Repository navigation
Extraordinary WHATNOT meeting on 2026-06-17 #12441
Description
Activity
- changed the title
[-]Extraordinary WHATNOT meeting on 2026-06-??[/-][+]Extraordinary WHATNOT meeting on 2026-06-17[/+]on Jun 2, 2026 Igalia/webengineshackfest#80 (comment)
We're proposing Wednesday 17th June at 15:00 CEST (local time) for this session.
If that's a problem, please let us know to try to find another slot in the scheduling.
@lukewarlow wondering if it's worth adding #12150 to the agenda since many folks are already attending this meeting, but potentially we wouldn't have the full hour to discuss if there's other issues people want to add. Thoughts?
Note that for the hackfest session we have 1.5h, just in case you want to use all the time to cover more topics.
Reacted by Ana Sollano KimSorry but it's too late to do such change, as it will impact other sessions already scheduled.
Reacted by Ana Sollano KimWill the meeting use the usual teleconferencing setup or a different one?
We'll provide a link on how to join remotely before the session tomorrow.
https://meet.jit.si/WEH2026-whatnot - this will be the meeting link we're using for later today.
Some carry over issues:
-
Add FileSystemHandle.remove method added by Anne Add FileSystemHandle.remove method fs#9
-
Passing scoped custom element registry to fragment parser has non-obvious side effects: Passing the scoped custom element registry to the fragment parser has non-obvious side effects #12274
-
Make muted content attribute affect muted IDL attribute only once Make muted content attribute affect muted IDL attribute only once #12473 -
HTML-in-canvas: HTML-in-Canvas #10650
-
- A brief carryover discussion of Menu elements proposal #11729
- Localized time formatting using
<time>for Stage 1 Localized time formatting without JavaScript #12591
- Localized time formatting using
Copy of the notes.
WEH 2026 - WHATNOT: Meeting for the WHATWG
- GitHub issue: WHATNOT: Meeting for the WHATWG Igalia/webengineshackfest#80
- URL: https://meet.jit.si/WEH2026-whatnot
Platform-Provided Behaviors for Custom Elements
Ana Sollano Kim: Authors cannot modify behaviors once set. Some asked for an alternate: Make the disable property an on/off so authors can attach behaviors and can toggle. Also commente on that. Looking for signal or alternatives.
Luke: Being able to disable solves some problems, define up-front seems OK. What benefit does that provide over add/remove? Presumably the same as activation behavior.
Brian: Maybe avoid the worst patterns? Don't think you end up with input type this way.
Luke: But just add all and then disable/re-enable a single one? End up in the same situation. Is there a reason that's easier than dynamic behaviors?
Ana: From my perspective easier to have behavior first rather than adding at any point in the lifecycle because the implementation is simpler if up front (edge case hard). Already how input and button do it. So set all and turn on/off what type. So a known pattern vs. just adding/removign at runtime.
Keith: you have to handle edge cases anyway. Minor distinction so could you describe the issues about runtime.
Luke: Just property on element.internals. Adding first then toggling does not seem better but doesn't solve issues.
Keith: Need observable array of properties. What does push/pop mean.
Luke: Presumable disabling.
Keith: Do we need a way to tell the behavior that it has been popped?
Noam: Examples seem very contrived in the explainer. Hard to reason about. Use cases for button about command invoker, or things liek changing type of input.
Keith: Common use case; button and link at same time. If href a link, otherwise a button. Common in design systems. So need submit, regular and link all at the same time for a button.
Noam: Examples outside of clickable things? Are we making something too generic?
Luke: Popover plus focus group. Want both behaviors and not mutually exclusive. More attribute than element derived.
Ana: Previous iteration didn't consider composition. Agree combining any native elements can seem weird but this is forward looking to support developer defined behaviors. More intuitive to view it this way.
Keith: Is Noam satisfied with Luke example (composing focus group with popover)?
Noam: We can be a bit more particular and give classes of behaviors to combine. Does it need to be as generic as an array of abstract behaviors with conflict resolution, hard to understand. If more platform defined e.g. clicking, focus, top-layer, all parallel that doesn't need conflict resolution.
Dan: Explainer examples mostly due to feedback. Leaving out combining limits future uses but current examples not particularly compelling. Design now to not lock out possibilities. Behaviors today are mutually exclusive so conflict not such a big deal. As to origin disable/enable if we have exclusive behaviors (only one) need to pick one over the other at the start and never need to think about having both, but add/remove and enable/disable need to cover more combinations.
Noam: Feel like making so generic is not justified by use cases and is not how I would go about it. Be a bit more specific while still not precluding extension. Appreciate proposal taking on the full problem, but want to see how we can do something to fix the button/link problem while supporting future without creating infra without a client. May create a lot of scenarios and how they work together - think of all the WPT. Is we just want button/link start not and extend later.
Luke: Point about mutually exclusive makes sense and maybe the API design can account for this. Maybe activation behavior that is submit or link and can only set of one or the other. Similar for other behaviors. Makes sense to have idea of other behaviors though a lot of work. Worth doing to get an API that makes sense. The whole permutation without WPT coverage would not be good. On disabling being better because you can rejest from the start, but Keith said you can have button sometimes and link sometimes, but people want that and if we stop them they will not adopt new thing.
Dan: Responding to Noam and bundles of behaviors. Knowing that something is a set button has things that go together. e.g focus, a11y, ... Adding e.g. popover with adding all the pieces is a problem. Probably should still think of bulk properties. This API maybe not right for adding other things, happy to consider other proposals.
Brian: High level composite things are finite and see how many there are to determine complexity. Other things that could be mixed seem to offer possibilites. I would not want to design an API based on just this one thing, rather than just define "ButtonLink". Why not give an element rather than low level complexities.
Luke: A lot of discussion is around submit, and solvable. e.g. button in slot. Can be solved without all this behavior system. Coming up with less contrived examples would be better. If we require js as we do not, adding IDL for form button in your shadow would be fine. Like reference target? Have the IDL reflector pattern already e.g. command for popover target,.. Trigger a popover can be done with shadow dom and IDL getter/setter. People want to do things: focus, tabindex, problem don't match platform behaviors. Distinct from activation, worth discussing some of these behaviors is useful.
Keith: Time box this? Heard some concrete follow up. Eliminate contrived examples. Consider popover behaviors as additional examples.
Ana: ACK
Spell check custom dictionary
Brian: Custom dictionary, have positions offline on the problem. PR with HTML edit proposal. Can we move to Stage 2? Questions?
Alicia: Does the proposal have plans to handle conjugation? Problem for many languages.
Eemeli: Finnish has issues with this API. What to do with the words is not in scope. What's next? e.g. are suggestions in scope, other spell check. We could and should explore this, and these cases need more, would be limited soon.
Alicia: E.g. Spanish, each verb has lots of conjugated forms. Common problem with spell checkers but there should be some way to handle it.
Eemeli: Finnish does this more than almost anyone else.
Brian: Good for brands. Good for domain words e.g. Gandalf.
Eemile: Gandalfin, Gandalfila, Next to Gandalf, e.g turns into one word. If we take steps in this direction would be good to address these problems. What can't be handled by hunspell would be above the scope.
Brian: Leave it up to browsers as to how to break up input words for spell checking.
Noam: Where is this incubated?
Brian: Here.
Henri: Some middle ground here between Brian and Eemile. Some word never changes but then in Finnish it changes, it is a total failure in a technical perspective. From a practical perspective if you believe tokenization is doable by the browser and there is a backend to inject between token and spell check and then if token is on list it's correct. Gives you something. It does somethig dor, e.g. Gandalf, does something for Finnish but maybe not as good as it could be. Accept that this may not provide the same quality of use experience across languages and maybe document how this would work for e.g. Finnish. Compare how it behaves compared to native apps e.g. Microsoft Word. Unreasonable to require that we do nothing if not perfect, rather assess state of the art. Know Hunspell is not great for Finnish, have the people but still not great.
Brian: Same thing happens with the User Custom Dictionary. Only support single word exactly as added. So support companies.
Anne: Concern that we are standarizing something and giving support to something not great.
Brian: Reasonable first step is OK.
Henri: Assuming browser tokenizer is indeed the API, then yes.
Eemile: That assumes adding custom words in all browsers.
Henri: have to be able to inject, caveat is not that important
Noam: Shouldn't W3C International group be better group, because they are the linguistic expert? Anyone in the room?
Henri: We know enough that there is utility but not perfect for everyone. We know what we should be doing in Finnish but we never had time to do it in Firefox.
Anne: Added I10N to issue,
Eemile: not representing i10n working group, but reasonable first step
Localized time formatting without JavaScript
Luca: Extension to the time element display formatted time, no way to display localized time without JS. After discussion, have a proposal. Stage 1? Anyboyd wants more background?
Keith: Why this format
Luca: Based on JS standard, unicode messageformat
Eemile: Intent to have a design that is not unique to HTML but is sufficient, not as detailed as the Intl data/time format. Subset so can be used directly.
Luca: Same syntax for any of the three potential places you need this.
Eemile: If accepted, take to TG2 group of TC39 to add support for ...
Brian: Really like the idea and support. Any implementer? That's the barrier for stage 1.
Keith: Format is locale dependent? When you take the attribute do you mutate the shadow dom.
Eemile: Or recreate.
Keith: You say that's OK?
Emilio: Use microtask or whatever. As long as you define it properly, should be fine.
Luke: We need someone who might implement, explainer, agree worth solving. Don't need implementation details.
Brian: Protoype with a custom element and give it to people, let them use it, get people to bang on it before implementing. Even if no browser implementing, can get feedback.
Keith: I represent implementor, and would like it, willing to do custom element.
Luke: Need to define ...
Anne: Fine for stage 1.
Brian: Stage 1. Good job.
Eemile: Related, first requirement is explainer ... but last thing branch of a spec, not clear.
Anne/Luke: That means a spec PR. Can agree it's something worth solving. Should fix the process a little to make it clearer.
Keith: Process mostly about conflict, but we all agree.
DOM Localization
Eemile: Start working toward something about DOM localization, see presentation at Hackfest. Start bringing localization cabailities that do not require scripting to localize for user. Explainer linked from the issue and include video from presentation. Not sure how many details to go into given most people saw the presentation.
Keith: Interested in the overlap between this and data binding in general. Lots of frameworks do this but not for localization. E.g. localizing string. Problem is useful to solve, handles longstanding diffucult use case.
Eemile: Specific problem is localization in the DOM. Can do it in Firefox but need to recognise that the solution make apply in other contexts. The powers to do localization are limited, but maybe we need to go wider for other situations. Or maybe limit localization to avoid footguns.
Luke: Stage 1. All OK? Seems like interesting. Frameworks implement many times over, seems to make sense. Agreement!
Add FileSystemHandle.remove method
Luke: Filesystem ...
Anne: Mainly added that because filesystem standard is not actively maintained but Chrome is implementing feature not standardized anywhere.
Olli: All browsers ship "move"?
Luke: "Remove" not "move"
Kagami: Yes this is about remove, but for move, Chrome implements move method behind pref, Safari only ships 1. Firefox ships all by default and because of that has a webcompat problem.
Anne: /Cites WPT results/
Olli:?
Luke: Do we know who the editors are for filesystem spec? Seems to be something that should resolve?
Anne: Maybe my problem to resolve?
James: General problem with lack of clarity on where things are going and happy to help editing.
Anne: Current editor is Austin .. and Anne current editor of workstream. First issue is not tentative tests with feature not in the standard. Existing PRs but issues need to be resolved. Happy to review. Given lack of involvement from Austin, (James) could help.
Tom: Austin has left Google. Mareijn Kruisselbrink could take over.
Mike: Austin not likely to come back - talk regularly due to webaps.
Noam: Asked internally and asked if people involved to step in. James could step in and wait on Google folks.
Anne: ?? is also editor.
Mike; Spec has been neglected and nobody wants to work on it. So if James is interested there is no point waiting around, because nobody is working on it.
James: Happy to jump in and get it untangled. Figure out longer term. Happy to do it.
Passing the scoped custom element registry to the fragment parser has non-obvious side effects
Keith: Set innerHTML on disconnected, custom elements will execute constructors. Not great. Steve had a suggestion to not initialize the template fragment until the last step (of innerHTML algorithm?) Basic step, deserialize with custom element null so no construtors, run sanitizer, then call custom element register on the tree. Effectively defer custom element constructors until after sanitization.
Noam: Just for sanitizer? Because streaming sanitier would solve this better out of the box. Better to align with that reather than change the current sanitizer now, because several other security issues exist with the current sanitizer. Other problem with sanitizer like supporting shadow roots and the like.
Keith: Don't love that. In an interesting place. Custom Element registries part of interop 2026. Don't want to ship something that won't sanitize well. Don't want to implement streaming sanitizer just for this use case. Would like to do this step and work on streaming sanitizer later.
Anne: Are they observably different?
Noam: No, It shoudn't be.
Keith: I'll take that.
Anne: Should do streaming then first.
Noam: Current sanitizer needs to be fixed regardless due to declarative shadow dom. Need to fix issue of sanitizer happening before side effects. Solving it twice seem redundant.
Keith: Stopping problem once is half a day, streaming is more.
Anne: Not observable, so you can implement it because if not observable then not out of spec.
Keith: OK. Satisfied, thanks.
Anne: Missed it. Other fixes.
: HTML in canvas is off the agenda until we solve the accessibility behavior
Menu elements proposal
David: Bring back because we had discussion buggest was ID refs vs nesting. OpenUI discussion.
Anne and Olli were concerned about. Also research into what libraries do. OpenUI not strong either way. People might have signifcant accessibility concern. Research showed libraries use nesting solution. Proposal to update prototype to do nesting and update spec PR. Then come back next week to discuss.Luke; One concern is the case of a single button opens menulist. That scenario ID ref based not accounted for and quite common so want to make it easy. Maybe as simple as ARIA? button where the menu is. How does nesting handle that?
David: Could have menu not attached to menubar, or menu no button. Prototype and revisit.
Anne: Olli and I think the general plan is good.
Luke: Stage 2.
David: Try it first. Hope is that try it, works, then easy to stage 2.
Luke: One more item.
Coherent story for HTML-setting methods
Noam: Discussed a few time. Trickling PRs into the spec. Want to raise details so not surprising when they appear in PRs. One is combination with trusted types. This API is to support positional methods and streaming, e.g. streaming HTML. One surprise is that it lets you use trusted types for legacy HTML-setting methods. So if you set with innerHTML lets you inject the sanitizer. So affects similar methed. Side effect is sanitizer support.
Luke: Relevant to something Frederic posted earlier today. Sounds nice if it works (Noam: yes). Question on details. Maybe put in explainers.
Noam: Teaser on what's surprising, we can move from there to next session. Other bit is how it works with out-of-order streaming which is something stage 3 a few weeks back. Template with processing instructions. When you use streaming you can also stream elements that change existing stuff. But if you use innerHTML you are patching fragment before you insert it, which might be surprising.
Luke: Go away, read through and add to next week.
Noam: Fine ...
Luke: Anything else?
Keith: Good work.
Luke: Thanks for attending.
What is the issue with the HTML Standard?
There is a proposal for an extraordinary WHATNOT meeting to be held during the Web Engines Hackfest in June. As this will be at least partly a F2F if there's specific issues you'd like to discuss it's worth commenting them on here to form an agenda.
I will update this issue once we have a specific date and time set.