Upcoming WHATNOT meeting on 2024-07-18

Thank you all for attending the meeting today and special thanks to Keith Cirkel for copiously taking meeting notes! Here are the notes from this meeting (the next one is at https://github.com/whatwg/html/issues/10496):

Agenda

Attendees: Luke Warlow, Panos Astithas, David Baron, Keith Cirkel, Emilio Cobos Álvarez, Sanket Joshi, Andrew Kaster, Una Kravets, Schalk Neethling, Olli Pettay, Ajay Rahatekar, Noam Rosenthal, Kagami Rosylight, Benjamin VanderSloot, Anne van Kesteren, Yoav Weiss, Chris Harrelson, Joey Arhar
Scribe: Keith Cirkel

Review past action items
1. Domenic will ping Mason/Joey for implementation interest from Chromium on Enhance <input type=color> with alpha and colorspace=display-p3. Kagami will ask Emilio/Olli to chime in.
  1. Joey and Emilio are positive about the proposal.
2. Keith will summarize the options and tradeoffs on Tie in AbortControllers with CustomElements.
  1. Done. Anne will move it to the DOM repo and Keith will update the title.
Carryovers from last time
1. None.
New topics
1. [Yoav] Severing a document's opener relationship regardless of origin
  1. Yoav will ask Artur and Arthur to comment on the issue.
2. [Andrew] redact location.ancestorOrigins according to Referrer Policy
  1. Chris will find someone from Chromium to look into this. Anne thinks the WebKit behavior can be changed. If Chromium is on board, we will need someone to step up with a concrete proposal to review.
3. [Keith] [Proposal] Invoker Buttons - allowing popover/dialog and more to be invoked without JS
  1. Keith will switch to use "source". Discussed various options around naming, and consensus is for the name to start with a single dash. Agreed to only support <button> for now.
4. [Michael] "Fragment serializing algorithm" outputs node itself instead of its contents for elements in non-HTML documents
  1. Luke has some precursory work that will move things forward here.

Action Items

@annevk will move Tie in AbortControllers with CustomElements to the DOM repo and @keithamus will update the title.
@yoavweiss will ask @arturjanc and @ArthurSonzogni to comment on the Severing a document's opener relationship regardless of origin issue.
@chrishtr will find someone from Chromium to look into redact location.ancestorOrigins according to Referrer Policy.

Minutes

Topic: Input type color alpha & p3

Panos: Welcome. Reviewing past action items. First; Joey?
Joey: Looks cool, briefly skimmed PR. One question: alpha attribute has more UI to let user choose alpha. Should it have more UI to choose from other colour spaces too?
Anne: In principle that would be good but we cannot mandate the UI. At least picking from P3 which is larger than RGB.
David: I would assume it's not about the user picking a colour space but picking within specified.
Anne: Correct
Joey: Not sure how we should represent the UI but sounds good.
Anne: Ideally the OS has such a picker.
Olli: If OS does not have that kind of picker, what should happen?
Anne: Limited to colours in the picker currently but serialises to P3. Also happens when your display cannot display P3 colours. Will be limitations. Best effort on both sides.
Luke: FWIW chrome has a web based interface. In terms of UI the colour picker in devtools should have the UI elements you need; alpha slider, colour spaces.
Joey: Thanks. Sounds promising.
Panos: Olli?
Olli: Was hoping to ask someone else who has experience with colours. Emilio?
Emilio: Off hand seems fine. Could imagine either extending colourspace attribute to support all css supported spaces or even more general make it boolean to make it return css colours. It's fine to just specify the colour space you want it returned in, with UI changes needed to select those. Display p3 makes sense, but it could be any other right? No reason to now allow, for e.g., oklab.
Anne: Main reason for limitation is there are no wider gamuts than p3 in other APIs. Most displays aren't there either. Not sure how useful it is to display others. Definitely could add more later. It makes sense to me if it's somewhat in tandem with display technology.
Emilio: Fair.
Panos: Next steps?
Anne: More comments on the issue would be great. Implementor interest, not sure how to count the signals. Explicit comments would be good if their team is interested.

Topic: Tie in AbortControllers with CustomElements

Keith: Everyone happy with the current direction?
Anne: it might be moved into the DOM repo. Maybe retitled, it seems to be a general disconnected API?

Topic: Severing a document's opener relationship regardless of origin

Yoav: Missed last discussion. If I read correctly there are a couple of open questions for me. One; potentially want noopener that doesn't allow popups in order to make it useful for bfcache. Not objecting but seems something we can add on as a separate PR as an extra value. Similarly relationship with COAP - we can have a more conservative approach not effecting cross origin isolated state. Expand to scenarios, backward compatible change. Haven't heard back from others. Wondering if we can push this forward if folks agree these questions can be dealt with later.
Anne: We do want input from someone on Google familiar with this stuff. If Artur has strong opinions? Has it been reviewed?
Yoav: More of the latter - it has been reviewed. I can ask to chime in
Anne: Would be good to get input from Kamil or the two Arturs. Seems reasonable to defer the value. Noreferrer with popups? Single noreferrer value for now. Then leaving COAP as exercise for the future seems possible; cross origin isolated getter can be used to figure out if you're in such an environment. Main concern is Artur to affirm if it fits with current design. Integration stuff - in particular reporting and such. Not 100% on that.
Yoav: He approved the CL to land in chromium behind a flag so I think he's okay with the design. I'll get him to chime in.

Topic: redact location.ancestorOrigins according to Referrer Policy

keith: i dont think this is my issue?
anne: this was raised by a ladybird developer
keith: ah i added agenda+
Andrew: We had a PR in ladybird adding ancestor origins. Issue from 2016 with lots of comments but no resolution. Posted in whatwg matrix. Mike said to bring it up here. Question is; what to do about this API? Firefox doesn't implement it. Should we? Perhaps with redactions? It seems an open question which origins should be exposed by this API, and what to do about it.
Anne: I still think the issue is valid and applies to a similarly named service worker API. Solution is to perhaps redact certain origins. You can determine how many parents you have… or can you? Perhaps we also need to figure that out. It does seem weird that apart from referrer this is essentially the only place that gives you a handle on who your parents are. If you're widely embedded iframe gives you quite a bit of info that maybe you shouldn't have, at least without opt in.
Luke: Window.top and window.parent?
Anne: only settable not gettable
Olli: Up to webkit and blink if you're okay to change you behaviour?
Anne: I think we'd be okay changing this. Need better definition
Olli: What has been suggested is reasonable.
Anne: I wrote a PR for this while at mozilla but I dont think it got review. It may have had some issues. In 2017…
Olli: Any opinions on Chromium side?
Chris:n Opinions on this?
Joey: on location ancestor origins? Not familiar with this API.
Panos: Know who is right to ask?
Chris: Proposed behavior? Does it match current browsers?
Anne: Only chrome and safari implement this API
Emilio: I see service worker API uses frozen array. Location API uses a weird interface for domstringlist. I dont think anything else uses it. It's supposed to be sameobject but it isn't in blink. Can we get away with changing it to frozenarray? Would make implementation a lot easier. It's fine to split into two changes.
Anne: Yeah that's a separate discussion
Chris: I'll take an action item… in the meantime can someone make a precise proposal?
Olli: The concrete concept is quite clear in the issue.
Chris: Which comment in particular?
Olli: Even the first one. Talking about referrer policy.
Chris: From Brad and Domenic
Olli: And Boris. Looks like Brave would like to limit this

Topic [Proposal] Invoker Buttons - allowing popover/dialog and more to be invoked without JS

keith: anne mentioned that commandevent has a proeprty invoker which refers to the button, is not the target its the related target but can't be called that, i think we want to rename this to something else. i dont think it can be invoker or command. we could call it button but i dont know how that jives. luke suggested commander. im easy with whatever name.
luke: commandsource maybe?
keith: sourcetarget? matches with relatedtarget
luke: sourcetarget is the thing that youre on?
anne: i think source can be fine. it doesn't have to be long, its already the command event.
keith: i'm fine with source, i can go make the change
luke: is that the thing that's more useful on events? to get the thing that dispatched them?
keith: command event is different. generally you would use target, but this is dispatched from another target. forms is one, but you could use form submitter.
anne: there is precedent for source. its on postmessage message event.
olli: xul also has source
keith: it seems source is well aligned. i'm gonna go do that. second comment is around custom commands that arent recognized as a native builtin. there's another comment around naming which requires dashes. that brought up the discussion that if we have to use dashes for the builtins, for non-builtins it requires a dash, but that can no longer apply as a heuristic if the builtins have a dash, so we can start it with a single or doulbe dash. domenic said we can defer the feature. I feel that it's an important thing and we should keep it and we should resolve on some other heuristic. I'm fine with adding a preceding dash if that's a comfortable direction.
luke: is there any precedent for a name requiring ?? single dash seems weird
anne: element names dont have hyphens
keith: we could also flip it and say that builtins must have a dash. we already have close for details
anne: that's not good
luke: id want it to start with two dashes to match css
keith: as jake points out, the reason that css has a double dash because single dash is for vendor prefixes. double dash seems to align well and developers will already know. we could surround them in parenthesis and that would be valid but look weird.
anne: as long as it contains a non alpha non hyphen its fine. you can do the inverse of a valid name is a valid custom name.
keith: so number one foo is a valid name?
luke: i would rather have a specific paradigm to be followed so it's easy to understand
keith: other heuristic is to only allow custom commands on non recognized elements. it wouldn't dispatch on a dialog element but it would if its my-dialog, but it limits it to custom elements which isn't great
luke: yeah this is already easier for web components but is harder in vue. I'm fine with double dash or colon. I guess it's just what fits in with the html design best. possible alternative is that custom action stuff we just do through a separate attribute and then they don't clash
keith: you can have a command= and a customcommand... we already have a lot of conditionals with type button and I'm already worried that we're going to be in a situation where people don't fully understand the heuristics and it silently fails. at the moment in chrome at least it console warns.
anne: i'm not sure why we would require two hyphens, i think a single one…
luke: making it start with one hyphen is fine. starting with something other than a hyphen could be good
anne: starting with a hyphen is fine. if someone could communicate this to developer community to get feedback that would be good
keith: we could have it start with something that isnt alphanumeric, so it could be a hyphen or underscore or other symbols and the community would settle on a convention there. it doesn't necessarily restrict the builtins any more. I doubt we would do that in html. it avoids the need to - avoids the particular symbol, you can use any of them
luke: the downside of that is that it makes it harder to read and understand whats going on
anne: that was a compelling argument to me, we should have a singular syntax for ease of learning and understanding
keith: is there a reason to not pick dash? does it make sense to just go with dash or should we seek developer opinions?
anne: we should go with dash and announce it and see if there's an alternative we didn't think of
anne: I want time in the next 3 weeks to review the html pr. Most things look good to me.
luke: only working with buttons rather than buttons and inputs. currently popovertarget and as currently proposed command will work on both button and input type=button submit or reset under various conditions. I guess technically an image input too. this has lead to already one bug where there's an inconsistency between button and input for popovertarget. do we need to support input at all? should we just make these work on button? Generally speaking I think people are using button.
olli: eventually it should be working everywhere. it could be default handling for click that triggers a command.
luke: we want it to be accessible, in a button like thing. custom elements came up which could work if we have an idl attribute. i think the attribute specifically we only allow it on buttons and only button-like inputs currently. i don't think we would allow it on the attribute on custom elements. they could set the javascript.
keith: bigger conversation around custom elements as buttons that's worth parking because there's a lot around that. i dont think its just commands that the community is interested in against the entire surface area of what a button does. but yeah the overarching specific issue here is do we continue to enable this for input type=submit/image/reset/button.
anne: i think we already wanted to disable them for reset and i guess image as well because that counts as submit. it would only work for input type=button
luke: well if it's outside a form… in webkit i made it work with reset and button to match the spec, but that's a discussion that needs to happen
anne: there's an issue for that right?
luke: yes. firefox matches the spec. doesn't work for button. chrome doesn't match the spec and doesn't work with reset. for what it's worth i think input or button varieties are legacy in my mind and it would be ok to not support them. in webkit they are separate code paths. steer people toward using button
anne: main reason for favoring this is that it's not a feature that's tied for forms, and input is a form feature, and already is very overloaded. if we can expose something or avoid exposing something on input that seems like a win to me.
keith: I'm inclined to agree. I don't know how many people, I don't think anyone uses input type button, i think it makes the most sense. i could see deprecating button but i dont think thats a challenge worth raising any time soon
luke: joey do you have feedback?
joey: yes only support the button element
olli: i still want this to be supported everywhere, but that's something we can figure out later
keith: yeah i guess it's easier to support button now and add it to additional elements if we feel that there's a strong use case for that
luke: sounds good to me
keith: sounds like we're all resolved then

Topic "Fragment serializing algorithm" outputs node itself instead of its contents for elements in non-HTML documents

Anne: This is another concern on legacy algorithms. DOM parsing is in a bad state.
Luke: I have a draft migrating XML serializer to HTML spec. This seems a prerequisite for this. It touches some of this stuff. Once that's done we can go through the issues on domparsing and see if they're still valid. Then see what the solution looks like.
Anne: If we move everything over we can talk to the w3c about moving the repo, then migrate all issues into html. That would be nice. We moved the text over but haven't solved the underlying issues. Maybe now more tractable.
Luke: One or two normative changes during migration but the large part of the issues are still there. The big red boxes at the start of the spec would be nice to remove. This issue can be solved similar to how outerhtml is implemented, although that's weird - make an imaginary element then get its contents. Ladybird has a flag in the algorithm as to whether or not to output the outer element, that's probably the best option here. I'll try to do that.
Panos: Andrew do you have more context from Ladybird side?
Andrew: I think Anne said it - we're finding legacy algorithms as we implement. We haven't aggregated these into a list but we could. All the places we implement the algorithm then looked and realised it's not what anyone does. We can tackle them one by one or aggregate them. What Luke proposed sounds good to me.

Panos: In that case we're out of topics. Anything else?

Joey: Select element improvements - UA stylesheet changes, I want to propose a lot of them. Where should we be talking about it? We have the shared forms meeting, css, and this. UA style changes should be in CSS or joint? If we resolve there is it okay to go into HTML?
Anne: The joint meeting seems fine, also CSSWG. Historically it's been CSSWG doing default UA changes but not bringing them to us. I assume it won't happen here. Some co-operation needs improvement. CSS suggests default sheets but they're example sheets not to be implemented. So some confusion.
Joey: I'd want it in HTML, I mostly want to know what meeting we should talk about it in.
David: Joint meeting seems reasonable. Some categories of things - that are mostly about css - can be done in CSSWG but this has a lot of html topics inside of it.
Joey: Sounds good thanks.

whatwg / html