Upcoming WHATNOT meeting on 2025-09-25

[cwilso]

What is the issue with the HTML Standard?

Last week we held our weekly triage call (#11664) and I will post the meeting notes there in a bit. The next one is scheduled for September 25, 9AM PDT. Note that this is 1 week later in the North America-EMEA friendly time.

People interested in attending the next call please respond here or reach out privately to @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.

[KurtCattiSchmidt]

Added an Agenda+ on #10673 to discuss getting it to Stage 2 now that I have a PR ready.

[cwilso]

We held this meeting yesterday, minutes are below. Our next meeting will be at #11717.

Chris mentions whatup meeting at TPAC: #11711.
simon: we need an agenda+ label for the f2f
chris: yes
anne: add the label through the meta repo, then run the script which will add it to all the repos

add missing idref reflections:
luke: we have for aria and for commandfor and popovertarget, the ability to set the targeted element from the equivalent of the idref attribute from js. that goes through element reflection. it was added for aria, and the new ones have them (commandfor and popovertarget), but we havent added them for html content attributes, like label element for. input element’s list, and various form elements which you can associate with a form. i raised an issue to say, should we add those missing ones? seemed like a good idea to add these. the question now is kind of on the shape of that and the exact behavior. ive initially proposed just adding new idl attributes that just do this specific thing, but it has been pointed out that there are existing properties for some or all of these that don’t quite do what we want but we could make them do it. there were questions about validation that these properties do. if we take label.control, that will only take labelable element, which currently i think the type is HTMLformcontrolelement, it would have to be raw htmlelement because of referencetarget, but we could make sure it only returns labelable elements if we wanted to. do people have thoughts? any objections?
mason: it sounds like a good idea, and i see the validation question, were there any other concerns raised?
luke: should we add a new form element or just keep control and make that writable and do the reflection? benefit of control is that we dont need to add a new property, but hard to feature detect if control is writable. we would need to add behavior to them so i dont know.
anne: has there been developer demand for these?
luke: for the label for element one, yes ive had people online mention it. for some of the others, i dont know. output’s for attribute seems pointless.
anne: the demand is for the setter?
luke: yes, to be able to set it to an element via js to get the same behavior as popovertargetelement.
keith: for web compat, you can see that the setter is undefined, so it should be trivial for feature detection.
mason: on the validation question, i dont think any of the other element reflection attributes do any validation. popovertarget can point to anything. is that the right thing to follow?
keith: for shadowroots you can set it and get null back?
mason: im talking about popovertargetelement and the target is not a popover. i thought that was a question for labelable things
luke: popovertarget is the precedent for do nothing, but maybe that should not return an element. for comandfor theres not really validation you can do
mason: if you wanted you could check the command and see if its the right one, but seems cleaner to just return the element
keith: if someone were to author the steps in the wrong order, tha twould fail. you could set it to a div and then add popover to it. idk if elements can become labelable
luke: custom elements can become registered and become form associated.
keith: that sounds like a real footgun if theres timing issues around CE registration for the validation
mason: i agree
simon: on the question of whether to introduce a new property, i think we should optimize for the long term ergonomics rather than feature detection. if feature detection is possible, then thats good enough. idk which is actually better for web devs, but in general we try to avoid duplicating functionality.
keith: on one hand, if you already know controls exists, then it becomes settable, but it lacks the symmetry with the others that are suffixed element. for label its not forElement, its control. which is the worse tradeoff? i have my opinion
luke: if we decide that reflectors dont do the validation, if we decide that it should do the same validation, then yes i think the answer will be use the existing one. with .control how does that work with custom elements today?
keith: if you set a for element, you can figure out if it was applied by looking at label.control. those are useful properties which justify their existence.
simon: yep, seems fair
mason: seems like there are 3 questions: should we do this, should we validate, and what should the names be?
keith: is this label one the only controversial?
luke: input list and ?? all have the behavior of is this valid. output for i dont think does, but doesn’t do anything. other one is the table header, something about table in the headers attribute, but that was added for completeness
keith: that begs the question, what are the use cases for this, maybe broken out into each one. we dont have to reflect every single one of these. currently theyre not all reflected. if we do some of them then that doesn’t really change the state of play, but if we do all of them is that really beneficial to developers? maybe we should break them out into separate issues, and the less controversial ones can land more easily.
luke: im happy to separate label for.
anne: it doesn’t seem like theres that much demand
luke: i could ask on social media but then people will just say yes
simon: upvotes is a property of has this been shared
luke: ill separate into separate issues and go from there

declarative css modules:
kurt: i have a pr ready, would appreciate some feedback, its my first PR in html. reading the stage 2 requirements, i think it meets that but is there more requirements that need to be met?
anne: i havent had a chance to review yet, but it does seem like the pr doesn’t build? theres a red x at the bottom. its the conformance checker
kurt: other than that, if someone wants to take a look
chris wilson: to focus in on stage question, do we have consensus on stage 2? the difference is that there is a draft spec, and consensus that the rough api shape is the right thing to solve the problem.
olli: i think i want to take alook at how nested shadowdoms are handled. or do we end up leaking css modules from inner ones to others or vice versa?
kurt: that is how the module system works, so it would
chris wilson: olli, can you review next time and come back to the stage question?
anne: were domenics comments resolved?
kurt: yes, domenic left in support of this
anne: initially he had some issues with how module mappings work
kurt: he said that is resolved with this new approach
anne: reading his comment, he wanted also json in js modules to be solved with the same kind of system. are you sure that all of that is resolved by this? it seems like there were some larger asks
kurt: anything serializable to a data url or import map ?? includes those, that got brought up and got resolved as the bigger approach
anne: thanks

allow focus if descendant has focus:
fernando: during the last meeting domenic raised a point here, related to permissions policy user activation. i am trying to write the spec for the last resolution at tpac, allowing parent frame to set focus in iframe. he was worried that we were going with loose behavior and if there was dev support for this. i wrote a comment in the pr explaining this, i talked to our customers, and if we go with a strict behavior of not allowing the child iframe which has the policy disabled to use the focus apis, that would break many experiences. that supports the case that this pr is making, of allowing the child iframe even with the policy disabled, once its got focus it can keep moving it around inside itself. i put some screenshots from teams and outlook. shares screen to show examples
anne: in the case of a embeds b embeds c, if ? is focused then b is allowed to focus arbitrary things?
fernando: yes, anything inside b or iframe that b is hosting
simon: but b could set a policy to disallow c from stealing focus, and then isolation would be within c
olli: can b then steal stuff which was meant for c? and then move focus to c and then steal focus from c?
fernando: yes, because b had the power to move focus around, so it sounds like it should be able to. idk what the concern would be there
anne: as far as i understand from the pr, this change doesn’t impact the permission at all. this sidesteps the permission. if we have a case of even if its just a embeds b embeds c, then if c has focus through the user, then if b has some loop where it tries to call element.focus on one of its things, it will now succeed where it would previously not. and maybe thats ok, but it seems a little weird
olli: i think we have had a security issue with this, but it might have been with the browser ui and the webpage, so you could steal input for the browser ui, but this is similarish issue
taylore: this would now let b succeed, but b was always able to steal focus. a can steal from b or c when its in focus. shares screen to show example
anne: is it true that with the current thing a can steal focus? it could block itself in which case it wouldn’t be able to steal focus. that would be weird because then a couldn’t steal it but then b could?
taylore: if a was disabled a b was allow self
anne: a could no longer disable itself because the initial check doesn’t return true but the descendant check returns true, it ends up disabling part of the feature of giving people control over this.
taylore: if those were switched, then b - allow self applies to everything in the same origin. maybe that would cause some issues.
anne: if a sets it to none, i forgot if it propagates to b
fernando: yes, b cannot override that
anne: even though it gets disabled all the way through, it doesnt matter because the first check won’t go trhough but the third will, so you cant actually disable it anymore with this proposed change
taylore: allow self lets you move focus on any descendant.
anne: the first step of the allow focus algorithms checks allowed to use, but that check no longer ends up mattering because of the inclusive descendant check
fernando: but the inclusive descendant check has focus
anne: it matters if one of them does have focus. previously it would return false in that case because the policy did not allow for it, and now it would return true
fernando: yes, thats intended. in that case, the reason is that if you have focus or your descendants have focus, then you have the power to move focus around. teams wants to give the app the freedom to move itself
anne: if teams want it, then cant they just delegate this permission?
fernando: they dont want to the frame to steal focus when they dont explicitly pass it to the frame. for example, in the case of a b c, they dont want b or c to steal focus, perhaps while the app is loading then the user focuses on the search bar for teams, maybe b wants to focus, they want to disallow that, so when the user wants to load the app, then they pass the focus and b can do whatever it wants with focus.
taylore: i think we need to think through that allow none example, but the intended behavior is that something beneath something that is allow self - anything at the allow self level is allowed to set focus, and anything is allow none then it has a conditional behavior where it can set focus but only if its been focused manually by clicking it, and thats intended. our main question is, is this behavior even though its odd is it suitable for a policy? or we should change the name? but we do believe that the intended behvaior is what we want.
chris wilson: it seems like we need some more investigation here, and some convincing of the problem i guess?
anne: its not clear to me that if b has focus then c can always steal it. you could imagine that b could be an ad and c could be a point of sale, and you dont want b to be able to steal focus.
fernando: yes, you have to trust the inner app
taylore: this is how things currently work, right?
leo: maybe we can better illustrate how this works today and point out the delta?
anne: current behavior meaning current implementations that dont follow the spec?
taylore: whats possible today, and how they set programmatic focus
anne: that would vary across implementations

meeting times:
olli: now that domenic wont be joining, should we have different times? usually US-japan friendly zone its me and chromium folks, and its a bit late time for me, and theres the other one
chris wilson: i asked the question before about whether we want to keep the one thats later than this for everyone meeting, i think the general consensus is that we want to keep the one thats earlier than this, eu-japan. maybe i should just set a poll and see if we want to move down to just doing the two different timezones.