| 00:59 | <EveryOS> | I had gotten a bit confused. I was reading #the-style-element, which linked to #associated-css-style-sheet, and I noticed it required `HTMLStyleElement` to implement `linkStyle`. I hadn't realized that Web IDL put includes at the bottom, so I was like "where is linkStyle implemented". Eventually, I figured it out. |
| 09:21 | <JakeA> | annevk: Domenic: gsnedders: Turns out it's used on >30% of page loads, so I guess sync IPC is a no-go (https://www.chromestatus.com/metrics/feature/timeline/popularity/2719). I pitched some ideas about what 'approximate' values we could use here https://github.com/whatwg/html/issues/2018#issuecomment-671887516 |
| 09:32 | <MikeSmith> | jgraham: annevk: so it turns out that Firefox is actually failing that html5lib test I mentioned here about a week ago |
| 09:32 | <MikeSmith> | https://freenode.logbot.info/whatwg/20200805#c4645508 |
| 09:33 | <MikeSmith> | when I mentioned it last week I hadn’t realized it’s a testing fragment parsing, not normal parsing |
| 09:34 | <MikeSmith> | so the actual test that’s failing is, parsing of <math><tr><td><mo><tr> with <tr> as the context |
| 09:34 | <MikeSmith> | https://github.com/html5lib/html5lib-tests/blob/master/tree-construction/math.dat#L12 |
| 09:35 | <MikeSmith> | actually, that test and 3 other <math> fragment-parsing tests |
| 09:35 | <MikeSmith> | https://wpt.live/html/syntax/parsing/html5lib_innerHTML_math.html |
| 09:36 | <MikeSmith> | https://wpt.fyi/results/html/syntax/parsing/html5lib_innerHTML_math.html?label=master&label=experimental&aligned |
| 09:41 | <MikeSmith> | ... |
| 09:41 | <MikeSmith> | so now I wonder why those failures hadn’t been noticed |
| 09:42 | <MikeSmith> | or else if they had been noticed, why there’s not an open Firefox bug about fixing them |
| 09:43 | <MikeSmith> | and I wonder if for Firefox CI, they’re flagged as expected failures (and if so, why) |
| 09:51 | <jgraham> | MikeSmith: https://searchfox.org/mozilla-central/source/testing/web-platform/meta/html/syntax/parsing/html5lib_innerHTML_math.html.ini |
| 09:52 | <jgraham> | Looks like we added expected: FAIL on a sync in 2018 |
| 09:53 | <jgraham> | It's hard to get people to look at all the expected failures, although we're getting better (layout team in particular are doing a great job) |
| 09:56 | <MikeSmith> | jgraham: ah thanks |
| 09:57 | <MikeSmith> | well as far as looking at the failures, I’m checking the source now |
| 09:59 | <MikeSmith> | I think it has to be some problem with the code not putting the tree builder into the right insertion mode for the context node |
| 10:00 | <MikeSmith> | ...because it’s getting the same test right if it’s run with a different context node |
| 10:01 | <MikeSmith> | specifically, that test works if the context element is td, but fails if the context element is tr |
| 10:03 | <jgraham> | hsivonen: ^ |
| 10:08 | <zcorpan> | I try to use BroadcastChannel in a test. Find that it is still not implemented in WebKit. Find https://bugs.webkit.org/show_bug.cgi?id=161472#c4 |
| 10:12 | <MikeSmith> | I think Ryosuke mentitioned the same thing in an issue-tracker discussion yesterday |
| 10:14 | <MikeSmith> | or maybe that was another feature, in which case it’s a general issue blocking multiple features |
| 12:30 | <smaug____> | MikeSmith: I think hsivonen is going to merge some changes from the validator to Gecko, to ensure the behavior is the same |
| 12:36 | <MikeSmith> | smaug____: I think I know the ones he’s planning to merge (they’re changes I wrote), but for this math fragment-parsing case, there’s no change yet — the Java (validator) parser also has the same bug, unfixed |
| 12:43 | <smaug____> | I see |
| 20:39 | <shu> | where in the HTML spec is the meaning of "resolve a promise" defined? |
| 20:41 | <shu> | ah, is it using the one in webidl? https://heycam.github.io/webidl/#resolve |
| 20:41 | <domfarolino> | shu: https://heycam.github.io/webidl/#resolve |
| 20:41 | <shu> | cool, thanks |
| 20:41 | <domfarolino> | Ah you found it |
| 20:41 | <domfarolino> | Yeah I think that's it |
| 20:42 | <TabAtkins> | ah dang y'all beat me |
| 20:42 | <shu> | i am glad irccloud doesn't autolink repo pictures |
| 20:43 | <domfarolino> | lol |
| 21:19 | <EveryOS> | https://www.irccloud.com/pastebin/iqADohBo/ |
| 21:20 | <EveryOS> | Oof, accidentally posted as snippet |
| 21:26 | <Domenic> | If you abandon back-compat, you can indeed get a much simpler parser |
| 21:27 | <Domenic> | https://ygg01.github.io/xml5_draft/ is one such example, especially if you subtract all the DOCTYPE states. |
| 21:30 | <EveryOS> | Oh, that's cool |
| 21:33 | <EveryOS> | Huh, Processing Instruction state? That must be something from XML that is not in HTML |
| 21:45 | <EveryOS> | Tbh I think that, as far as parsing HTML5, the complexity is in the Insertion Modes |
| 21:45 | <EveryOS> | Yes, there are more Tokenization states than Insertion Modes |
| 21:45 | <EveryOS> | But the Insertion modes have large branches for different tokens |
| 21:45 | <EveryOS> | And also, the logic used in Insertion Modes is much more complex than that of Tokenization States, and can even call into other algorithims |
| 21:49 | <EveryOS> | https://usercontent.irccloud-cdn.com/file/OruABbaj/image.png |
| 21:49 | <EveryOS> | The blue boxes are TODO statements |
| 21:49 | <EveryOS> | I have many more in the insertion state point than my tokenization point |
| 21:54 | <Domenic> | Good point, if you have a less complex language, then tree construction becomes trivial once you've tokenized. |
