| 01:13 | <Domenic> | Structs have items, although I sometimes accidentally call them members, which makes me wonder why we called them items in the first place... |
| 02:12 | <jmdyck> | And would you refer to something like a navigable's target name as an item? |
| 03:29 | <Domenic> | To the extent that we decide they are structs, yes. Which I guess they are, although not explicitly. |
| 07:48 | <annevk> | Domenic: thoughts on https://github.com/web-platform-tests/wpt/pull/50295? I didn't actually want that to land until you weighed in. |
| 08:11 | <Domenic> | Hmm I wonder how I missed that. I think the 1 and 2 direction seems reasonable. This seems like an area where doing the simplest-possible thing is best, and since "anything starting with on" wasn't good, the 1 plus 2 option seems like the next-simplest. |
| 09:27 | <foolip> | I'm thinking of writing a basic tool to convert the HTML spec to Bikeshed, getting it only 80% correct, so that Tab could benchmark against that instead. annevk other than performance, do you know of any other issues that would have to be addressed to make migration realistic? I can spend a bit of time on this if it feels within reach. |
| 09:35 | <Ms2ger> | Grateful that Tab has time to work on bikeshed |
| 11:51 | <annevk> | foolip: you could maybe use Microsoft's work on the W3C fork some number of years ago for benchmark purposes? But maybe doing it fresh is better, as much has changed. I don't know of any other issues, but I think it's primarily Domenic that cares about the particulars here as I was willing to accept longer CI runs. |
| 12:41 | <sideshowbarker> | I guess we’d want to decide how much a slowdown in build times for CI runs — and for local builds by patch/PR contributors — would be acceptable |
| 12:42 | <sideshowbarker> | In my local environment currently, the build takes only about 25 seconds to run |
| 12:43 | <sideshowbarker> | So even if the Bikeshed build ended up about 10 times as slow, that’s still only 4 minutes |
| 12:44 | <sideshowbarker> | …which maybe is still fast relative to say, building code for a large software project |
| 12:44 | <sideshowbarker> | (certainly faster than running a clean build for any browser engine) |
| 12:55 | <annevk> | https://matrixlogs.bakkot.com/irc-whatwg/plaintext/2018-06.txt has some prior discussion involving many of the same people. Assuming Domenic still feels the same about this, the numbers would have to be very close to what you get today locally. |
| 12:57 | <Domenic> | I am constantly editing and rebuilding the full spec locally, yeah, anything slower than the current would dramatically curtail my contributions |
| 12:59 | <Domenic> | Html-build's -f mode (single page only, no highlight pass, no lint pass) is like < 5 seconds on my desktop, maybe 10-15 on laptop? |
| 13:05 | <sideshowbarker> | OK yeah, I just tried now, and building with -f is 4–5 seconds on my laptop |
| 13:07 | <sideshowbarker> | so 10 times slower than that would be 40–50 seconds |
| 13:07 | <sideshowbarker> | I’d like to be optimistic, but I find it unlikely that a Bikeshed-based build is going to ever be able to come close to the current build times |
| 13:08 | <sideshowbarker> | I mean, at least a Python-based Bikeshed |
| 13:08 | <sideshowbarker> | but maybe there’s some magic there I’m unaware of |
| 13:09 | <sideshowbarker> | One thing about the existing Wattsi code is that its HTML parser is extremely exceptionally fast |
| 13:10 | <sideshowbarker> | and another thing is, I think maybe even in the -f case, the Wattsi build parses the source multiple times |
| 13:25 | <jmdyck> | Why would it parse it multiple times? |
| 13:34 | <jose.pepe> | Greetings to all. I am glad that this chat on whatwg exists, I just discovered it! I was wondering if there is any documentation on the "domain language" concepts related to DOM, as it would be a good tool for me to have that documentation to refer to while studying the living DOM documentation. |
| 13:36 | <annevk> | jose.pepe: https://dom.spec.whatwg.org/ should explain all the terms. Anything in particular that trips you up? |
| 13:41 | <jose p> | Hi annevk, that is the documentation I am studying these days, however I have just started and I would like to understand better what is a "navigable", what is 'something active' (for example when talking about session history entry) and some other concepts are used there |
| 13:49 | <jmdyck> | navigable and session history aren't mentioned in the DOM spec. Are you looking at the HTML spec? |
| 14:06 | <jose p> | That's right. Sorry for the misunderstanding. This is the url I'm reading from: https://html.spec.whatwg.org/#navigation-and-session-history |
| 14:11 | <annevk> | jose p: it might make more sense if you start reading at 7.3 (and maybe keep in mind 1.9.1, which is not entirely facetious, especially if you're new to standards in general) |
| 14:20 | <jose p> | Not facetious. I'm learning the basics so these explanations and rules come in handy here. Thx annevk |
| 14:27 | <Noam Rosenthal> | zcorpan: I see that the Mozilla standards position github doesn't have a template anymore, is that on purpose? |
| 14:30 | <zcorpan> | Noam Rosenthal: I guess GitHub removed support for the ISSUE_TEMPLATE.md. See https://github.com/mozilla/standards-positions/pull/1156 |
| 14:31 | <zcorpan> | Manually copy from https://github.com/mozilla/standards-positions/blob/main/ISSUE_TEMPLATE.md?plain=1 for now |
| 14:33 | <jmdyck> | foolip: I'm curious about the idea of converting the HTML spec to Bikeshed. I wonder if the HTML spec is too 'weird' to express in Bikeshed format, but I'm not familiar enough with the latter yet. |
| 15:20 | <Ms2ger> | It might need some pre- or post-processing, but I don't think it's that weird in other ways than size |
| 15:41 | <annevk> | Agreed. HTML used to be in terms of Anolis, which is what Bikeshed in terms of format is also loosely derived from. (And as I mentioned above it's been converted to Bikeshed before. Just not in a way that lasted or could be properly reviewed.) |
| 15:42 | <annevk> | Did the CSS specification preprocessor have a name of sorts? I think that was used before these tools, but it's hard to find now. |
| 15:45 | <Ms2ger> | "Bert's postprocessor"? |
| 15:46 | <annevk> | That's not wrong. 😀 |
| 15:55 | <smaug> | Jake Archibald: happen to be around? |
| 15:58 | <Jake Archibald> | @smaug:mozilla.org: half 😀. I'm in all day meetings but I can do some async replying |
| 15:59 | <smaug> | Jake Archibald: just a random spec question. Is there some clear documentation what is navigable and what is traversable navigable , and when is a navigable not traversable navigable? |
| 16:02 | <Jake Archibald> | @smaug:mozilla.org: from memory, the traversable is the thing that owns the history entries. So, an iframe is not traversable, because it's the top level that traverses. It'd be nice to have traversable iframes at some point, but they don't exist right now |
| 16:02 | <Jake Archibald> | Eg when you back() an iframe it's just telling the top level to go back (if it's allowed to) |
| 16:02 | <smaug> | But there is separately top-level traversable |
| 16:03 | <Jake Archibald> | Hmmmmm maybe I need to refresh my memory of the spec |
| 16:05 | <Jake Archibald> | https://html.spec.whatwg.org/multipage/document-sequences.html#top-level-traversables
|
| 16:05 | <Jake Archibald> | So yeah, it'd be "traversable iframes", if we ever get those, that would be traversables that are not top level |
| 16:05 | <smaug> | Ok, this is massively confusing. I guess need to get rid of some definition |
| 16:06 | <Jake Archibald> | I mean, I think traversable iframes would be massively valuable, but if folks want to remove that possibility from the spec now, sure |
| 16:06 | <smaug> | let's add definitions once they are needed for something |
| 16:07 | <smaug> | But ok, thanks for clarifying this |
| 16:08 | <Noam Rosenthal> | yea right now traversable navigable and top-level traversable are synonomous AFAIU |
| 16:08 | <smaug> | (I've read those same definitions every now and then and they are always just as hard to understand 😉 ) |
| 16:09 | <Noam Rosenthal> | When I need to touch that part of the HTML standard I start the day by saying "traversable navigable" three times in a row fast as a tooth-strengthening exercise |
| 16:12 | <Jake Archibald> | Is traverables vs navigables confusing? In that traversables have history state, and the intended position in history, whereas navigables just get told which history entry to use |
| 16:12 | <Noam Rosenthal> | I think we should do that. The standard is already complicated enough, it shouldn't have terms things that don't yet exist |
| 16:12 | <Jake Archibald> | The old model was definitely simpler but didn't really cover reality (and there was many bugs as a result) |
| 16:13 | <Noam Rosenthal> | It's two new 4-syllable words that are not in day to day use |
| 16:14 | <Noam Rosenthal> | Anyway, not suggesting to rename those terms, but it's indeed not easy |
| 16:14 | <Jake Archibald> | There may be better names out there for "thing that traverses" and "thing that navigates" |
| 16:14 | <Jake Archibald> | But I couldn't think of anything else that described that distinction |
| 16:14 | <Jake Archibald> | I agree it's a bit "thennable" |
| 16:22 | <Dominic Farolino> | In HTML yes. If you consider monkeypatched specs like fenced frames, then no. |
| 16:22 | <smaug> | That is chromium only thingie |
| 16:23 | <Dominic Farolino> | I'm aware :) hence my "if" condition haha |
| 16:24 | <smaug> | Dominic Farolino: oh, since you're here, did you see my comment about moveBefore 🙂 |
| 16:24 | <Dominic Farolino> | Does https://html.spec.whatwg.org/multipage/document-sequences.html#infrastructure-for-sequences-of-documents help a little with your original question? |
| 16:25 | <Dominic Farolino> | Yeah somehow I missed it until I saw it yesterday, so I will look into that asap. Thanks for the reminder. |
| 16:28 | <Noam Rosenthal> | I'd say that navigable is a document-view (as per the definition in the spec, it "presents a document") and traversable navigable is a root document view (which can still be a "fenced frame" and can be different than "top level" in monkey-patches). I think the fact that the document view can be navigated and the top-level view can be traverse is a property of the thing rather than a definition of the thing. We can probably come up with something even better but it's at least less jaw breaking |
| 16:35 | <Dominic Farolino> | annevk: In https://dom.spec.whatwg.org/#concept-node-remove, setting the boundary points of the live ranges is just manual here, right? We don't go through https://dom.spec.whatwg.org/#concept-range-bp-set do we? |
| 16:35 | <Dominic Farolino> | Seems like we should, and maybe that's the intent? But we don't link to that algorithm so it's unclear |
| 16:40 | <annevk> | Hmm. It seems clear that we don't go through that algorithm? Perhaps we should, but that seems like something that should be proven first in some manner. Not lead to claims that the current set of steps is unclear. |
| 16:42 | <Dominic Farolino> | It is clear we don't link to it, yeah. I thought there was a chance we might've intended to, but just failed to link to that algorithm is all. |
| 16:45 | <annevk> | I doubt that. "set the start or end" very much seems like something you'd invoke from a public method. |
| 16:51 | <annevk> | I guess the one caveat here is that those definitions post-date implementations, but are still pretty old going back to the early days of the modern DOM standard. So re-reviewing them and trying to find cases where those conditions don't hold up is prolly valuable work. |