2024-12-01 [22:36:14.0880] Curious, is it obvious to everyone that `importNode()` clones from its name? [00:52:28.0843] > <@annevk:matrix.org> Curious, is it obvious to everyone that `importNode()` clones from its name? No. It’s not *that* surprising but also not obvious I guess [09:17:25.0994] small community update from ada-url.com: we added URLSearchParams to Ada on v2.9.0. right now, I’m working on adding URLSearchParams to Ada’s Rust crate. https://github.com/ada-url/rust/pull/57 2024-12-02 [16:24:43.0976] Apologies if this is a common question -- I searched the FAQ but I don't _think_ I saw anything https://github.com/whatwg/html/blob/main/FAQ.md Is there a canonical representation of the HTML _spec_ as opposed to the IDL (for example, the spec would specify that the `type` on a `button` is an "enumerated attribute" as opposed to a DOM string [which the IDL says])? [16:25:25.0368] Certainly I could parse https://github.com/whatwg/html/blob/main/source and while it's not "hard" it's a non-trivial task [16:26:03.0816] * Apologies if this is a common question -- I searched the FAQ but I don't _think_ I saw anything https://github.com/whatwg/html/blob/main/FAQ.md Is there a canonical representation of the HTML _spec_ **in a machine readable-format** like XML or JSON as opposed to the IDL (for example, the spec would specify that the `type` on a `button` is an "enumerated attribute" as opposed to a DOM string \[which the IDL says\])? [16:26:24.0060] * Apologies if this is a common question -- I searched the FAQ but I don't _think_ I saw anything https://github.com/whatwg/html/blob/main/FAQ.md Is there a canonical representation of the HTML _spec_ **in a machine readable-format** like XML or JSON as opposed to the IDL (for example, the spec would specify that the `type` on a `button` is an "enumerated attribute" that can take "button" "submit", etc. as opposed to a DOM string \[which the IDL says\])? [16:27:35.0046] There are quite a few scattered efforts out there -- e.g. https://github.com/tawesoft/html5spec [16:28:16.0298] Certainly I would imagine MDN does this to prepare their documentation -- but it's not immediately clear to me how or if they do that without studying their build process a lot more [16:29:22.0421] * Apologies if this is a common question -- I searched the FAQ but I don't _think_ I saw anything https://github.com/whatwg/html/blob/main/FAQ.md Is there a canonical representation of the HTML _spec_ **in a machine readable-format** like XML or JSON as opposed to the IDL? For example, the spec would specify that the `type` on a `button` is an "enumerated attribute" that can take "button" "submit", etc. as opposed to the IDL, which specifies a DOM String [16:49:32.0692] if you want to parse `source`, you'd be best off using or extending wattsi https://github.com/whatwg/wattsi [17:34:01.0334] There is no such machine-readable format besides the source itself. [18:34:30.0205] >if you want to parse source, you'd be best off using or extending wattsi https://github.com/whatwg/wattsi That makes sense. I had a look at I am impressed it is maintained and in Pascal. I agree that parsing wattsi sources (and potentially using wattsi itself) makes sense due to the useful `dfn`tag especially. For example in the case of `button`, it is helpful that `dfn` holds context for attributes: ```
Keyword State Brief description
submit Submit Button Submits the form.
reset Reset Button Resets the form.
button Button Does nothing.
Keyword State Brief description
submit Submit Button Submits the form.
reset Reset Button Resets the form.
button Button Does nothing.
``` [18:36:54.0325] Although I don't have a specific suggestion in mind, are maintainers of `wattsi` open to contributions that would _extendi_ the language at all? I don't have anything specific in mind at the moment, but something that could potentially help the robustness of such a parser for subsequent updates to the standard. [18:37:02.0290] * Although I don't have a specific suggestion in mind, are maintainers of `wattsi` open to contributions that would _extend_ the language at all? I don't have anything specific in mind at the moment, but something that could potentially help the robustness of such a parser for subsequent updates to the standard. [18:37:08.0680] * Although I don't have a specific suggestion in mind, are maintainers of `wattsi` open to contributions that would _extend_ the language? I don't have anything specific in mind at the moment, but something that could potentially help the robustness of such a parser for subsequent updates to the standard. [18:42:30.0915] For example, I could envision a collection of tags that could be used to articulate each dom element, would retain searchability within `wattsi` sources, yet could reduce boilerplate. [18:43:25.0191] * For example, I could envision a collection of tags that could be used to articulate each dom element, would retain searchability within `wattsi` sources, yet could reduce boilerplate and enhance parseability. [18:43:32.0897] * For example, I could envision a collection of tags that could be used to articulate each dom element, would retain searchability within `wattsi` sources, yet could reduce boilerplate while enhancing parseability. [18:43:44.0784] * For example, I could envision a collection of tags that could be used to articulate each dom element, while retaining searchability within `wattsi` sources, yet could reduce boilerplate while enhancing parseability. [18:46:13.0250] * For example, I could envision a collection of tags that could be used to articulate each dom element, while retaining searchability within `wattsi` sources and could reduce boilerplate while enhancing parseability. [18:53:11.0417] Here is a very rough example: ```

