| 07:15 | <annevk> | Took me long enough to realize the -N files in html/browsers/browsing-the-web/navigating-across-documents/ are supporting documents |
| 09:27 | <annevk> | Oh, git submodule update --init --recursive is listed in the documentation |
| 09:27 | <annevk> | I should try to remember that |
| 10:16 | <MikeSmith> | annevk: http://stackoverflow.com/questions/37522356/how-to-unify-retrieving-file-slices-supporting-both-file-api-and-xmlhttprequest |
| 10:19 | <MikeSmith> | also http://stackoverflow.com/questions/37522181/getting-the-http-status-code-for-a-failed-to-load-web-worker for anybody who might have a ready answer |
| 10:21 | <MikeSmith> | also is the answer at http://stackoverflow.com/questions/37521172/is-javascript-location-href-call-is-asynchronous actually correct? |
| 10:22 | <Ms2ger> | No |
| 10:23 | <MikeSmith> | OK well somebody should take the time to correct the person who posted it :) |
| 10:24 | Ms2ger | goes to find his password |
| 10:24 | <MikeSmith> | just have it send you an e-mail message with a reset link |
| 10:25 | <MikeSmith> | or actually I thought you could just link it to some other account |
| 10:26 | <MikeSmith> | anyway, I don’t remember half the passwords I use. I just reset them to something else every time I need to |
| 10:27 | <annevk> | I'm quite happy with 1Password |
| 12:47 | <MikeSmith> | zcorpan: please take a look at the error message for https://checker.html5.org/?doc=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%2C%3C%2521doctype%2520html%3E%3Ctitle%3Etest%3C%252Ftitle%3E%3Cbody%3E%3Clink%2520rel%253Dicon%2520href%253Dfoo%3E and lemme know what you think |
| 12:47 | <MikeSmith> | e.g., is it too verbose |
| 12:49 | <MikeSmith> | or should we instead have it just emit a message like, “A link element with rel attribute whose value is “icon” must not appear as a descendant of a body element.” |
| 12:50 | <MikeSmith> | and similarly for other cases of rel in body where the the value is not dns-prefetch, pingback, preconnect, prefetch, prerender, or stylesheet |
| 12:50 | <MikeSmith> | I mean, have the message mention that the particular rel value used is not allowed |
| 12:51 | <MikeSmith> | vs instead mentioning what is allowed, like the message says now |
| 12:52 | <MikeSmith> | it seems to me it’s almost always better for users to mention what is allowed, but the messages can get a bit verbose |
| 13:06 | <zcorpan> | MikeSmith: looks good to me. it's not overly long and seems more helpful than just "foo is not allowed here" |
| 13:08 | <zcorpan> | MikeSmith: maybe s/must not appear as a descendant of a body element/is not allowed in body/ if you want it shorter |
| 13:09 | <MikeSmith> | yeah I was thinking that too (about “is not allowed” instead |
| 13:09 | <zcorpan> | MikeSmith: maybe the messages can have different styles for elements, attributes and values? |
| 13:09 | <MikeSmith> | no, it cannot currently |
| 13:09 | <MikeSmith> | well not without some ugly hackery |
| 13:10 | <MikeSmith> | on top of the ugly hackery already behind it |
| 13:10 | <zcorpan> | sure, i mean, an idea for better usability :-) |
| 13:10 | <MikeSmith> | yeah |
| 13:12 | <zcorpan> | is there something post-processing the messages to convert quotes to <code>s etc? |
| 13:24 | <zcorpan> | MikeSmith: src/nu/validator/messages/MessageEmitterAdapter.java ? seems like it could set a class attribute on the <code> depending on the text that preceded, if it was "element " or "attribute " (and then massage the messages to use that pattern consistently)? |
| 13:42 | <annevk> | wanderview: https://github.com/whatwg/fetch/issues/245#issuecomment-216822526 |
| 13:42 | <annevk> | wanderview: https://github.com/whatwg/url/pull/123 |
| 13:56 | <annevk> | zcorpan: maybe you can review https://github.com/whatwg/html/pull/1330 too? |
| 13:59 | <zcorpan> | annevk: sure, looking |
| 14:15 | <MikeSmith> | zcorpan: so the problem is that the codeString(…) logic that formats the code strings is format-agnostic; it is used for emitting the the gnu-formatted results and the JSON-formatted ones along with the HTML-formatted results |
| 14:15 | <MikeSmith> | zcorpan: so the place where I’d need to have it add a class value is https://github.com/validator/validator/blob/master/src/nu/validator/messages/XhtmlMessageTextHandler.java#L132 |
| 14:18 | <MikeSmith> | so I guess what I would need to do is add a param to that method in the class in inherits from, with a value of the param being the type of code (element, attribute, or value). And the non-HTML emitters would just not do anything with that param |
| 14:22 | <MikeSmith> | but still even if I did that I have to do a bunch more to even be able to hook into that, because as far as “depending on the text that preceded”, the logic does not keep state information about what text preceded what. It doesn’t actually even work from normal strings as a unit but instead from character arrays. |
| 14:23 | <MikeSmith> | so anyway, would not be straightforward at all to do it in the backend, but I think it might be in the JavaScript frontend code and a vaguely recall I have it doing something similar there already for something |
| 14:26 | <zcorpan> | MikeSmith: ok. i'm sure you can figure something out :-) |
| 14:26 | <nox> | Did anyone try to specify LenientFloat? |
| 14:27 | <zcorpan> | MikeSmith: another option is to use different characters earlier in the pipeline to differentiate |
| 14:27 | <nox> | (https://www.w3.org/Bugs/Public/show_bug.cgi?id=19988) |
| 14:29 | <zcorpan> | nox: cssom-view uses unrestricted double in some places and converts non-finite values to 0 (for compat with "long") |
| 14:30 | <nox> | zcorpan: Well, could have two behaviours like TreatNullAs |
| 14:30 | <nox> | (Or whatever is its name, can't remember.) |
| 14:30 | <zcorpan> | yeah |
| 14:30 | <zcorpan> | i suppose this hasn't happened yet |
| 14:38 | <zcorpan> | Should we make this no longer a parse error? <!-----------------------> |
| 16:25 | <Domenic> | interesting |
| 16:25 | <Domenic> | why was it a parse error? |
| 16:27 | <annevk> | Presumably the SGML thing? |
| 16:28 | <gsnedders> | yeah, the fact it wasn't compatible with legacy UAs post-Acid2, AFAIK |
| 16:43 | <Domenic> | like, old browsers would blow up in some way? how old? |
| 16:45 | <gsnedders> | Domenic: post-Acid2, pre-HTML5 parser |
| 16:45 | <Domenic> | that's not really meaningful to me... |
| 16:45 | <gsnedders> | mid-00 to late-00s? |
| 16:46 | <Domenic> | hmm hmm |
| 16:46 | <Domenic> | so maybe ie8 still blows up or something |
| 16:46 | <gsnedders> | Acid2 had an SGML comment parsing test, because Hixie_ |
| 16:47 | <gsnedders> | http://ln.hixie.ch/?start=1137799947&count=1 |
| 16:50 | <annevk> | So many lessons in that post we now take for granted |
| 16:53 | <tantek> | hah - somehow I totally missed that post |
| 16:54 | <tantek> | darn, 404: http://people.bath.ac.uk/py8ieh/internet/eviltests/comments-evil.html |
| 16:56 | <annevk> | tantek: http://www.hixie.ch/tests/evil/mixed/comments-evil.html |
| 16:57 | <annevk> | tantek: I guess bath.ac.uk finally upgraded Apache and no longer kept Ian's old redirects |
| 16:59 | <tantek> | I'm pretty sure we fixed that in Tasman (IE5/Mac) too back in the day, because of the thoroughness of all the rest of Hixie's tests. |
| 17:00 | <annevk> | Kinda weird Ian never got an award of sorts for advancing testing and standards practices as much as he has |
| 17:01 | <tantek> | annevk: hah, he & I were awarded with organizing a whole panel on best test suite practices at TPAC 2004 where we got to call out so many W3C test suites for being bad (or a few good) examples |
| 17:02 | <annevk> | Oh man, W3C is notoriously bad at this |
| 17:02 | <annevk> | I got "recognized" twice |
| 17:02 | <tantek> | hah - they used to be MUCH worse |
| 17:03 | <tantek> | annevk - though I'd say both Hixie and dbaron - their tests for CSS etc. back in that time period were amazingly useful at advancing interop, especially for new/emerging features |
| 17:03 | <annevk> | I got a paper signed by timbl et al for being on the W3C TAG, and for being a Chair of the Notifications WG |
| 17:03 | <annevk> | A decade of contributing to standards? Meh |
| 17:03 | <tantek> | hmm that makes me think |
| 17:04 | <annevk> | Yeah, that coupled with the unfortunately belated insight that standards can change, is what really changed the whole game |
| 17:05 | <tantek> | annevk: sure. I mean it took long enough to realize that we could actually *fix* CSS2 (in a non-spec-back-compat way) |
| 17:05 | <annevk> | If they had figured that out sooner, margin collapsing and inline text layout would be somewhat easier to grok |
| 17:06 | <tantek> | I'm not sure there was anything sane we could have done about margin collapsing after CSS1 "shipped". |
| 17:06 | <tantek> | (even with hindsight, it seems like an unsolveable mess) |
| 17:07 | <tantek> | (and we had zero chance of *eliminating* margin collapsing) |
| 17:07 | <annevk> | From talking to Hixie_ the problem was preserving as much as possible of the incompatible CSS2 invariants while also being compatible with browsers |
| 17:07 | <annevk> | Rather than just tossing CSS2 out of the window |
| 17:08 | <tantek> | um, we actually did toss much (most?) of CSS2 out the window when writing up CSS2.1 |
| 17:08 | <tantek> | and trying to pick the sane(r) things (most) browsers agreed on |
| 17:08 | <tantek> | a lot of the methodologies we take for granted today about evolving specs based on implementations came from that effort |
| 17:09 | <tantek> | granted, we could have probably tossed even more out of CSS2(.1) but we were still "new" at this at the time and still learning how far we could push things |
| 17:12 | <annevk> | Yeah, that's the story I remember for margin collapsing, that it could have been made much simpler if only Hixie_ and dbaron had realized sooner CSS 2.0 was not holy |
| 17:13 | <tantek> | there was no chance of any such realization as long as the creators of CSS1 were firmly re-emphasizing the "correctness" of vertical margin collapsing as an author-friendly model of block flow layout |
| 17:19 | <dbaron> | I think we could have eliminated the margins-collapsing-through-blocks thing, which was the biggest mistake there. |
| 17:21 | <tantek> | agreed. I really disliked that we kept that in particular. :/ |
| 17:35 | gsnedders | got caught out by that again a few days ago… |
| 17:35 | <gsnedders> | and it's not like I don't know a lot of this stuff well. |
| 17:47 | <annevk> | Enabling Travis has been great |
| 17:50 | <Domenic> | :) |