| 02:07 | <MikeSmith> | Domenic: I don't have perms to update /TR shortname (undated) URLs. Nor does plh. They're basically just symlinks set up by the publication manager (aka webmaster) |
| 02:08 | <MikeSmith> | but what I can do is, I can add a bold disclaimer that will show up there |
| 02:08 | <MikeSmith> | will do that right now |
| 02:11 | <MikeSmith> | Domenic: btw sad to hear "they don't want to sponsor working from home or remote work, which has lost a couple candidates already". I had thought that in the past at least they'd taken more of an enlightend view of things |
| 02:15 | <MikeSmith> | I guess the claims at various places of attracting/having the "best and brightest" needs to be qualified with "The best and the brightest people who already live near one of the few places where we have engineering offices or are willing uproot your entire lives to relocate to one of the few places where we think they should leve." |
| 02:20 | <MikeSmith> | btw while working right now on adding the disclaimer to the https://www.w3.org/TR/url/ document, it seems very appropriate that I have to use cvs to do it |
| 02:29 | <MikeSmith> | Domenic: annevk https://www.w3.org/TR/url/ now has a fugly non-dismissable fixed-position warning |
| 02:30 | <MikeSmith> | that's the best I can do for now |
| 03:45 | <MikeSmith> | Domenic: annevk fwiw I also went ahead just now and added the fugly non-dismissable fixed-position warning to the https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm and https://www.w3.org/TR/streams-api/ documents |
| 03:50 | <roc> | MikeSmith: who's "they"? |
| 03:51 | <MikeSmith> | hi roc |
| 03:51 | <MikeSmith> | roc: http://krijnhoetmer.nl/irc-logs/whatwg/20150818#l-602 |
| 03:51 | <MikeSmith> | is the context |
| 03:52 | <roc> | ta |
| 03:55 | <MikeSmith> | roc: btw as a parent 8with a lot of what you wrote about the rw |
| 03:56 | <MikeSmith> | oofs |
| 03:56 | <MikeSmith> | roc: btw as a parent 8with a lot of what you wrote about the rw |
| 03:56 | MikeSmith | straightens out his fingers |
| 03:57 | <MikeSmith> | roc: as a parent (with another new one on the way soon), lot of what you wrote about the unexpected rewards of being a parent in http://robert.ocallahan.org/2015/08/parenting.html really spoke to me and my own experiences |
| 03:57 | <MikeSmith> | so, thanks for taking time to write it |
| 03:57 | <roc> | cool! |
| 03:59 | <MikeSmith> | I wish more tech people in our world would take time to write a bit now and then about their non-tech lives |
| 03:59 | <MikeSmith> | I should more myself, I guess |
| 04:22 | <MikeSmith> | birtles: thanks for the https://platform.html5.org/ PR (just now merged it) |
| 04:37 | <birtles> | MikeSmith: thanks! |
| 04:38 | <Domenic> | oh awesome, thanks MikeSmith! |
| 05:56 | <annevk> | MikeSmith++ |
| 07:33 | <nox> | I don't see anything related to U+0000 NULL in https://html.spec.whatwg.org/multipage/syntax.html#cdata-section-state, is that intended? |
| 07:33 | <nox> | html5lib-tests seem to include tests for NULL replacement by U+FFFD, but I can't find that in the spec. |
| 07:38 | <Ms2ger> | I think there's supposed to be some kind of preprocessing step |
| 07:39 | <Ms2ger> | Or not |
| 07:39 | <Ms2ger> | The handling of U+0000 NULL characters varies based on where the characters are found. In general, they are ignored except where doing so could plausibly introduce an attack vector. This handling is, by necessity, spread across both the tokenization stage and the tree construction stage. |
| 07:45 | <nox> | Ms2ger: I think the rationale was avoiding NULL everywhere, because of legacy things where it could be a security issue. The weird thing is these tests checking for replacement. |
| 07:57 | <annevk> | nox: see 12.2.5.5 |
| 07:58 | <annevk> | nox: CDATA only occurs in foreign content, where a null is replaced with U+FFFD looks like |
| 07:59 | <nox> | annevk: Oh, thanks. |
| 08:19 | <annevk> | zewt: https://github.com/whatwg/url/issues/62#issuecomment-132488127 |
| 08:22 | <nox> | annevk: Oh, subscribed. :) |
| 08:37 | <nox> | There are tests for <rb> in <ruby> in html5lib-tests, but no mention of <rb> at all in the HTML spec. Is that intended too? |
| 08:40 | <Ms2ger> | Don't ask |
| 08:40 | <nox> | Ah ah. |
| 08:40 | <nox> | I think the tests are wrong, according to https://github.com/html5lib/html5lib-tests/issues/54. |
| 08:41 | <annevk> | nox: there's an open bug on <rb> iirc |
| 08:42 | <nox> | annevk: https://github.com/html5lib/html5lib-tests/issues/51? |
| 08:42 | <annevk> | nox: I meant against the HTML Standard |
| 08:42 | <nox> | Oh, sorry. |
| 08:42 | <nox> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=26189 |
| 08:43 | <annevk> | Yeah, I wonder how much scrutiny the addition in "W3C HTML" got |
| 08:44 | <annevk> | The last time the W3C supplied a patch (for <template>) it was quite bad |
| 08:44 | <nox> | Hah. |
| 08:45 | <nox> | annevk: The current consensus is that <rb> and <rtc> should be implicitly closed, right? |
| 08:48 | <annevk> | nox: I don't know |
| 08:52 | <Ms2ger> | Calling hsivonen |
| 08:54 | <hsivonen> | I was called |
| 08:55 | <hsivonen> | nox, annevk, Ms2ger: I've noticed that we fail the html5lib Ruby tests, but I haven't had the time to look into whether to blame the code, the tests or the spec |
| 08:56 | <nox> | hsivonen: In doubt, blame everything. |
| 08:56 | <nox> | Or just Obama. |
| 08:56 | <Ms2ger> | Or Canada |
| 08:56 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=1178484 makes me sad, but I guess I should r+ it and not fight it |
| 08:57 | <hsivonen> | Facebook won this one long ago :-( |
| 09:02 | <jgraham> | Canada will at least apologise |
| 09:08 | <nox> | jgraham: Ah ah. |
| 09:11 | <annevk> | hsivonen: that idea still seems terrible though |
| 09:11 | <annevk> | hsivonen: note also that folks objected when this was raised on dev.platform |
| 09:27 | jgraham | mutters something about tests where the title doesn't match the actual test behaviour |
| 09:27 | <jgraham> | For the record, it's quit possible that I wrote the test in question :) |
| 09:27 | <jgraham> | *quite |
| 09:27 | <jgraham> | Although history — at least outside Opera — doesn't record that |
| 09:28 | <jgraham> | Anyone want to guess what https://github.com/w3c/web-platform-tests/blob/master/old-tests/submission/Opera/script_scheduling/112.html is supposed to be testing? |
| 09:31 | <jgraham> | testing that a script with both async and defer runs before the load event seems rather pointless since either attribute could have that effect |
| 09:32 | <jgraham> | and timing alone should usually cause it to run after DOMContentLoaded even if it's async |
| 10:05 | <annevk> | jgraham: I wonder if that used to be a more elaborate external dependency before, with "pipe=trickle(d1)" |
| 10:05 | <annevk> | jgraham: causing it to hang for a second or so |
| 10:30 | <annevk> | Ms2ger: why is there both a ref and xref folder in https://github.com/whatwg/xref/? |
| 10:34 | <Ms2ger> | ref is for the References section? |
| 10:35 | <Ms2ger> | Not sure if there's still much of a point to that |
| 10:38 | <annevk> | Oh, I didn't know about that feature |
| 10:38 | <annevk> | Seems weird |
| 10:46 | <annevk> | MikeSmith: what's the two favicon files in https://github.com/whatwg/platform.html5.org? |
| 10:47 | <annevk> | MikeSmith: also, maybe remove whatwg.png in favor of just referencing resources.whatwg.org? |
| 11:11 | <nox> | I have trouble following the spec as to why "<!doctype html><p><math><mn><span></p>a" should end up with a p inside a span inside an mn inside a math inside another p. |
| 11:40 | <gsnedders> | nox: you hit the 'Otherwise, process the token according to the rules given in the section corresponding to the current insertion mode in HTML content.' in the foreign content insertion mode |
| 11:40 | <gsnedders> | then you go back to the in body mode and you hit "If the stack of open elements does not have a p element in button scope, then this is a parse error; insert an HTML element for a "p" start tag token with no attributes. |
| 11:41 | <gsnedders> | and because "mn" creates a scope you don't have a p element in scope |
| 11:42 | <nox> | gsnedders: Thanks. |
| 11:43 | <nox> | gsnedders: But that "Otherwise" is hit 'If the adjusted current node is a MathML text integration point and the token is a start tag whose tag name is neither "mglyph" nor "malignmark"', isn't the token here <span>? |
| 11:43 | <Ms2ger> | jgraham, wait, why does https://github.com/w3c/web-platform-tests/blob/master/old-tests/submission/Opera/script_scheduling/112.html call t.done() twice? |
| 11:45 | <gsnedders> | nox: oh, sorry. yes, the span is parsed in the current insertion mode (in-body) |
| 11:46 | nox | is utterly lost. :) |
| 11:47 | <nox> | gsnedders: Shouldn't the span be parsed through "Otherwise process the token according to the rules given in the section for parsing tokens in foreign content."? |
| 11:48 | <gsnedders> | nox: OK, so when you've parsed "<!doctype html><p><math><mn>", you have a span start tag token to parse |
| 11:48 | <nox> | Yes. |
| 11:48 | <gsnedders> | nox: the adjusted current node is a mn element in the MathML namespace, which is a MathML text integration point |
| 11:48 | <gsnedders> | so we "Process the token according to the rules given in the section corresponding to the current insertion mode in HTML content. |
| 11:48 | <nox> | Why? |
| 11:48 | <gsnedders> | https://html.spec.whatwg.org/multipage/syntax.html#tree-construction-dispatcher |
| 11:48 | <nox> | "If the adjusted current node is a MathML text integration point and the token is a start tag whose tag name is neither "mglyph" nor "malignmark" |
| 11:48 | <nox> | If the adjusted current node is a MathML text integration point and the token is a character token" |
| 11:49 | <nox> | AFAICT, the adjusted current node is indeed a MathML text integration point, but the token isn't a start tag whose tag name is neither "mglyph" nor "malignmark". |
| 11:49 | <gsnedders> | so the adjusted current node is a mn element in the MathML namespace, right? |
| 11:50 | <gsnedders> | the token is a start tag whose tag name is neither "mglyph" nor "malignmark", because it's a start tag whose tag name is "span" |
| 11:50 | <nox> | Oh god, I can't read. |
| 11:50 | <gsnedders> | and "span" is neither "mglyph" nor "malignmark" |
| 11:50 | <gsnedders> | :) |
| 11:50 | <gsnedders> | eh, it happens to us all. especially when implementing something that's quite repetitive. |
| 11:55 | <jgraham> | Ms2ger: Good point! |
| 12:32 | <annevk> | hsivonen: it just occurred to me that https://github.com/whatwg/encoding/issues/5 is a problem for several encodings |
| 13:58 | <gsnedders> | nox: you implementing foreign content support in html5ever, or? |
| 13:58 | <nox> | gsnedders: I'm making failing tests pass. That was one of them yes. |
| 13:59 | <gsnedders> | nox: so yeah, I /believe/ we should have the right number of errors for all the tests, but I can't guarantee it. |
| 14:04 | <nox> | gsnedders: I kinda want to add tests for the parse errors too. |
| 14:04 | <gsnedders> | nox: what do you mean? |
| 14:05 | <nox> | gsnedders: I mean in html5ever. The #error part isn't tested. |
| 14:05 | <gsnedders> | nox: right |
| 14:05 | <gsnedders> | nox: so yeah, I can't guarantee the #error section is right, but it probably is? |
| 14:06 | <gsnedders> | nox: I can give far stronger guarantees about everything else! |
| 14:07 | <nox> | gsnedders: Well, even all the more reason to implement them, that way we will be able to give strong guarantees about everything. |
| 14:12 | <Ms2ger> | There's still the question of collapsing multiple parse errors into one |
| 14:14 | <gsnedders> | the /number/ of parse errors should be constant, IIRC |
| 14:14 | <gsnedders> | it's just /what/ parse errors you get is undefined |
| 14:16 | <nox> | gsnedders: I know of at least one FIXME in html5ever where it wonders if some error machinery should stop at first erroneous tag. I'm not currently at home so can't say more about it. |
| 14:17 | <jgraham> | I'm less sure that the error part is right :) |
| 14:43 | <wanderview> | annevk: https://github.com/whatwg/fetch/issues/112 |
| 14:44 | <Domenic> | Ah, it's so nice having more implementers in the channel, spicing things up with crazy parser talk. <3 nox |
| 15:06 | <annevk> | wanderview: thank you |
| 15:27 | <nox> | Domenic: Heh. :) |
| 15:42 | <wanderview> | annevk: I'm going to write my wpt test to the gecko behavior for now on the assumption that spec issue is real |
| 15:43 | <annevk> | wanderview: sounds good |
| 15:43 | <annevk> | wanderview: I can try to fix it tomorrow if that helps |
| 15:45 | <wanderview> | thanks |
| 15:45 | <wanderview> | annevk: I'll probably be working on this for at least a few more days... so any time in there |
| 16:10 | <ccardona-work> | Good morning WHATWG crew o/ |
| 16:46 | annevk | has been tidying up URL and Encoding |
| 16:47 | <annevk> | I still have to do some Encoding and URL stuff, but fixing a few Fetch things shouldn't take long |
| 16:50 | <nox> | gsnedders: I think there are no tests for parsing fragments into templates. |
| 16:52 | <nox> | gsnedders: Nor tests for parsing fragments into annotate-xml elements. |
| 16:55 | <gsnedders> | nox: entirely plausible |
| 16:56 | <gsnedders> | nox: in general fragment parsing is somewhat undertested |
| 16:56 | <gsnedders> | nox: feel free to contribute tests (or at least file bugs on what needs tests)! |
| 17:09 | <wanderview> | annevk: does Response tainting effect anything other than the type of Response returned from fetch()? |
| 17:10 | <wanderview> | I mean, do we expect other specs like html to look at the type of the Response returned from the fetch algorithm? |
| 17:26 | <Ms2ger> | annevk, un-owner-ed myself |
| 18:28 | <nox> | gsnedders: Filed some. |
| 18:31 | <nox> | hsivonen: Any idea when you will look at the Ruby in HTML tests/spec btw? Last failing tests I can't do much about. :) |
| 19:54 | <nox> | OH: "HTML is fairly easy to parse, I wrote an HTML parser once just with a loop and state variable" |
| 20:04 | <jgraham> | hahahahahaha |
| 20:55 | <Matt5ander5> | does anyone in here use textual irc client for mac ? |
| 21:08 | <nox> | #data |
| 21:08 | <nox> | <table><colgroup> foo</colgroup></table> |
| 21:08 | <nox> | #errors |
| 21:08 | <nox> | (1,7): expected-doctype-but-got-start-tag |
| 21:08 | <nox> | (1,32): foster-parenting-character-in-table |
| 21:08 | <nox> | (1,32): foster-parenting-character-in-table |
| 21:08 | <nox> | (1,32): foster-parenting-character-in-table |
| 21:08 | <nox> | (1,32): unexpected-end-tag |
| 21:08 | <nox> | #document |
| 21:08 | <nox> | | <html> |
| 21:08 | <nox> | | <head> |
| 21:08 | <nox> | | <body> |
| 21:09 | <nox> | Anyway, yay, gsnedders, the errors look funky in many places, from a quick first glance. |
| 21:10 | <nox> | In the case I mistakenly pasted just now, the foster-parenting errors are I think for the "foo" text, one per character, and is reported at the end of </colgroup> for a reason I ignore. A mistake, probably? |
| 21:11 | <nox> | I also don't know how they are related to foster parenting, too. |
| 21:50 | <gsnedders> | nox: and the locations seem off, bah |
| 21:51 | <gsnedders> | nox: basically nolanw based them off his Obj-C implementation a while ago because it was the first time in ages anyone had tried to make sure an implementation was up to date with the spec wrt parse errors. at some point html5lib-python should be updated so we can see how that compares. |
| 22:03 | <nox> | gsnedders: I'm currently comparing them to the results of html5ever, |
| 22:03 | <nox> | gsnedders: looked at 4 mismatches, all 4 seem to be problems in the tests. |
| 22:04 | <gsnedders> | Entirely plausible. :) |
| 22:04 | <nox> | 59 failing tests when checking errors. |
| 22:04 | <gsnedders> | Feel free to open a PR. That one might take longer to review, though. :) |
| 22:04 | <nox> | Many of them are just foster-parenting-character-in-table. |
| 22:04 | <nox> | gsnedders: Will do, with the most obvious commits first. |
| 22:05 | <nox> | For example, 􏑇FOO in the tests only report an error for the illegal code point, and not the missing semicolon. |
| 22:53 | <nox> | gsnedders: Just understood why the location are off. And it seems on purpose. |
| 22:54 | <nox> | gsnedders: Error happens in "Anything else" in https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-intabletext, so you could argue it is reported at the end of the "anything else" thing, in that case </colgroup>. |
| 22:54 | <nox> | Having the error three times is wrong though. |