The button element

Flow content, Phrasing content, Interactive content, Palpable content Listed, Labelable, Submittable, Autocapitalize-and-autocorrect inheriting Where phrasing content is expected Phrasing content, no interactive content descendant, no tabindex attribute descendant Global attributes disabled, form, formaction, formenctype, formmethod, formnovalidate, formtarget name, popovertarget, popovertargetaction, type, value For authors For implementers ... ``` [18:53:55.0408] I very much doubt it -- but appreciate your consideration [18:54:09.0748] * I very much doubt it -- but very much appreciate your consideration. [18:54:27.0348] * I would doubt it for many reasons -- but very much appreciate your consideration. [18:54:55.0775] [this isn't quite right -- but perhaps conveys the idea] [19:41:30.0542] Yes, we're quite open to that. Although it'd be even better if it could be done in the new Rust pre-processor layer, which is in a more well-known language and has nice things like unit tests. I'd be ideal if eventually we moved everything from Wattsi to Rust. See this example issue for one such project (not quite what you're looking for, but gives an idea): https://github.com/whatwg/html-build/issues/293 See here for the Rust layer: https://github.com/whatwg/html-build/blob/main/src/main.rs See here for some previous discussion of machine-readable stuff: https://github.com/whatwg/wattsi/issues/146 + https://github.com/whatwg/html/issues/1246 [21:35:29.0443] Thank you so much [21:36:04.0151] Is there openness to moving wattsi in its entirety over to Rust? ie matching the same existing spec [21:36:20.0191] * Aside: is there interest in moving wattsi in its entirety over to Rust? ie matching the same existing spec [21:36:31.0950] * Aside: is there interest in moving wattsi in its entirety over to Rust? for example, also matching the same existing spec [21:36:36.0421] * Aside: is there interest in moving wattsi in its entirety over to Rust? for example, also matching the existing spec [21:37:09.0048] * Aside: is there interest in moving wattsi in its entirety over to Rust? for example matching the existing spec [21:37:17.0375] * Aside: is there interest in moving wattsi in its entirety over to Rust? Matching the existing spec [21:37:26.0679] * Aside: is there interest in moving wattsi in over to Rust? Matching the existing spec [21:39:28.0150] * ~Aside: is there interest in moving wattsi in over to Rust? Matching the existing spec~ Edit: re-read, looks like yes > I'd be ideal if eventually we moved everything from Wattsi to Rust. [21:39:58.0946] [oh wow, I had no idea hixie worked on this back in the day.] [22:04:18.0942] Minor patch https://github.com/whatwg/wattsi/pull/164 [22:04:35.0089] * Minor patch https://github.com/whatwg/wattsi/pull/164 cc/ Domenic [05:24:49.0268] Small curiosity, can a node's children ever not be "in tree order"? Asking because at least in [node insert](https://dom.spec.whatwg.org/#concept-node-insert), it's asked to iterate over a DocumentFragment's children in tree order and that seemed redundant, but maybe it's not. [07:03:06.0023] No, that's just saying if you have a node with children [a, b, c], you should work on a first, then b, then c [08:08:08.0781] Ian Hickson: https://www.software.hixie.ch/utilities/js/live-dom-viewer/ doesn't seem to be responding [08:08:58.0514] I guess this could have been a dm, but maybe someone else knows or can help :) [08:09:29.0597] * I guess this could have been a dm, but maybe someone else knows something (like the host is generally having troubles) or can help :) [08:10:28.0727] * Ian Hickson: https://www.software.hixie.ch/utilities/js/live-dom-viewer/ doesn't seem to be responding (indeed your domain in general) [09:59:33.0761] If you’re all this payment method and you needs some cash 💵 just clink on my link and join my telegram group 👍👍👍👍🙏🙏 👇👇👇👇👇👇👇👇👇👇 Cashapp? Chime Apple Pay? pal? Venmo? BOA? Wells Fargo? Join my channel now Got any of these Chase? BOA? Wells Fargo? Navy federal? Capital one? Truist? Att &t? PNC? TD bank? Credit union? M&T bank? Santander bank? Northwest bank? Or any other local Bank JOIN MY CHANNEL NOW TO GET PAID!!✅ Join the telegram channel 👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇 https://t.me/+ioqje81ziAYyYTc0 https://t.me/+ioqje81ziAYyYTc0 👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆 @EVERYBODY @EVERYBODY @EVERBODY @EVERYBODY [10:40:36.0674] How do we want to handle https://github.com/whatwg/html/pull/10557 ? It looks like the boxes in OP are ticked, but it's not clear if it's web compatible yet, and there was at least one crbug filed about (https://issues.chromium.org/issues/379612186) cc annevk (For https://issues.chromium.org/issues/379034733#comment6 , that should be fixed in the spec PR, but maybe not yet in chromium) [14:33:49.0232] > <@ms2ger:igalia.com> No, that's just saying if you have a node with children [a, b, c], you should work on a first, then b, then c Ok, but given that a node's `children` is already an ordered set, it's thus redundant to iterate it in tree order, no? Unless its order is something else than tree order. [14:56:28.0498] > <@zcorpan:mozilla.org> How do we want to handle https://github.com/whatwg/html/pull/10557 ? It looks like the boxes in OP are ticked, but it's not clear if it's web compatible yet, and there was at least one crbug filed about (https://issues.chromium.org/issues/379612186) cc annevk > > (For https://issues.chromium.org/issues/379034733#comment6 , that should be fixed in the spec PR, but maybe not yet in chromium) Maybe jarhar can give us an update on the shipping plans? Is Chromium still proceeding to ship exactly what's in the PR? I think it might be reasonable to delay landing until it's baked in stable for a while, but we could also land and revert if it's not able to make it. 2024-12-03 [01:22:11.0977] > <@kaiido:matrix.org> Ok, but given that a node's `children` is already an ordered set, it's thus redundant to iterate it in tree order, no? Unless its order is something else than tree order. I'm not sure I follow your question - the children are ordered, and you should iterate over them in that order. You might imagine in some case you'd want to iterate over them in reverse order, or in other cases it might not matter at all [01:35:42.0132] Yes, so my point is that in at least [node insert](https://dom.spec.whatwg.org/#concept-node-insert), at step 7, it's asked to iterate over `children` in tree order. That made me wonder if `children` could ever not be in tree order, since it's already an ordered set (which I assume is already in tree order). So either this "in tree order" at this step is redundant, either `children` can indeed be in an other order. [01:39:55.0067] * Yes, so my point is that in at least [node insert](https://dom.spec.whatwg.org/#concept-node-insert), at step 7, it's asked to iterate over `children` in tree order. That made me wonder if `children` could ever not be in tree order, since it's already an ordered set (which I assume is already in tree order). So either this "in tree order" at this step is redundant, either `children` can indeed be in an other order. Ps: I'm fine with it being redundant, that's really just something that got me curious. [02:02:29.0178] I don't understand. It's not a question of whether children is in tree order or not; it's a question of the order in which you handle them [02:03:32.0176] Say you have a tree `` and you say "for each child x of the a element, print the local name of x", you could print either "bi" or "ib" [02:04:29.0472] The default order for this ordered set is "tree order" so it's redundant, but it's good to be explicit as sometimes iterations don't care about order [02:33:04.0553] Thanks Noam. That's just what I wanted to know, and yes, I agree it's good to be explicit here. Sorry Ms2ger I wasn't clear enough. [02:35:15.0378] zcorpan: Domenic: yeah, I'd like to hear from jarhar before moving ahead. And given that there's already been some fallout maybe we should at least give it a couple of weeks of shipping. [02:37:34.0519] Noam Rosenthal: Kaiido: when it's just children we might be able to omit the term these days, but when it's descendants we can't. That we can omit it for children is new as we didn't define their data structure until quite recently and I didn't actually think it had implications when I did that. So maybe this is something to open an issue for and figure out what we want to do. [06:01:31.0175] zcorpan: see also https://github.com/whatwg/html/issues/10310#issuecomment-2506360351 btw on `