WHATWG
2026-05-20
plaintext logs
prev next
source on github
10:08
<sfarre>
i see you closed https://github.com/whatwg/fullscreen/pull/247 annevk did fullscreen spec get updated or something?
10:10
<sfarre>
oh I saw Jake Archibald comment in the issue nvm
10:11
<sfarre>
is the new-old-three-argument version the same as the previous one?
10:12
<Jake Archibald>
sfarre: the calling pattern is the same. The behaviour within now handles popover=hint
10:13
<sfarre>
ok great
12:14
<Noam Rosenthal>
The "platform provided behaviors" topic is on WHATNOT agenda tomorrow,
I wanted to point out to the group that
I think https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PlatformProvidedBehaviors/explainer.md#alternative-7-low-level-primitives-on-elementinternals is a really good explanation of why this is a desirable approach rather than more ElementInternals and I recommend spending time reading it to come prepared. Thanks Ana Sollano Kim for writing it up with such care.
12:15
<Noam Rosenthal>
(FWIW I have no vested interest in this API nor am I involved in it directly but I think it's going in the right direction)
12:42
<annevk>
I mean I agree you can have those issues, but enabling you to have those kind of issues is kind of the point. Also, behaviors seems very novel.
12:43
<annevk>
Like we might well regret this design if Decorators actually become a thing.
12:45
<Noam Rosenthal>
I share some reservations about the API shape/naming etc but I think that the general idea of presets of multiple internal configuration choices is a better course of action than trying to disintegrate it to atoms. I think the point should be users/accessibility first rather than technical purity for web components... and we can always add those atoms as we go along
12:47
<Noam Rosenthal>
IOW it's OK if some of these internals are "cascading" in a way and can override each other with clear rules. they don't all have to be purely atomic as it can get ridiculously complex to implement accessible UI
12:48
<annevk>
I don't think anyone is asking for atoms, but not being able to make a custom element focusable in 2026 is kinda meh. Not sure why this needs to come first.
12:50
<Noam Rosenthal>
can't say about priorities but I think they do touch on that in the explainer. If focusable: true doesn't help you build accessible custom UI elements without a dozen other booleans then I can see a reason to start with "submit button behavior" and drill down from there
12:52
<Noam Rosenthal>
.. but saying: let's take the imagined low level list for the explainer and implement that first" is a valid stance. My aim atm was not to convince anyone but to remind people to read the explainer before tomorrow as I found that helpful
12:57
<annevk>
I'm actually surprised the explainer doesn't do any comparison to form-associated custom elements. They are slightly higher-level building blocks and it would seem that something like that could work here as well.
12:57
<annevk>
At least they repurpose a bunch of existing features to enable their own feature set.
12:58
<Noam Rosenthal>
Ana Sollano Kim: ^^
13:12
<Luke Warlow>
Yeah I don't think everything needs to be atomised but I do think some atoms are necessary. Designing at least one atom alongside maybe two or three behaviours would make this much easier to evaluate as a design. Perhaps "internals.[atom]" is the design and that's perhaps fine, but it would be good to agree on that. Obviously then you have to deliniate whats an atom and whats actually a behaviour.
13:14
<annevk>
It also seems rather scary to bless a whole new behavior system with one behavior that's both complex but also simple compared to some of the other semantics in HTML. If it was just a new thing alongside form-associated custom elements it'd feel much less invasive.
13:18
<Noam Rosenthal>
Yea that's again a shape thing. A static boolean in the element definition seems to do roughly the same thing as a behavior with a simpler shape and less of a "system". would be good to explore that
13:29
<Noam Rosenthal>
Though also adding a bunch of static booleans to the element class feels a bit boolean-trappy. maybe there's some middle ground
13:32
<Noam Rosenthal>
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PlatformProvidedBehaviors/explainer.md#alternative-2-elementinternalstype-proposed kind of touches on this but maybe could be expanded
13:48
<Noam Rosenthal>

e.g. I think a shape like:

// this:
static behavior = ["form-associated", "submit"];

// instead of this:
static formAssociated = true;

#internals = this.attachInternals({
behaviors: [new HTMLSubmitButtonBehavior()],

would be just fine. I don't by that string-based API are error prones and the HTML spec is riddled with those.

13:55
<Luke Warlow>
Could even use well known symbols or something too if that was preferable.
13:55
<Luke Warlow>
Static does prevent changing at runtime but then so does the current behaviour idea, I'm not sure I buy that that is always preferable. Stuff like draggable or popover you might want to be dynamic. A link doesn't have "hyperlink" behaviour unless it has href for example.
13:57
<Noam Rosenthal>
I think I disagree. A "hyperlink" behavior means that it gets enabled/disabled by the existense of the href attribute. same for popover. I think making the general behavior immutable simplifies things a lot
13:59
<Luke Warlow>
But the whole point with say popover behaviour is to not require adding the popover attribute? What if you want a button unless there's a href attribute? Now I can absolutely buy the argument that it's bad API to do that, but it is also what people do.
14:01
<Luke Warlow>
I guess with this requiring JavaScript a hyperlink behaviour is probably fine but I do wonder what the sanitizer API would think about that. Perhaps we shouldn't allow javascript: navigations using this.
14:04
<Noam Rosenthal>
Probably some declarative way to make the behavior attribute dependent? I don't know. Turning behaviors on/off imperatively based on attribute changes sounds error prone but perhaps it's ok
14:07
<annevk>
Yeah another concern I have with the explainer is it wanting a bunch of things to be dynamic around some design idea whereby a type attribute changes the nature of the custom element. We have that in HTML for input and had something like it with object, but we would not repeat those for new elements (though sometimes we have to be pragmatic and build on input).
14:08
<Noam Rosenthal>
(also <script type>)
14:09
<Noam Rosenthal>
... and <link rel>
14:12
<annevk>
Right and <template>. The HTML parser is a pretty strong forcing function as well in this area unfortunately. But none of those elements really reach the same level of complexity that input does. And input would be more directly comparable to any custom element I think.
14:13
<Noam Rosenthal>
yea sure
14:14
<Noam Rosenthal>
Seems like they want it to be done based on the value of that attribute at connection time. also not sure if I love that
14:14
<annevk>
Noam Rosenthal: do you know who is responsible for blocking btw? I noticed it doesn't have CEReactions. I don't think that matters for WebKit, but for any other implementation that would constitute a bug I think.
14:16
<Noam Rosenthal>
I think I'll just make myself responsible for it and fix it
14:18
<Noam Rosenthal>
ah it's a DOMTokenList. Those have CEReactions internally. I think it's fine
14:22
<annevk>
Oh yeah, that does all work correctly.