2026-07-01 [01:20:36.0283] I've made a rough refinement proposal to the platform provided behahviors after the hackfest WHATNOT, I wonder what people think https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1353 (e.g. keithamus Luke Warlow might be interested) [01:23:13.0604] Tl;dr is to have `activationBehavior` and potentially other discrete "types" of behavior in the future. Different types of behavior can compose with each other, but each type has its own notion of what's mutually exclusive (e.g. link and button are two discrete types of activation behavior) [01:23:39.0936] * Tl;dr is to have `activationBehavior` and potentially other discrete "types" of behavior in the future. Different types of behavior can compose with each other, but each type has its own notion of what's mutually exclusive (e.g. link and button are two mutually exclusive activation behaviors) [01:37:02.0348] A similar proposal was raised by microsoft around... 2023 TPAC maybe? I am personally against the idea of static members. I don't think they're very readable, I think string values are messy and easy to make mistakes with (and silently fail if you typo either the name or the value). This also doesn't represent the same semantics as the proposed elementinternals, which is that this isn't then switchable at runtime. [01:37:31.0554] The static vs. attaching as internal thing is not the main idea [01:38:03.0567] The main idea is the concept of a `activationBehavior`? [01:38:25.0648] Yes, the concept that behaviors are clustered by type rather than in a general purpose array [01:38:51.0395] I'm OK with attaching them in runtime, e.g. only when an element is disconnected or with some other constraint or whatever [01:38:58.0481] So we go from 1 vector member to N scalar members? [01:40:09.0180] For now, 1 scalar member (activation), and every increase in N is speced [01:40:59.0818] What shape is `ElementInternals.prototype.activationBehavior` in this case? It seems it would have to be a superset of all possible activation behaviours? i.e. it needs `href`, `formAction` and so on? What if I set `activationBehavior = 'link'` then set `internals.activationBehavior.formAction = 'POST'`? I guess nothing happens? [01:43:02.0680] We can bikeshed on that but if it was static I think `activationBehavior` can return a `LinkBehavior` interface etc. we can find a shape for it if it's not static, e.g. ``` internals.activationBehavio.setLink({href: "/example"}); internals.activationBehavior.setSubmit({formData: "POST"}); ``` [01:43:52.0631] I'm curious - as a thought experiment, how would you solve this in C++? Like if I said to you "we have HTMLButtonElement, we have HTMLLinkElement, we need a new element which is sometimes a button and sometimes a link", what would be the general shape to solve this? [01:44:26.0200] std::variant ? [01:44:43.0165] Or an interface that both implement (old school polymorphism)? [01:45:41.0933] A variant/union is a very established concept [01:45:52.0234] I imagine I would move their activation behaviours into a mixin, and have them both apply their respective mixins, then have the new element call one or the other. [01:46:50.0020] Yea sure, that's a different flavor of polymorphism [01:47:44.0797] At any rate; I don't want to make JS into C++, but it seems the solutions we have for C++ significantly diverge from the solutions we're proposing for JS. [01:48:44.0428] I don't think so? how is `activationBehavior: "submit" | "link"` different from `std::variant behavior_" [01:48:53.0252] * I don't think so? how is `activationBehavior: "submit" | "link"` different from \`std::variant\ behavior\_` [01:49:40.0789] When I develop this in C++ I could have multiple options but I would usually try to make the types statically reflect what's possible rather than have a bunch of runtime conflict resolution/error scenarios (which is what an array can lead to) [01:50:17.0156] Right but you don't do that by adding static members that assign/return strings, right? [01:51:10.0097] I can't help but feel like if JS had some better intrinsics (i.e. mixins) we perhaps wouldn't be having this conversation, because the solution would be more apparent. [01:51:38.0077] The "effective type" of a variant is an enum, and enum in JS is a string [01:52:30.0991] Also C++ doesn't really have mixins. You can do multiple inheritance but that's considered something you need to be very careful with [01:54:26.0747] Anyway I think we can solve the issue people have with providing platform-like behaviors (specifically button/link-like) to their own custom elements without having to invent new language features [01:54:35.0754] Why is the effective enum in JS a string? Most languages its a number, and a lot of the older DOM code has numeric enums, with static const aliases. [01:56:30.0526] FTR I'm not advocating for `associatedBehaviour = 1` any more than `"button"`. I think both have all the same problems; which are second-order to the variant issue. Namely, that we can't really throw or tell the developer they got this wrong if it's a static member. If it's not a static member though, you inherit all of the runtime difficulty you're wanting to move away from. [01:56:37.0422] Because as an interpreted language, strings in JS are not more expensive than constant numbers. And they're much easier to extend than numeric enums [01:59:02.0976] ``` const submitBehavior = new SubmitBehavior(); // Throws if element is connected element.internals.activation = submitBehavior; submitBehavior.formAction = ``` [01:59:12.0794] I'm also not suggesting we invent new language features. More just lamenting at the current state of JS, I suppose. Like for example if decorators were actually shipping in JS engines, I'd imagine there'd be some proposal around built-in decorators for this. [01:59:27.0537] * ``` const submitBehavior = new SubmitBehavior(); // Throws if element is connected element.internals.activation = submitBehavior; submitBehavior.formAction = "POST" ``` [01:59:59.0851] Yea I think I never liked either mixins or decorators TBH. They both create an implicit processing model. But it's a matter of taste [02:01:18.0006] If people want to develop in that kind of way in user space it's fine, but I think that as the platform we can be more conservative and provide the minimum needed functionality in a concise way. What I don't understand yet is why and how those behaviors need to be composed with user-defined behaviors and are they even on the same dimension [02:04:54.0006] I think providing a mechanism that users can build their own in userland helps developers understand how the feature works, and also means there's less gymnastics when it comes to polyfills, which helps with feature adoption. [02:06:36.0693] Polyfills aside, I get that sort of conceptually but none of the explainers show how this works in practice and I fail to understand how putting platform behaviors in an open-ended array helps users build their own behaviors in userland. [02:07:25.0188] It also *does not* explain how the platform works - because it creates a bunch of error conditions that you need to read the spec to understand [02:07:57.0443] In the platform you likely have only one activation behavior, so allowing you to put several in an array un-explains it [02:08:40.0235] I don't disagree but I think the array came from the idea that developers will combine behaviours, e.g. the button/link case. [02:11:24.0205] behaviors are still combinable here, e.g. activation and replaced-content can be separate behaviors. Then we can decide if "link" is mutually exclusive from button or not, and then it can be "buttonBehavior" and "linkBehavior" (what happens when you click it though?). I think allowing a "link-button" in one element is more harm than good but I can be persuaded otherwise [02:13:25.0742] If the platform can safely provide a "button link" by combining those two behaviors, then absolutely they should be composed in this API. My impression from the use cases is that this type of composability is more of a neat idea than something that's actually sought out [02:35:15.0145] https://github.com/whatwg/html/pull/12642 [02:36:51.0921] Ugh, thanks Element for not notifying me about all these responses. :( [02:38:34.0831] I don't think it makes sense to design individual web platform features to be polyfillable, but I think it's defensible as a goal that the platform should provide the low-level primitives that make polyfilling viable a whole. There are gaps that affect both polyfills occupying the same namespace or ponyfills. For example: - CSS polyfills currently require refetching and reparsing the entire stylesheet, making individual polyfills effectively unviable - HTML polyfills that work correctly across shadow DOM boundaries are practically impossible to implement performantly because of the lack of hooks to monitor (even open) shadow roots, monitor mutations across shadow roots, or fetch elements that match a certain pattern across shadow roots. [02:40:03.0161] > <@keithamus:matrix.org> FTR I'm not advocating for `associatedBehaviour = 1` any more than `"button"`. I think both have all the same problems; which are second-order to the variant issue. Namely, that we can't really throw or tell the developer they got this wrong if it's a static member. If it's not a static member though, you inherit all of the runtime difficulty you're wanting to move away from. Just to re-iterate the current design doesn't solve essentially any of the runtime 'issues' and I think they're exaggerated. [02:40:37.0185] I can see the argument that polyfills may reduce motivation for browsers to implement a feature natively, but polyfills encourage authors to use a standardized feature, which *increases* motivation for browsers to implement. I don't think it's clear-cut which of these forces prevails in the end, but historically I'd say polyfills have helped drive implementations rather than discourage them. [02:40:50.0691] * I can see the argument that polyfills may reduce motivation for browsers to implement a feature natively, but polyfills also encourage authors to use a standardized feature, which _increases_ motivation for browsers to implement. I don't think it's clear-cut which of these forces prevails in the end, but historically I'd say polyfills have helped drive implementations rather than discourage them. [02:42:16.0544] Fwiw I still lean towards a truly dynamic rather than static or one time dynamic system [02:44:26.0783] Ponyfills are helpful, especially for cases where they can be close enough to the final API ergonomics (the `` vs `` example mentooned above). But their appeal is weaker. The core appeal of polyfills is that you can use a modern feature in browsers that support it, with the benefits of performance, correctness, etc. and you can later simply remove the scaffolding and you're left with something that **works**. If you lose that promise, the benefit is unclear. You may as well just use a userland library which has fewer constraints and moves faster. [02:44:37.0300] * Ponyfills are helpful, especially for cases where they can be close enough to the final API ergonomics (the `` vs `` example mentioned above). But their appeal is weaker. The core appeal of polyfills is that you can use a modern feature in browsers that support it, with the benefits of performance, correctness, etc. and you can later simply remove the scaffolding and you're left with something that **works**. If you lose that promise, the benefit is unclear. You may as well just use a userland library which has fewer constraints and moves faster. [02:49:57.0237] I agree that sometimes speculative polyfills have jumped the gun, but even then, the risks of authors experimenting with a speculative API using a polyfill are far smaller than browsers shipping the API only to later find that it doesn't cater to author needs to the extent that was anticipated. JS has always allowed polyfills with absolutely no restrictions on namespace, and historically cases like smooshgate or the more recent scoped registries one are still few and far between, and IMO do not outweigh the benefits the platform got in the same timeframe from the existence of polyfills as a whole. [02:50:03.0091] Yea none of this change is opinionated about dynamism/mutability. I don't have a strong opinion on that. I suggested "only change when disconnected" but it's orthogonal [02:56:25.0720] > I would much rather people write a library that demonstrates the need for something > I see "library that implements some feature" and "polyfill" as synonymous, but I can also see that fails to capture everything. The psychology of the two is completely different. One is introducing another dependency and all the risk-benefit and comparative evaluation that comes with that. The other is simply bridging a gap temporarily, with the intent of being removed later. You're no longer need to evaluate whether an API meets your needs, and can swap one implementation for another with no integration effort. Basically, you get the API benefits of standardization, even before you get the implementation benefits. [03:01:37.0756] Anyhow, my takeaway from reading this discussion (and from some private discussions over the last few days) is: * it does not appear to be committee consensus that pollyfills are undesirable though we recognize it's a tradeoff and not without costs * there are some views that ponyfills might be a better solution * speculative polyfills of still in-design APIs are have a worse cost-benefit than polyfills of mature features * it's less clear to what extent we consider making their existence possible a standards goal. Please correct me if you feel this is inaccurate. [03:09:49.0842] https://github.com/whatwg/html/pull/12643 [07:25:21.0813] Shannon Booth: so https://github.com/whatwg/html/pull/12624 works, right? I'll do another round of editorial review. [08:11:42.0849] Actually I think I spotted something when I worked on the follow up - we need to adjust to the root insertion target also when inserting non-elements. So I'll make that revision together with the editorial changes [09:00:50.0100] Shannon Booth: I wonder how this didn't come up in testing [09:01:13.0977] (side note: I love that ladybird even gives us this testing ability in the first place) [10:04:54.0632] Hi all, just a friendly reminder to post any discussion topics for NEXT Thursday's joint CSSWG/WHATWG/OpenUI task force meeting to the meeting agenda issue: https://github.com/whatwg/html/issues/12620 (I'm sending this a week early, because I'm out next week.) [10:06:21.0761] OK should be good now (also fixed nits) [10:37:09.0312] Oops! This bit of the parser didn't match the spec very closely (and is quite close to FFI glue), so I probably just missed some portions where it was adjusting the position where the spec wasn't. Also possible the coverage I was running didn't catch it perhaps [10:44:09.0613] But yeah, works well, hopefully also helps with the sanitiser stuff [11:17:12.0378] Though from auditing some WPTs, I do suspect there are some other issues. For example, looks like the fragment parser for the outer HTML setter might need to be passed the element which is created rather than parent based on https://github.com/web-platform-tests/wpt/blob/master/html/webappapis/dynamic-markup-insertion/the-outerhtml-property/outerhtml-documentfragment.html Seems unrelated to these improvements though 2026-07-02 [23:53:10.0971] Shannon Booth sideshowbarker want to review https://github.com/whatwg/dom/pull/1477? [00:29:52.0397] I pushed some nits, but I think this latest iteration needs some more work. [00:50:17.0801] left a comment about one extra deviation we have in place, though I think it is separate [00:56:31.0864] Oops looking at it again it was a bit sloppy in terms of style. sorry about that. Fixing now. [01:31:45.0040] Should be ready for another look. I fixed all the style regressions. [02:40:29.0245] Seems like WATTSI is giving a 503 (https://github.com/whatwg/html/pull/12624), anything to do when that happens? [03:13:52.0566] ok seems to be fixed the 3rd time [04:39:32.0401] Shannon Booth: hello again, I think https://github.com/whatwg/dom/pull/1479 should fix that NodeIterator issue. If you know of a less involved fix I'm all ears. [05:06:54.0126] ha not sure why specfmt didn't catch any of these wrapping thing. I couldn't see them myself with the naked eye [05:12:46.0020] It's really easy to find them when you look through the complete diff on GitHub and don't see the text lining up. [05:14:10.0683] I guess I shouldn't say easy, but it's definitely possible. [05:15:55.0160] yea I think I forgot to click "Refresh" in the diff view so I was seeing a previous version [05:16:26.0652] (also maybe over-relying on specfmt which was so far rather dependable) [05:23:29.0105] But then you should notice that as you read through it surely as it doesn't contain all changes? Your turnaround is quick, but I feel like I spend a lot of time on nits with your PRs. [05:24:28.0584] That's fair feedback, I always try to improve. [06:33:57.0386] Anyway, for this PR I've now triple-checked everything for nits and I think we're good [07:05:00.0085] Another realization: Authors generally want to use the native behavior when it exists. Fundamentally, *that* is what "tramples all over our design flexibility", not polyfills. Even without a polyfill, authors will use feature detection and use the native functionality if it exists, and fall back to their own code only if it doesn't. This can be done in a userland wrapper, a build tool, or even add hoc per usage. Polyfills are simply abstractions to make this pattern more ergonomic for consumers, whereas a userland wrapper introduces one more level of indirection. IMO, by not working on primitives that make good polyfills possible we do not preserve our design flexibility, we just get a buggier Web… [08:08:23.0733] Noam Rosenthal: for https://github.com/whatwg/dom/pull/1478#pullrequestreview-4617350032 what happens if you clone a document and then `document.open()` it? This will give different results depending on how implementations track this state. [08:09:11.0246] Noam Rosenthal: you probably don't even have to clone it depending on when a new parser is allocated. [08:10:43.0977] Right so I think you change the document open steps so they always set this to true. Which means that an XHR document with `document.open()` called on it will now do something different. At least specification-wise. Right? [08:14:57.0286] Right! That edge scenario is untested and the PR changes the behavior. Though I'm not sure what the correct behavior is. I think `document.open()` always allowing (or not allowing) DSD regardless of where the document came from makes more sense(TM) when you think of what this flag comes to protect against. [08:15:44.0426] I think I agree it's fine, but we should be intentional about it in terms of tests and eventual commit message. [08:16:40.0035] Absolutely. I'll add a test for this scenario and update the commit message. I didn't know about the XHR subtlety (probably because it's not tested and I'm not sure if blink does the spec'ed thing there...) [08:28:14.0152] annevk: Ah actually blink *does* keep this flag for non-fragment parsing and it affects `document.write()` in those scenarios like XHR (also `document.implementation.createHTMLDocument`). So I think we should keep this flag in DOM but stop override it when it's the fragment parser rather than rely on the state of the inert document. I'll revise the HTML PR [08:28:51.0465] We can later think of changing the behavior but the goal here was to better spec current behavior so lets start with that [09:48:31.0157] OK I updated the PR and commit description, as well as a link to a test that verifies what happens with `document.open()` after `XHR` 2026-07-03 [23:32:57.0195] Luke Warlow keithamus https://github.com/whatwg/html/pull/12184 is mainly about aligning with implementations right? Any reason not to fill out OP accordingly? Curious what prevents us from landing that. [00:05:49.0744] > <@annevk:matrix.org> Luke Warlow keithamus https://github.com/whatwg/html/pull/12184 is mainly about aligning with implementations right? Any reason not to fill out OP accordingly? Curious what prevents us from landing that. There is some implementation change so we do need browser bugs and so we do also need implementor interest. [00:06:27.0859] Consider Mozilla interested [00:06:38.0557] I think I also raised a ticket [00:31:59.0526] Luke Warlow: those changes seem fine for WebKit as well [13:14:51.0001] > <@annevk:matrix.org> Luke Warlow keithamus https://github.com/whatwg/html/pull/12184 is mainly about aligning with implementations right? Any reason not to fill out OP accordingly? Curious what prevents us from landing that. Filled that out now, thanks Keith for raising the browser bugs. 2026-07-04 [05:29:36.0459] I still think this is the solution πŸ˜… https://x.com/LeaVerou/status/1821316779886403721 [07:37:38.0064] is https://privacycg.github.io/storage-partitioning/ the most up to date place to read about partitioning? [07:50:02.0362] This really needs to be better integrated into existing specs. [07:52:19.0769] Yeah, I'm trying to figure it out a little at the moment how things are meant to be keyed. [07:53:13.0863] I know various WPTs are marked non tentative for it, like for web storage as all engines implement, but afaik it's currently in implementation defined area 2026-07-06 [19:22:34.0110] Thought I'd share this here: A while ago I wrote a user script (I use it through tampermonkey) that inserts the section name you're on into the tab title on any WHATWG specs: ```js // ==UserScript== // @name Web Spec Title Machine // @version 2026-02-26 // @description current section of web specs in the page title // @author Psychpsyo // @match https://*.spec.whatwg.org/* // @grant none // ==/UserScript== const titleElem = document.querySelector("title"); const originalTitle = titleElem.textContent; function putFragmentIntoTitle() { if (location.hash) { titleElem.textContent = `${location.hash} - ${originalTitle}`; } else { titleElem.textContent = originalTitle; } } putFragmentIntoTitle(); window.addEventListener("hashchange", putFragmentIntoTitle); ``` [19:26:27.0215] I wish [00:45:16.0810] Noam Rosenthal: I'm making more changes to your refactor PR, still quite a bit was wrong [00:46:37.0411] Noam Rosenthal: I realized that `Document.parseHTML()` and friends also have to continue to change the document state as otherwise we are impacting what a subsequent `open()` call would do. [00:56:08.0642] Okay, I think it's good now but maybe Shannon Booth can have another look. Another thing I wanted to do once this lands is to turn concept-frag-parse-context into a "fragment context" concept that the parser holds. Then the parser can also branch on that (non-null) to detect if it's doing fragment-based parsing. [01:09:57.0971] > <@annevk:matrix.org> Noam Rosenthal: I realized that `Document.parseHTML()` and friends also have to continue to change the document state as otherwise we are impacting what a subsequent `open()` call would do. Ah yes of course. I am going to open an issue to change this behavior so it only relies on the parsing method rather than on something that sticks to the document [01:11:15.0606] > <@annevk:matrix.org> Okay, I think it's good now but maybe Shannon Booth can have another look. Another thing I wanted to do once this lands is to turn concept-frag-parse-context into a "fragment context" concept that the parser holds. Then the parser can also branch on that (non-null) to detect if it's doing fragment-based parsing. Yea I was thinking the same about the context. I have a few pending PRs but after that I want to make the whole parser instance modern including that [06:06:58.0089] annevk: FWIW, the reason I haven't looked at https://github.com/whatwg/dom/pull/1470 is that I've been waiting for a proper proposal for the whole thing. [06:07:07.0652] * annevk: FWIW, the reason I haven't looked at https://github.com/whatwg/dom/pull/1470 is that I've been waiting for a proper proposal for the whole thing, I mean OpaqueRange [06:14:08.0288] smaug: happy to wait. I have the HTTP Workshop next week and then vacation so I won't be able to work on it until mid-August anyway. [07:24:35.0772] I'd say `customElementRegistry` was more like speculative polyfilling where a userland feature was made to look like a prospective future standard, no? Rather than an actual polyfill of something that's spec'ed but not yet baseline? [07:25:06.0705] It would be good to have some guidelines/postmortem about it with examples. Perhaps a good TPAC conversation [10:33:35.0975] πŸ‘‹ I've been looking at parsing _Processing Instructions_ an have a few notes/questions: - I notice that the token is not handled in the "in head noscript" insertion mode, unlike most other modes where it seems to align with comment tokens. Is that intentional? - The fragment serialization for PI is potentially lossy: `` has data `d?`. Following the serialization instructions would produce `` (`>` is the serialization closer, not `?>`) which now has the data `d`. [10:36:24.0524] Happy to open issues for either of these if neceesary. [10:37:23.0569] * πŸ‘‹ I've been looking at parsing _Processing Instructions_ an have a few notes/questions: - I notice that the processing instruction token is not handled in the ["in head noscript" insertion mode](https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inheadnoscript), unlike most other modes where it seems to align with comment tokens. Is that intentional? - The [fragment serialization](https://html.spec.whatwg.org/multipage/parsing.html#serialising-html-fragments) for PI is potentially lossy: `` has data `d?`. Following the serialization instructions would produce `` (`>` is the serialization closer, not `?>`) which now has the data `d`. [10:42:47.0032] Related, I opened a [WPT PR for the PI node tree construction tests](https://github.com/web-platform-tests/wpt/pull/61085) because I noticed the recently added tests do not follow the specified format. Since either the specified format or the tests need to be updated, it seems like there's an opportunity to update the WPT format for PI. Comments appear as `` - they _always_ have a space inside the comment open/close. PI nodes could serialize this way as well in the tree construction tests, for example ``. I like the alignment with comments, and it helps to make it clear what's data and what is part of the tree syntax, like in the case above with the `??>` closers. [10:57:28.0191] For the "in head noscript" insertion mode, this would fall through to the anything else clause, effectively moving into "in head" and inserting the PI. [11:06:03.0374] Processing instruction tokens are also missing from the ["in template" insertion mode](https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-intemplate). In that case, there's _no_ "anything else" clause, PI tokens just aren't handled. I suppose PI in templates should be handled the same a comment and "Process the token using the rules for the 'in body' insertion mode." [11:59:28.0348] > <@noamr:matrix.org> I'd say `customElementRegistry` was more like speculative polyfilling where a userland feature was made to look like a prospective future standard, no? Rather than an actual polyfill of something that's spec'ed but not yet baseline? Yea 2026-07-07 [18:52:11.0939] <0x4261756d> The tree_construction tests suggest that they should be processed using the rules for 'in body', at least they pass when doing that. [18:56:22.0251] <0x4261756d> The tree_construction part is resolved thanks to https://github.com/web-platform-tests/wpt/pull/61085. Only the tokenizer tests remain broken [06:43:22.0690] I opened a PR for this: https://github.com/whatwg/html/pull/12653 [08:00:08.0543] Shannon Booth: curious if Attr in ranges came up in Ladybird as apparently there was no real test coverage. I created some over at https://github.com/web-platform-tests/wpt/pull/61121 [09:32:46.0910] I'm not 100% sure what you mean, but we pass those tests too [09:38:04.0079] But StaticRange indeed throws per spec [09:44:25.0289] Shannon Booth: just wondering if it was problematic that there was no test coverage. I guess maybe not. It does seem like the spec is adequate. [09:47:06.0685] Ah! Yeah I think we just got the behaviour for free due to inheritance 2026-07-08 [22:45:56.0258] Anyone interested in some DOM editorial review? https://github.com/whatwg/dom/pull/1484 [23:20:00.0000] > <@annevk:matrix.org> Anyone interested in some DOM editorial review? https://github.com/whatwg/dom/pull/1484 Can get to it in a few hours [03:17:24.0576] Done [05:50:43.0651] Thanks! [06:35:28.0935] I keep reading `moveBefore()` wrong. [06:37:24.0408] It's lost all meaning to me I've read it all so much now. [06:37:44.0227] wrong in the sense of what the receiver/arguments are? [06:37:55.0704] cause that confounds me every time [06:39:16.0545] Yeah logically based on name I'd expect the caller to be the thing that moves. [06:39:24.0857] Yea it was supposed to be consistent with `insertBefore` with the thought that we would add move semantics to the other verbs in the future [06:39:34.0867] But the DOM APIs all follow this weirdness so consistency is probably best [07:34:13.0664] my attempts to sneak a preference for smalltalk function naming conventions into the TAG design principles failed. ;-) [07:35:10.0992] (in particular, I think smalltalk has a practice where function names are actually split up and the arguments placed in between the parts of the name, so a function called moveBefore would clearly have the thing you move as the first argument and the thing it's before as the second argument [07:35:31.0347] * (in particular, I think smalltalk has a practice where function names are actually split up and the arguments placed in between the parts of the name, so a function called moveBefore would clearly have the thing you move as the first argument and the thing it's before as the second argument.) [07:38:38.0703] * (in particular, I think smalltalk has a practice where function names are split up and the arguments placed in between the parts of the name, so a function called moveBefore would clearly have the thing you move as the first argument and the thing it's before as the second argument.) [08:03:06.0808] But this follows those principles right? However, I keep thinking we're moving **this**. [08:11:27.0826] I feel the same when I use `insertBefore`, apart from already being used to it because it's old. [08:11:47.0422] Maybe adding `moveReplaceChildren`, `moveAppend`, `movePrepend`, `moveReplaceWith` will help here [09:08:24.0569] yeah, I guess this does follow those principles. I never remember, I just have to look it up if I want to use insertBefore or moveBefore. Or I can use Element.before() or Element.after() without looking it up. [11:11:12.0072] Consider the sentence (in HTML 4.11.3.5) "The Label of the command is the value of the option element's label attribute, if there is one, or else the option element's descendant text content, with ASCII whitespace stripped and collapsed." which I'll abbreviate as "X is A, or else B, with C." So, on the face of it, there's an ambiguity as to whether the "with C" applies to "A or B", or just "B". Is there a rule that tells me which is the intended/correct parse? [11:16:50.0063] I don't know that there's a good general rule -- but in this case I think it's probably just B. [11:17:53.0790] the spec could probably use a `
` here. [11:19:26.0585] ```
If the option element has a label attribute
the value of that attribute
otherwise
the option element's descendant text content, with ASCII whitespace stripped and collapsed ``` [12:08:09.0721] Yeah replacing this with a simple algorithm seems like the way to go [12:08:47.0528] Though I cannot say for sure which interpretation is correct. If commands are implemented we could at least test [13:04:58.0459] The existence of code like: Chrome: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/html_option_element.cc;l=245-258;drc=b862710ed46fb3be9921820e0c12002b2ac65017 Firefox: https://searchfox.org/firefox-main/rev/0088392ab4ccab730743ed188ddec62d04e578b7/dom/html/HTMLOptionElement.h#77-87 https://searchfox.org/firefox-main/rev/0088392ab4ccab730743ed188ddec62d04e578b7/dom/html/HTMLOptionElement.cpp#219-238 suggests that it's just B. (I didn't check that that code is actually used for the spec quote above, but it seems pretty likely.) [16:55:51.0864] dbaron: Thanks for the links. I tried and failed to find something similar for Ladybird. I also tried and failed to find tests of the functionality in WPT. 2026-07-09 [21:35:40.0244] I wonder if we can just make it point to a concept on the option element. But clarifying it’s B seems fine for now [01:04:45.0368] FYI: WHATNOT started [02:38:44.0605] foolip: could you rebase https://github.com/whatwg/html/pull/11818 perhaps? Perhaps my last commit clashed somehow? I noticed we were using the wrong target definition for Sanitizer and fixed that; might be your PR is impacted as well [02:38:50.0351] still trying to remember where heading offset was discussed... I remember the room, and I think wasn't Anaheim, but some nicer place. Probably Sevilla? [02:39:34.0713] Yes, https://github.com/whatwg/meta/issues/284. And now the notes... [02:42:29.0089] > Joey: I'm in favor of just walking the flat tree. > Anne: no, it's not the flat tree > Keith: is it shadow-including ancestors? [02:42:30.0663] lol [02:53:24.0070] annevk: what was the DOM pr/issue number you mentioned, which wasn't on the agenda [02:55:24.0600] smaug: https://github.com/whatwg/dom/pull/1486 [03:11:48.0230] yeah, can't really figure out why it was added https://github.com/whatwg/dom/issues/744 [03:11:53.0888] But removing sounds good [03:13:49.0380] smaug: from what I recall I (we?) wanted ShadowRoot and DocumentFragment with host to be more consistent with each other [03:14:36.0666] yeah, could be that consistency bit [03:15:00.0286] But since no one ever implemented that, removing is ok [04:46:37.0660] smaug: I added you to the group of people who have write access to all spec repos. The main effect of this is that your review checkmark will now be green. (Which then will also allow people to merge based on that as the main branches typically require a PR + review although some allow admins to merge without review.) [04:47:52.0237] Now the important question is that what was the color before? [04:48:01.0787] * Now the important question is that what was the color before, if not green? [04:52:08.0103] I wanted to post a screenshot, but it seems that GitHub changes the checkmark retroactively. Which seems quite wrong. [04:54:00.0878] * I wanted to post a screenshot, but it seems that GitHub changes the checkmark retroactively. Which seems quite wrong. Found one: [04:57:10.0055] Black coral [05:19:59.0772] By the way, it seems that TC39 has moved away from coercion except for booleans. So we should probably do it as well. Kinda silly as I'm pretty sure we added coercion for consistency with JavaScript. [06:29:28.0068] annevk freddy : can I enlist WebKit/Gecko as interested in "sanitize while parsing"? the only observable behavior of that is text node coalescing but some follow up fixes (e.g. sanitizer DSD support) rely on that. also does that need its own implementation bug opened? [06:30:21.0960] (https://github.com/whatwg/html/pull/12645) [07:49:51.0806] Yes, no for WebKit; ?, probably yes for Gecko [07:50:18.0728] I'm pretty sure we established ? is yes for Gecko too. [07:50:24.0754] * I'm pretty sure we established ? is yes for Gecko too [08:11:41.0245] annevk: we're discussing https://github.com/w3c/csswg-drafts/issues/14143 in the openui/csswg/whatwg joint meeting right now. [08:18:06.0790] "yes, no for WebKit"? sounds like "yes"? [08:18:35.0096] Ah "no" for opening a specific bug, gotcha [08:39:27.0977] Sorry, had to run an errand. That's why I left a comment. [10:08:17.0491] Hey I'll go to TPAC in November by train+ferry from the netherlands (NL-BE-London-Wales). If anybody along that path (or from around Paris, or western germany) wants more info or to join me rather than flying, react to this message or DM me :) [10:08:37.0891] * Hey I'll go to TPAC in October by train+ferry from the netherlands (NL-BE-London-Wales). If anybody along that path (or from around Paris, or western germany) wants more info or to join me rather than flying, react to this message or DM me :) [10:41:27.0214] unlikely to be at TPAC but i love that you're still doing that [15:23:24.0072] In https://html.spec.whatwg.org/#updating-the-image-data, there's a sentence that begins with "That task, and each subsequent task," and contains "if image request is the current request". Does that if-test happen when the task is queued, or when it runs, or something else? 2026-07-10 [22:09:12.0036] jmdyck: has to happen while it runs for it to make sense. It would be clearer if it had the same "must additionally run this step" language as the paragraph below. [03:46:25.0236] What if we just moved the "if" clause to after the "must"? [03:50:31.0888] jmdyck: sounds okay [05:46:17.0670] smaug: I found a fun edge case while going through DOM issues: https://github.com/whatwg/dom/issues/977#issuecomment-4935401092 [05:52:21.0561] annevk: inner is some window, I assume [05:53:43.0391] annevk: what do other browsers do? [05:54:00.0109] (and Gecko should create wrapper when adopting these days. It just recently changed) [05:55:28.0119] smaug: Chrome and Safari happen to pass that specific test, but fail a bunch of others from the PR. And if I make WebKit have Gecko-like behavior it'll fail that test. Are you saying that creating wrappers on cross-document adoption is not a perf pitfall I should be afraid of? [05:58:13.0767] We basically had to change behavior because of webcompat. Oh, but we missed something here [05:58:57.0702] emilio: [05:59:04.0153] (This is a very recent change) [05:59:21.0757] smaug: are you talking about Gecko no longer mutating the prototype on adoption? For some reason I thought that changed long ago. [05:59:40.0990] That was a recent thing [05:59:48.0153] * That was a recent change [06:02:13.0429] fix should be easy and fast. The usual worry is keeping the other realm alive. But that happens already in the case there is the js wrapper [06:04:12.0420] Interesting, that was a 2018 specification decision: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567. I guess whenever cross-document adoption happens the script doing that must have access to some wrappers of both realms already. [06:07:22.0996] I was equally worried about memory leaks 10 years ago as I'm now πŸ™‚ [06:07:39.0683] Well, maybe I'm more worried these days given the recent bad examples [06:10:37.0037] @annevk: In that same sentence, in the phrase "and each subsequent task, that is queued by the networking task source ...", the comma seems incorrect to me. Shall I delete it? [06:10:50.0283] If it wasn't for custom elements it could still be interesting to pursue, though I suppose it might not be web-compatible anymore either. [06:11:39.0354] jmdyck: seems fine. Probably the easiest if you just rewrite as you see fit and then we figure out during review if we need to fine-tune a bit. [06:11:58.0653] ok [06:28:12.0733] Done! [06:29:48.0335] hm, my PR got "Error: Wattsi server error" [09:46:58.0278] it would have been a lot funner if hixie had called it whoopsi instead of whattsi [09:47:09.0367] "Whoopsie server error" [10:05:24.0086] What *does* Wattsi mean, anyhow? [10:48:10.0033] I'm really surprised I don't know this myself.. Ian Hickson why'd you call it Wattsi? [11:07:26.0598] clearly a reference to Watt's Spiny Rat (Maxomys wattsi) [11:11:36.0333] Based on https://github.com/whatwg/wattsi/blob/main/src/LICENSE it seems more likely to be a reference to https://en.wikipedia.org/wiki/Anolis_wattsii (if anything) [11:13:59.0396] ... which is also connected to https://pythonhosted.org/anolis/ [11:16:51.0254] ... the canonical repo for which is probably https://github.com/Ms2ger/anolis [12:46:25.0054] Ah nice. My colleague πŸ˜€ [14:19:08.0838] And I started working on Bikeshed in Feb 2013, a little before that final Anolis documentation was released. [14:26:08.0508] It's fun to see what the first features were that caused me to start writing it 1. markdown paragraphs 2. propdef blocks 3. indented pre elements 4. boilerplate that's it!