Upcoming WHATNOT meeting on 2024-12-19

[past]

What is the issue with the HTML Standard?

Today we held our weekly triage call (#10825) and I will post the meeting notes there in a bit. The next one is scheduled for December 19, 9am PST. Note that this is 1 week later in an Americas + Europe friendly time.

People interested in attending the next call please respond here or reach out privately to @past, @cwilso, or the editors. We will be tagging issues for the next call again using agenda+ in all WHATWG repositories across issues and pull requests and we would like to invite anyone that can contribute to join us.

[past]

Thank you all for attending the meeting today and a special thank you to Joey and Chris for taking meeting notes! Here are the notes from this meeting (the next one is at #10878):

Agenda

Attendees: Joey Arhar, Panos Astithas, Stephen Chenney, Justin Fagnani, Dominic Farolino, Mason Freed, Andres Ricardo Perez, Olli Pettay, Kagami Rosylight, Anne van Kesteren, Chris Wilson, Di Zhang
Scribe: Joey (Chris as backup)

1. Review past action items
   1. Olli will review or find someone from Gecko to review tabindex vs reading-flow property. It would be great to have Elika's review as well, since she had some concerns previously.
      1. [Olli] reviewed some, looks reasonable, needs still s-p both from Gecko and Webkit
      2. Followup on CSS side, doesn't need to stay on our agenda.
   2. Joey will update his PR per the consensus in How to spec user interaction for select.
      1. [Olli] Only minor nits from me. Is user-select:none missing?
2. Carryovers from last time
   1. [Anne] Revamped Scoped Custom Element Registries
      1. Asking for review; haven't prototyped yet
      2. Anne to create label to tie issues together
      3. Overall positive response, but bikeshedding
      4. Carryover
3. New topics
   1. [Joey] Stage 3 for customizable select
      1. Open question about alt-text in the value for options
      2. user-select behavior
      3. …that's all that was mentioned. Please review to see if there are others.
      4. Carryover: Joey to address alt text issue, bring back for promotion to stage 3
   2. [Stephen] Add an optional lang argument to OffscreenCanvas constructor (Issue)
      1. Feedback received, will bring back to agenda if necessary; no carryover
   3. [Dom] Introduce moveBefore() state-preserving atomic move API (and stage 3 on the issue)
      1. Agreement to move to Stage 3.

Action Items

1. @annevk will create a label to tie Revamped Scoped Custom Element Registries issues together.
2. @domfarolino will update Introduce moveBefore() state-preserving atomic move API with the stage 3 label.

Minutes

topic: tabindex vs reading flow

olli: yeah i was looking into that. We had a long discussion about that at the last meeting.
chris: Do we need to keep this on the agenda for the future? or is it well underway?
anne: whatwg side is pretty clear, we can drop it. There's some css stuff that needs to be done first.

topic: <select> user interactions

Joey: olli left a review comment on the PR. user-select:none, I filed a new issue: #10876. We've discussed button elements before and I think we're rediscovering the same here. (e.g. preventing text selection when clicking and dragging). For customizable select I think we want something more like Firefox so it can be controlled with user selects. Worried the behavior we have could prevent users from clicking and dragging to select. Not sure how it will work in practice. I need to look into this some more, find out where the prevent selection is implemented in Chrome. Carryover for a couple of meetings from now.

topic: scoped custom element registries

anne: I wanted to discuss this briefly. Ryosuke and I are trying to figure out how to do this proposal while addressing concerns regarding elements that are disconnected and would lose their registry, and if they need to keep their registry. If you move an element outside a shadow tree and then start appending things to it. you have to figure out how to decouple it from shadow trees so that's what we're doing. This proposal ends up tying registries to elements more directly. It still allows them to be tied to shadow roots, and other changes follow from there.
mason: awesome that you're expanding the proposal, looks more powerful which is cool. from my point of view, have yall prototyped it? there were concerns about memory if elements are pointing to a registry, and performance with tree walks.
anne: we came upon this when trying to solve the final set of issues with initial scoped registries implementation figuring out what to do with disconnected trees. We haven't prototyped it yet but think it can be reasonably performant by - in the common case, a tree will not have its registry change a lot. you will have a bit on the element that says it's not different from other elements, and when there is that bit, you have to look through the table. You also don't have to care about the registry that often. optimistic that it will work.
olli: you also have to do it when appending children. ok parent has some special registry, and you have to copy that to the children. There are cases like that where it will add some overhead.
anne: if the inserted node doesnt have a registry yet, yeah
mason: when you insert a big tree of stuff you have to set the bit everywhere?
anne: if they're all coming from the null registry you could optimize that. but yeah if they have different bits set then it will be trickier.
olli: you have your top level registry and you add more elements beneath that you're using a special registry and not the top level one.
mason: there are two performance cases. don't want to regress performance on only one registry, and then there's multiple registries
justin: Thanks for working on this, this is the big gambit. I wonder, to mason's point, is it worthwhile to put implementation guidelines or notes why this proposal could be fast? with the old one, the reason to put it in the shadowroot before was feedback that we can't put it on each node.
anne: I think webkit also gave this feedback. Nobody wants to have a pointer on an element directly. We were thinking of bits and side tables. That was not a thought we had previously. Maybe some speedometer work made us fiddle with bits on nodes in general, and the thought that we could use that here. generally i would say that the spec should probably not talk about that. There's many optimizations of that kind that implementations already have to make, and we are not going into details about those. js spec doesn't talk about jit. I think one key thing, everyone involved realizes that it probably has to be implemented in such a way, but that is also shared through open source implementations.
justin: one concern i have about the shape of the api here is what it will look like for frameworks to create elements in the correct scope. if its being rendered to a shadowroot or light dom that has a registry. i tried to expand on common stuff between document or shadow root, so you could use that as your creation object. fallback to createnode or importnode would work with frameworks that don't have this or polyfill. The additional requirement to do .customelements on document or shadowroot, and this different api, its almost a trivial complaint because its just more characters that you have to type, but we've gotten a lot of feedback from frameworks about how ugly the apis are, (stuff about calling lots of apis), its a one time change about frameworks, but why is element creation so complicated now? either you have a document or an object and you call importnode on that thing.
mason: quick +1 to the question. I have a different twist on the same thing. clonenode vs importnode are confusing and do different things. were adding another one, and it would be good if we could just keep it to 2
anne: just importnode i dont think would work. I'm also not sure about - so a lot of the argument seems to hinge on whether you want to do it the new way but also want to cater to old user agents, and you also want to add more to cater to them. I don't want to be designing for 4 years from now when the old ones dont matter anymore.
mason: in the far future there will still be 3 methods, that concern remains
anne: Yeah, I think that's valid. We could do this differently, but i dont think either clonenode or importnode have a signature that's attractive. This would be like our way of fixing that. Plus this also provides a way of getting the registry correct which neither of those have. importnode could work if you add it to the element directly, but i dont think we should go there.
mason: if you rename clonesubtree to importnode, its on a different object but at least authors can remember 2 things instead of 3
anne: clonesubtree clones by default, but others clone the top level which is not what you want typically, and it sets the registry
mason: my concern is just confusion. If there's a way to make that better
anne: we did think about just having importnode on there, but importnode is just a ugly api. clonenode is ugly too. they all do bottom out in the same thing.
justin: There's different versions of ugly. i have to either use importnode or clonenode
anne: they can all use clonesubtree.
justin: It can be hard to get adoption of this thing. I guess the document is going to get clonesubtree as well?
anne: Maybe?
justin: I brought this up in the thread, now we say the proper way to create all elements is to use something.customelements.clonesubtree or createelement. Now we don't want libraries to treat native elements and custom elements differently. Whatever tag name you have, pass it forward. Now that's all going to be through this custom elements interface. It shouldn't be called customelements. asymmetry between customelements.get and built-ins. customelements.createelement which will work on builtins. so now you cant - one thing checks whether something is a custom element, and the other thing can create any element. Maybe a minor thing, but this is something we get pushback on. Is it appropriate for all element creation to go through the customelement object?
anne: i dont mind it so much. i think we had proposals before for get and stuff to work on builtins. We didn't really get it fleshed out, or nobody ended up fleshing it out. there are some - builtin elements also have some corner cases where they reuse the class name over local names
justin: people use customelements.get to see if a tag name is a custom element. returning a constructor there i could see it being a problem
anne: yeah that seems like it would be a problem
mason: anne it does sound like you want clonesubtree to be the new thing to use in all cases. I see Justin's point that putting customelements is weird. if you want to have it be for everything then maybe document should have it and use the documents registry
anne: How would you do it for an element?
mason: maybe element.clonesubtree
justin: shadowroot too
anne: you cant clone a shadowroot directly?
justin: shadowroot.clonesubtree with the node you want to clone. clone it within this objects registries scope
anne: i think thats more confusing than the registry being the this object
chris: Is there more progress to be made here?
anne: more reviews would be great. We definitely need to have another discussion. If people have ideas for other shapes it's welcome. commenting directly on the PRs, try to dissuade people from that because then the PRs get very long. If you're an HTML spec editor then feel free, but otherwise maybe not.
mason: do you want separate issues? that same concern happens on the main issue as well
anne: sure, and then i can create a label
justin: i think this can clearly work, so im happy about that
chris: Do we want to put this on the agenda again?
anne: yeah

topic: customizable select

Joey: once again asking for stage 3 or more reviews on customizable select. I think in terms of spec PRs, have made some changes based on feedback from David and Dom Farolino. Any thoughts?
Olli: I wonder if Henri has seen those.
Joey: Henri's concern is probably still unchanged in the spec.
Anne: I thought we'd just learned the parser approach didn't quite work out; bit surprised it's going for stage 3 again.
Joey: still looking for more review here; parser changes I tried to ship them in Chrome but a few bugs related to code that collects info about option elements and then sends them to native picker. One other piece about input tags closing selects, which I'd prefer not to make happen.
Anne: So it's planned for shipping again? ALT text being displayed in native selects and such?
Joey: Yes. ALT text from images should be reflected in select value.
Anne: some questions about how to handle SVG?
Joey: would prefer not but no legitimate reason so can add it. Right now it just collects text nodes, but can look for image elements.
Anne: Maybe SVG text content is fine. Generally for SVG I don't have a good intuition, but I would expect to be able to put an image into the option and have its alt text be reflected in the value.
Stephen: SVG has a title element that might serve that purpose. There's also a descriptor but that's long-form and probably not appropriate.
Mason: this might discourage ALT text usage, if it starts showing up in places.
Anne: I would expect it to be used for the display value at least, maybe not the submitted value.
Mason: Maybe with good guidance we could avoid this as a problem.
Joey: they could also add the label attribute for appearance auto mode or whatever. But I think this makes sense for the display label.
Anne: it adds a label and a value; if it doesn't add a value it defers to the label.
Joey: to MAson's point about seeing alt text show up in the value, maybe split: if there's a value use that without looking at alt text attributes then for the label include alt text.
Anne: what happens currently is that label and value both defer to text and that does some filtering on elements.
Stephen: One way to avoid the alt text trimming is to say you're only going to take the first n characters of alt text, which would avoid blowing up the description. Its not great, but avoids the problem.
Mason: sounds like we need to address the alt text question. Anything else like that we need to address [prior to stage 3]?
Anne: These are what came to mind from a review a couple of weeks ago.
Chris: let's address alt text and come back next time, simultaneously do review and raise any other issues.

topic: canvas constructor

stephen: ill defined for regular canvas. you get whatever the ua decides is the default language. the solution to this is to add an additional attribute to the canvas text drawing IDL that lets you provide a language. I think there's probably broad agreement because it fixes a problem that creates inconsistent rendering in canvas. I'd like a review on the pr language on what the value is to use. If it's not given then what should you use? A related issue was a similar problem for direction, writing direction for canvas text where that is also ill defined. in chrome, for an offscreen canvas, you always use left to right i believe. we use css style direction which is not the preferred way to get a direction, should be using HTML dir attribute. Any thoughts at all?
anne: Thanks for tackling this, important for text to have both direction and language. For getting the language of a node, html has an algorithm for this, it's just called language I think. you can use that. There is a similar thing for direction we should use.
stephen: if the worker has a dom window scope, then you can pull it from the document, so that works. if the worker has no dom window and just has an offscreen execution context, then we would just have to default to ltr.
anne: like if the worker canvas was created by a transfer?
steven: yeah if you transfer a canvas element render context to an offscreen canvas, in which case you can get back
anne: in that case you want to specify something like its snapshotted, we don't want to keep carrying that data across the thread boundary. if you change the language it shouldn't affect the worker, maybe the canvas api
steven: i should specify what happens on dynamic changes to the language. A related issue is if you change the language, should you reload the font? i do need to add that
anne: in the window case you want to snapshot when you do something with the text
steven: happy to clean this up. olli do you think gecko would support this?
olli: changes should be quite simple here
chris: Any other feedback?

topic: movebefore api

dom: a month ago we discussed stage 3, and some reviews have come in since then. Everything has been addressed except for a bug olli found. ill address that, and add tests, but given nothing significant in the design shape has come up since then, I'm wondering if we are good to move to stage 3 since it's been a month and the reviews have come in and were stable on it. Besides writing tests, i think it makes sense to ask for stage 3 again?
olli: one was about the slots in the old shadowroot, and then the other one was on the html side which is do we need to pass the next sibling
dom: there's been a comment
olli: ok i havent read those yet
dom: it was a while ago about moving stuff parameters
olli: there was the comment that there are some of the elements, source element, it needs to access the next sibling in the previous location. It seems to access something that isnt there anymore, if i interpreted that correctly
dom: oh theres a new comment, got it
anne: I think that might also be a problem with insertion in general, where we have this weird language, the "was" language, that seems like a bug. I looked at it a long time ago and I wasn't sure how to resolve it.
dom: I see. ok, i havent seen this comment yet, so I will take a look at it. Those are good points. I would make the argument that they aren't stage 3 blockers.
anne: I think stage progression is fine. I would like to take a final look before merging. I think 3 is fine. I thought it was already there.
olli: I think that's fine. I wish there were more testing for the basic dom stuff.
anne: At some point there was a concern about mutation events?
mason: it disappeared for all but a few people in July. still planning to remove the rest of the people in may or june. I recently contacted everyone on that trial and only got positive responses, so optimistic about June.
dom: mutation events are suppressed in the movebefore api.
olli: the pr doesn't mention pr events of course, but we would have to add a flag that says don't dispatch mutation events here.
mason: that already existed as a concept in the spec
olli: there is a test for that which is testing something not in the spec, but i guess thats fine
dom: ill address remaining stuff, mark it stage 3, and reconvene in the new year