| 04:16 | <Ana Sollano Kim> | On this, I think the following might be interesting: I few months ago I added use counters to see if people did actually change the type of <button> and <input>: https://chromium-review.googlesource.com/c/chromium/src/+/7624034. Changing type while a <button> is connected to the DOM -> ~6% vs disconnected -> ~25% of page loads. Changing type while an <input> is connected to the DOM -> ~1% vs disconnected ~70%. This + having a few people independently bring up not following the <input type> pattern and this article https://meowni.ca/posts/a-story-about-input/, informed our decision to not have dynamic changes until we hear a valid/real use case for it (which I've asked for but have not heard any yet). |
| 04:19 | <Ana Sollano Kim> | I must say that I'm not opposed to the idea of dynamic behaviors, there's certainly some design/implementation issues I'd be worried about though. This is more just explaining why I didn't choose that direction in this public iteration. I'm certainly open to feedback as to why dynamic is preferred and happy to explore/prototype that. |
| 05:30 | <annevk> | I'm not sure statistics about where type is mutated tell us much. You'd also need to know over what period of time it is mutated to know if it is relevant or not. |
| 05:30 | <annevk> | Overall I'm not really convinced that this is sufficient to break with prior established patterns. |
| 07:43 | <Tim van der Lippe> | Hey folks, on May 18th https://linegoup.lol shows a big drop in passing tests for almost all engines. Looking at individual browser results, https://wpt.fyi/results/wasm/core?label=canary&from=2026-05-18T06%3A00%3A00.000Z&to=2026-05-18T20%3A00%3A00.000Z&product=chrome points to a big drop in WASM test scores. The only commit that appears to be in this timeframe is https://github.com/web-platform-tests/wpt/commit/49981e3a30d6ad4fccceae8a0e834e043d2f048a I don't know whether this could cause this big drop, but maybe somebody with WASM knowledge knows what's going on here? It's a scheduled sync (https://github.com/web-platform-tests/wpt/pull/59934), but I don't know what the source is (the PR doesn't list that in its description). So I also don't know where to report this finding. |
| 07:45 | <annevk> | Jake Archibald Alice (🇳🇱) smaug maybe we could organize a small breakout meeting next week to go over https://github.com/WICG/webcomponents/issues/1098? Seems straightforward since we're all in Europe (I think). I'm hoping that might improve our collective understanding of it. |
| 07:46 | <smaug> | sounds good to me |
| 07:46 | <Jake Archibald> | I'm up for that. Monday is a holiday in the UK and Tuesday looks busy for me, but anything else… |
| 07:47 | <Alice (🇳🇱)> | I can't do Thursday, and I'll need a bit of time to refresh my memory, so maybe Wednesday or Friday? |
| 07:47 | <smaug> | Friday any time wfm |
| 07:48 | <Jake Archibald> | Same |
| 07:50 | <Jake Archibald> | Yoav Weiss Noam Rosenthal: Btw, the reason I kept "traversable navigable" and "top-level traversable" as separate things is because of your use-case, and the general idea of having an iframe that doesn't take part in top-level traversal. |
| 07:53 | <annevk> | Okay, I scheduled something for approximately this time one week from now. If anyone else wants in, let me know. |
| 08:31 | <Noam Rosenthal> | Yea makes sense that that concept is distinct from "top level". |
| 08:32 | <Noam Rosenthal> | I wonder if we broke the assumptions for it being not necessarily top level later on though. That part of the spec is quite complex |
| 08:41 | <Ms2ger> | Thanks for flagging, the source is https://github.com/WebAssembly/spec/pull/2017 . I'll fix now |
| 08:45 | <Ms2ger> | https://github.com/WebAssembly/spec/pull/2172 |
| 12:25 | <annevk> | Alice (🇳🇱) Jake Archibald smaug I also had Claude put together a comparison of some alternatives https://gist.github.com/annevk/10d21f3696622b111989ce6720600a96 |
| 12:44 | <annevk> | D makes some sense to me. When we added the source IDL attribute it already seemed a bit of a hack that it wasn’t integrated with event dispatch like relatedTarget. |
| 12:52 | <smaug> | D is like the current relatedTarget approach, no? mouseover/out/focus/focusin/focusout/blur which have .relatedTarget are also composed |
| 13:03 | <Alice (🇳🇱)> | Is that not the behaviour that was removed in https://github.com/whatwg/html/pull/11255? Am I misunderstanding the proposal? |
| 13:16 | <annevk> | Alice (🇳🇱): I think it is, so it might need some adjusting. One could imagine doing a check when dispatching as to whether the event should be composed or not based on where source is relative to target. The core concern I have with A is that it changes get the parent. |
| 13:21 | <Alice (🇳🇱)> | The goal of that was to honour the intent of not having composed set, while still allowing listeners in source's tree to observe the event |
| 13:22 | <Alice (🇳🇱)> | It seems like a big hammer to set composed just to get the event to propagate into source's tree |
| 13:22 | <Alice (🇳🇱)> | but I don't really have a horse in this race, so if folks are ok with it after all then so am I |
| 13:25 | <annevk> | I think if coupled with relatedTarget-like semantics it ends up being mostly equivalent, except that intermediate shadow roots are no longer skipped. Because it's also somewhat weird for non-composed events to nevertheless escape the shadow root. That's pretty magical too. |
| 13:26 | <annevk> | I guess I'm glad we haven't done multiple shadow roots per element as that would make all of this even more mind boggling. |
| 13:27 | <Alice (🇳🇱)> | I need to refresh my memory on the relatedTarget behaviour and the intent behind it |
| 13:29 | <Alice (🇳🇱)> | I don't really know what people mean when they describe behaviour as magical; I always just read it as "bad vibes" |
| 13:32 | <annevk> | Bad vibes sounds accurate. :-) I think what I usually mean is that the behavior seems unexpected given the shape of whatever is being discussed. Perhaps to a severe degree. |
| 13:34 | <zcorpan> | IMO magic is when something pulls tricks to achieve the desired outcome, and those tricks are usually not exposed as their own lower-level primitives. e.g. fieldset + legend rendering is magic |
| 14:23 | <smaug> | It is not. Those events were just composed, but .source handling didn't trigger similar behavior as .relatedTarget |
| 14:24 | <smaug> | Or I misinterpret what claude means in D |
| 14:27 | <smaug> | And the intent of .relatedTarget behavior is basically that if there are mouseout/mouseover events, they will be visible only to the subtrees under the root in which both .target and .relatedTarget live. So, if mouse change position to be over another element in some shadow subtree, from light tree point of view there shouldn't be any new mouseout/over events |
| 14:28 | <smaug> | mousemove is also composed, but since .relatedTarget is null, it propagates all the way to window object |
| 14:28 | <smaug> | (and move itself isn't about any particular element, it is a proper user input) |
| 14:59 | <annevk> | Dominic Farolino: why are many of the tests inside dom/nodes/insertion-removing-steps/ still tentative? |
| 17:38 | <nicolo-ribaudo> | I'm reading the media events spec, specifically to figure our under which conditions the "ended" event is fired: https://html.spec.whatwg.org/multipage/media.html#reaches-the-end If the media element is paused at time X and the source changes its duration to X, does it fall under "the current playback position reaches the end", or not because the current playback position is not changing so it's not itself reaching anything? I tried writing a test for it using MediaSource, but what I'm seeing in Chrome is that it doesn't even set the |
| 17:43 | <nicolo-ribaudo> | Oh and also, should the ended event be fired if the duration is changing to something lower than X? My reading of the spec says yes, but from what I'm seeing no browser does. |
| 17:54 | <Tim van der Lippe> | Thanks for taking care of this! |