| 08:03 | <annevk> | yoav: to be sure, that test passes in all browsers? |
| 08:05 | yoav | verifying |
| 08:06 | <yoav> | yup |
| 08:08 | <annevk> | thanks, all merged |
| 10:07 | <zcorpan_> | annevk: do you know why CSP-blocked images in firefox are display: none !important ? |
| 10:07 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8451 |
| 10:10 | <annevk> | ecobos might know, but that sounds weird |
| 10:11 | <annevk> | Ideally they would be no different from any other kind of network error |
| 10:17 | <zcorpan_> | ecobos: they're matching :-moz-supressed I think https://hg.mozilla.org/mozilla-central/file/tip/layout/style/res/html.css#l665 |
| 10:27 | <andreubotella> | I'm refactoring the HTML parser to use I/O queues in a bit of an informal way to be fleshed out later |
| 10:28 | <andreubotella> | and I'm not sure what language to use to say that the tokenizer and tree constructor must run on the same thread |
| 10:40 | <MikeSmith> | andreubotella: are implementations of the parser algorithm required to use threads to begin with? |
| 10:40 | <MikeSmith> | that seems like an implementation detail |
| 10:41 | <andreubotella> | not until now, but as part of encoding#215 annevk and I realized that "streams" had some holes in them, and decided to go with a blocking read |
| 10:42 | <MikeSmith> | I see |
| 10:42 | <andreubotella> | I'm now realizing that this might need some restructuring of the way the reentrancy works |
| 10:43 | <andreubotella> | which is pretty much black magic to me |
| 10:43 | <andreubotella> | thus why I'm doing this informally on html#5874, to be fleshed out later |
| 10:43 | <MikeSmith> | well I think as far as the spec language goes around the tokenizer and tree constructor, I would think just some language about “blocking read” would suffice, without mentioning threads |
| 10:44 | <MikeSmith> | but now I realize that is probably what you were already saying yourelf |
| 10:44 | <MikeSmith> | I mean how to word that, without explicitly saying, “must run on the same thread“ |
| 10:45 | <andreubotella> | I'm specifying that the decode algorithm and the tokenizer/tree constructor must run in parallel to the event loop and to each other |
| 10:45 | <andreubotella> | since the reads from the network are enqueued onto the input byte stream on the event loop |
| 10:46 | <andreubotella> | but I'm leaving it at that, with maybe some note about implementations having to bend the spec to modify the DOM from a thread |
| 10:50 | <MikeSmith> | yeah such notes are really helpful in making clear what needs to happen in normal practice, when the spec language gets that abstract |
| 10:50 | <MikeSmith> | anyway what you describe sounds pretty interesting |
| 10:52 | <MikeSmith> | (lately I’ve been working a lot on bug fixes and updates to the validator.nu Java implementation of the HTML parser, so I’m especially interested in any possible evolutions of the parser algorithm) |
| 10:54 | <andreubotella> | this is meant to be an editorial change, since the bug was in the way Encoding streams switched from being data structures in memory on one moment to representing a sequence of bytes to come from the network on the next |
| 10:54 | <andreubotella> | implementations shouldn't have that problem |
| 10:59 | <zcorpan_> | hsivonen: is the speculative parser kicked off upon an <script> without a src attribute? |
| 11:08 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8457 suggests there's no speculation for an inline classic script |
| 11:14 | <zcorpan_> | hsivonen: I'm a bit confused by your comments here https://github.com/privacycg/proposals/issues/19#issuecomment-690162075 |
| 11:16 | <zcorpan_> | hsivonen: so you mean fetches can happen before the parser inserts stuff the to DOM even though there's no speculative parsing? |
| 11:17 | <ecobos> | zcorpan_: yeah, they're matching `:-moz-suppressed`... I don't have all the context of that but if you file a bug and cc me I can get to it. I agree it's pretty weird |
| 11:17 | <ecobos> | zcorpan_: (you can see the browser rules in devtools if you check the right checkbox in the settings, fyi) |
| 11:18 | <zcorpan_> | ecobos: I saw it in devtools :) |
| 11:18 | <zcorpan_> | ok I can file, thanks! |
| 11:18 | <ecobos> | zcorpan_: ah, so the "I think" was really "I know" :P |
| 11:19 | <zcorpan_> | ecobos: that assumes I trust devtools :P |
| 11:19 | <ecobos> | lol |
| 11:20 | <ecobos> | zcorpan_: well, this is some old code, so figuring out what depends on this is going to be fun... https://bugzilla.mozilla.org/show_bug.cgi?id=11011 |
| 11:20 | ecobos | hadn't seen a 5-digit bug number in a while |
| 11:22 | <ecobos> | zcorpan_: It seems per the comments that that was supposed to "block images from this site" and such, so if it triggers for CSP it seems like a bug to me |
| 11:22 | <ecobos> | zcorpan_: anyhow I can look, feel free to cc/ni? me so I don't forget. Thank you! |
| 11:29 | <zcorpan_> | ecobos: https://bugzilla.mozilla.org/show_bug.cgi?id=1664156 |
| 11:55 | <annevk> | Anyone else care to review a minor DOM Event introduction change? https://github.com/whatwg/dom/pull/890 |
| 12:01 | <MikeSmith> | annevk: will look |
| 12:06 | <MikeSmith> | annevk: is that whole section marked non-normative? |
| 12:06 | MikeSmith | looks |
| 12:07 | <MikeSmith> | OK, it’s not, actually |
| 12:07 | <MikeSmith> | maybe it should be? |
| 12:18 | <annevk> | MikeSmith: probably, yeah |
| 12:44 | <MikeSmith> | annevk: added a general comment: |
| 12:45 | <MikeSmith> | > General comment (relevant to @kevinsung’s specific comment about “effectively”): To avoid ambiguity about what statements in the DOM spec are normative and which aren’t, it seems like it would be useful for non-normative sections of the published DOM spec to be rendered with explicit This section is non-normative text after the section headings — in the way the HTML spec is. But I guess more |
| 12:45 | <MikeSmith> | generally, that’s an issue for Bikeshed (in that, Bikeshed currently doesn’t have a feature for automatically emitting explicit This section is non-normative text in the way that the HTML spec has. |
| 12:45 | <MikeSmith> | ... |
| 12:46 | <MikeSmith> | I don’t think Bikeshed has any such feature, but maybe it does and I just haven’t noticed |
| 13:50 | <andreubotella> | in wattsi, a definition with <dfn data-x=""> makes no sense, right? |
| 13:50 | <andreubotella> | as in, an empty data-x attribute |
| 13:52 | <zcorpan_> | andreubotella: html uses that in a few places, in Typographic conventions and Terminology |
| 13:53 | <zcorpan_> | andreubotella: for Terminology, I think it wants to define terms but not have links for each usage of that term |
| 13:54 | <andreubotella> | I see |
| 13:54 | <andreubotella> | So I suppose this is a mistake: |
| 13:54 | <andreubotella> | > The next input character is the first character in the input stream that has not yet been <dfn data-x="">consumed</dfn> or explicitly ignored |
| 13:56 | <zcorpan_> | andreubotella: I'm not sure why that doesn't use a normal <dfn> |
| 13:57 | <zcorpan_> | "Reconsume" is <dfn>ed, but "consume" is not |
| 14:47 | <annevk> | andreubotella: I doubt it's a real mistake since if anyone tried to link that with <span>consumed</span> it would not build |
| 14:47 | <andreubotella> | "consume the next input character" is ofc used a lot, just not linked |
| 14:47 | <annevk> | andreubotella: that does not mean the current state of affairs is ideal, a lot of this text is old and predates our more formal style |
| 14:48 | <annevk> | linking it does seem nicer |
| 16:30 | <andreubotella> | https://github.com/whatwg/html/pull/5874 |
| 16:30 | <andreubotella> | those were a lot of "consume the next input character" |
| 16:31 | <andreubotella> | and I had to fight VSCode every time because it kept indenting the second line |
| 16:31 | <TabAtkins> | MikeSmith: Bikeshed doesn't have such a feature, no. |
| 16:31 | <andreubotella> | *misindenting rather |
| 19:52 | <zcorpan_> | https://github.com/privacycg/proposals/issues/19 - I have several questions, but might get a bit off topic for the issue :) (cc hsivonen ) |
| 19:53 | <zcorpan_> | I think I recall the speculative fetches from normal HTML parser being a thing even before speculative parsing existed, but I'm not entirely sure. Was it a thing before speculative parsing? |
| 19:54 | <zcorpan_> | Do chromium and webkit also do this? (i.e. speculatively fetch resources from the HTML parser before the element is inserted to the DOM) |
| 19:54 | <zcorpan_> | Should we specify this? |
| 20:00 | <zcorpan_> | What's a reliable way to test it? <object>? (it gets processed "the element is popped off the stack of open elements of an HTML parser or XML parser,", in a queued task) |