Upcoming WHATNOT meeting on 2025-03-13

[past]

What is the issue with the HTML Standard?

Yesterday we held our weekly triage call (#11081) and I will post the meeting notes there in a bit. The next one is scheduled for March 13, 9am PDT. Note that this is 1 week later in an Americas + Europe friendly time and there is a daylight savings change in North America in the meantime.

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 W. for taking meeting notes! Here are the notes from this meeting (the next one is at #11031):

Agenda

Attendees: Luke Warlow, Joey Arhar, Panos Astithas, Stephen Chenney, Keith Cirkel, Dominic Farolino, Mason Freed, Chris Harrelson, Evelynn Kaplan, Alison Maher, Olli Pettay, Kagami Rosylight, Chris Wilson, Di Zhang, Andy Luhrs, Anne van Kesteren
Scribe: Joey and Chris

1. Review past action items
   1. Olli will take a look at Feature Policy: focus-without-user-activation, Domenic will try to take a look in a few days if no one else gets to it.
      1. [smaug] seems like it landed, but it looks quite reasonable
2. Carryovers from last time
   1. [Anne] Web Compatibility of Scoped Custom Element Registries
      1. PR review is needed.
   2. [Alison] ARIA notify iframe restrictions
      1. Olli and Anne will take a look.
3. New topics
   1. [Anne] native/primitive appearance of Customizable <select>
      1. Chris will talk to the CSSWG about this.
   2. [Di] Should live range expose endpoints inside a shadow tree
      1. Olli will take a look at the selection PR.
   3. [Di] Naming of Composed Range
      1. Carryover.
   4. [Dom] FACE reset algorithm during custom element creation
      1. Carryover.
   5. [smaug] Should we try (again) to remove XSLT?
      1. Carryover.
   6. [Luke] Fix dialog closedby and requestClose() #10954
      1. Carryover.
   7. [Luke] File upload control rendering should specify the button element to use. #11130
      1. Carryover.

Action Items

1. @smaug---- and @annevk will take a look at ARIA notify iframe restrictions.
2. @chrishtr will talk to the CSSWG about native/primitive appearance of Customizable <select>.
3. @smaug---- will take a look at the selection PR for Should live range expose endpoints inside a shadow tree.

Minutes

feature policy: focus-without-user-activation
panos: nothing more to do here

web compat of scoped CE registries

• anne: we hit some issues with rolling it out because of polyfills existing in the wild, and initially we thought we had a solution that preserved the shape of the api, but then we found more breakage from another polyfill. We ended up migrating away from the customelements name to customelementsregistry for most accessors, and this is reflected in the latest PRs, for which im still looking for review. They're in a pretty good shape. one realization is that maybe we should also expose customelementregistry on document, that's the one change that still needs some work in the PRs. wanted to know what people thought of that.
• mason: does it actually break stuff if you override that name? do they feature detect for something in the platforms?
• anne: we tried replaceable and changed dictionary to any, but broke something that did something different
• olli: at apple youre still reviewing? or should we review?
• anne: its been ready for a long time
• olli: there are no review requests for the PR
• anne: they're ready for review
• mason: we're ready to give it a review
• panos: shall we assign people or figure that out async?
• anne: what i heard here sounds fine
• panos: did you want to check implementor interest?
• olli: keith prototyped something
• mason: chrome has an old prototype. we're supportive
• olli: i dont think we want to land the patches until we have the api stable. implementation work isn't too bad
• panos: we talked before about being more explicit about implementor interest
• mason: we could do stages if you want
• anne: I don't really care. from our side its ready, just want to know what y'all think
• olli: maybe some issues about memory management or perf, maybe not
• anne: we haven't encountered any speedometer regressions

aria notify iframe restrictions

• alison: aria notify is a new js api that we're working on to allow authors to provide custom announcements to AT users. we have an opt out for users for iframes. There's a few different proposals. one is to provide a new sandbox option, another to have a permission policy, another to have document policy. Which one makes the most sense?
• olli: how stable is this proposal in general?
• alison: we've been working with the ARIA working group on this, we have a scoped v1 proposal. In chromium we have an implementation we're wrapping up behind a flag and then start an origin trial. looking to get started with web developers
• panos: i see a concern in the issue
• alison: that was about the permission policy - i think his preference was to use document policy
• panos: i haven't seen a response, do you have any thoughts?
• alison: i don't have a preference, it seems like we can achieve it either way. His concern was about using the allowlisted star instead of self. i don't know if we have a preference for this, default for it to be allowed but opted out
• panos: does anyone have thoughts on this question?
• olli: I want to also take a look at the actual aria api. It reminds me a bit of salt - speech application text, which I implemented 22 years ago at nokia. it was a microsoft proposal
• panos: do you want someone from webkit to take a look?
• alison: yes
• panos: anne would you be the right person to look at this?
• anne: sure you can add an action item for me, but ill talk to colleagues probably. the html integration is just a policy thing or was there other aspects?
• alison: how do we allow authors to opt iframes out of aria notify

native appearance of customizable select

• anne: I realized this is an aspect of the select element that we hadn't yet defined, but probably should be. don't want to end up in a situation where you can use css to style the native appearance but in others you can't. for appearance:auto for the enhanced select element to be interoperable as well.
• mason: the appearance:auto appearance to be interoperable?
• anne: to the extent that it is web observable
• mason: like the rendering or not the rendering?
• anne: the rendering is typically not web observable
• mason: it's currently not interoperable. I think we're ok adding some text that it's ok to render images? on some platforms its hard, like the native mac picker
• anne: the other thing i wanted to get clarity on, when we proposed the switch control, you all wanted us to fill out the boxes for native and none appearance, but now you're ?? at that for the select element which seems a little weird.
• mason: appearance base wasn't a thing at that point, but the hope was that you'd have interoperable styling at that point
• anne: that was a separate concern
• mason: in our view it was connected
• anne: i remember specifically talking about the native appearance thing, and you said at the time that you only care about base appearance
• mason: the pseudo elements for example, that was or is still missing from the PR, and it was unclear to me whether the pseudos would be available on auto or only base. That was one of the things that was missing, was the pseudo elements for switch
• anne: those would not be present for auto
• mason: there are pseudo elements present for auto in other controls
• anne: right, so shouldn't we have that discussion then for select as well
• mason: sure lets have that conversation for auto
• Joey: As Mason and I both mentioned in the issue, we can add some text to how options are rendered , e.g. how images could be put in. What would you like to see?
• Anne: I think we need to address some of the styling things like new pseudoelements appearing or not.
• Joey: So if you dont put appearance base on the ::picker select then it doesn't do anything as we ‘ve implemented it; I'd be happy to spell out unless you think there are some capabilities you'd like to add.
• Anne: not necessarily. Just like a box and some of the styles. Obv, there are some compatibility constraints.
• Joey: for select arrow we'd not planning on making that do anything for appearance:auto; not with the check mark sooner element. Happy to add anything you would like.
• Luke: spelling it out would be useful, to get it noted down one way or another. Given appearance:base is a thing, we probably don't need to add all these to appearance:auto and :select. One thing that might be worth noting down is whether this is a html or css thing, OS-specific.
• Mason: +1. I think we should talk about it but that's a separate issue from customizable.
• Anne: I don't think anyone has requested that auto:appearance does fancier things. We have all these new elements and we have to describe how they end up looking like, regardless of appearance: base.
• Mason: That's why we have appearance:base?
• Anne: No. They can have arbitrary children, which impacts the algorithm. New pseudoelements, whether or not they end up doing something for auto and non appearance.
• Mason: That's what Joey said; the pseudo are only present when the base control or the picker are present.
• Anne: I don't think we got it. If the native appears like a red box, that doesn't say anything about if the implementation exposes them. What are you rendering when it is like an iframe?
• Mason: not planning on rendering, extract the text content.
• Chrishtr: We should just say no pseudoelements, and we extract the text content.
• Luke: I think we have an algo in a PR that says just that?
• Joey: Yes? We have the thing that says option elements are rendered by displaying their label, and algo to collect all that text. There's a red box for more detail.
• Joey: Who can write that?
• Anne: doesn't need to be me. I think Mason wrote out for the switch control what he thought had to be done, like all kinds of property combinations and stuff to figure out what the initial values were going to be.
• Chrishtr: you're saying this is undefined for any form control at present?
• Anne: yes
• Chrishtr: I can work with the group to figure that out.

PA: live range endpoints inside a shadow tree?

• Di: for this we're reviewing the PR for composed section range, live range if live range has endpoint using the same root is okay but if it is in different roots/trees it will collapse. Behavior not currently compatible across browsers.
• Dominic: if you call get selection set base and extend to end points that span a shadow boundary, they get collapsed somewhere. What we want to do is provide spec that allows get composed ranges to be arranged, composed across the shadow boundary which is different from get range at zero. That effort would be leaving get range at zero alone. First thing is to give spec muscle to get component ranges; second is to deal with compat issue of how collapsed live ranges work when it comes to shadow dom.
• Anne: The important bit is that the caller gets knowledge of the shadow roots, they get exposed, right?
• Dom: right. The two apis can finally return different ranges.
• Anne: bit muddy since getComposedRange has already landed to some extent.
• Dom: It's in the ? and webkit has it. But only nightly in FF, and chromium doesn't ship it at all. So it's half, and one foot in/one foot out.
• Anne: we should really get the encapsulation right.
• Olli: browsers are not consistent at all. Do you know if webkit had compat issues when the implementation landed?
• Anne: I haven't heard of anything, Ryosuke would know for sure.
• Dom: I don't think we would be enshrining anything that isn't already enshrined, it will just return the right ranges.
• Olli: I'd prefer to fix both APIs at once, and they have reasonably well working APIs.
• Anne: yeah I'm worried we've released this api to devs across all browsers and we say it's stable, then they play with it…
• Dom: but they needed getRangeAt(0) in order to make this work today
• Panos: it would give them an offramp and we'd be in a better position to evaluate possible breakage of getRangeAt(0).
• Anne: I'm uncomfortable with going ahead with this because the spec as proposed enshrines behavior for getrange that is bad.
• Dom: no more than it already is.
• Panos: I'd like to timebox this discussion, and see if we can converge on changes to the old API and see if we can get consensus on either not making changes or making them in a way everyone is happy with. Plausible?
• Dom: don't think there's much disagreement on what the ideal version of the old api should do. Can we do it practically when all browsers disagree on it?
• Chris: Do I understand correctly that we agree on the shape of the new api, but disagree on whether the old API can be fixed?
• Dom: second part correct. Whether we can agree on all of the semantics of the new API, I'd like to achieve that.
• Di: we're not changing the endpoints of getRangeAt.
• Dom: Right, we're not changing anything that any browser would be required to return from getRangeAt(0). No web observable change.
• Anne: I think that might be correct, but it doesn't try to take the wrong behavior further.
• Dom: That's maybe where we disagree, I think it preserves the incorrect enshrinement.
• Dom: the change we add is they get reflected back to the composed selections.
• Panos: maybe Anne/Olli mention in the issue the specific text they disagree with? Proposals for making them better?
• Dom: Anne, can you review everything as far as we can go with it.
• Anne: not sure what the resistance is to fixing the old one. [Anne has to depart]
• [minor discussion]
• Chrishtr: Olli, are you okay with the PRs?
• Olli: haven't looked at anything for selection API itself; was looking at the DOM side. Don't have strong opinions on that. I don't like the legacy, but if others do, fine with me.
• Chris: With both of us close to shipping, can we ship the same thing?
• Olli: I need to ask Sean, he isn't here
• Chris: Would you prefer we change the behavior of getRangeAt?
• Olli: no strong opinions [agrees to review pr]