Upcoming WHATNOT meeting on 2025-02-13

[past]

What is the issue with the HTML Standard?

Yesterday we held our weekly triage call (#10972) and I will post the meeting notes there in a bit. The next one is scheduled for February 13, 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 Chris and Mason for taking meeting notes! Here are the notes from this meeting (the next one is at #11026):

Agenda

Attendees: Alison Maher, Emlio Cobos Álvarez, Ollie Pettay, Keith Cirkel, Noam Rosenthal, Kagami Rosylight, Luke Warlow, Chris Wilson, Joey Arhar, Mason Freed, Anne van Kesteren, Kurt Catti-Schmidt, Benjamin VanderSloot, Panos Astithas, Rakesh Goulikar, Sanket Joshi, Stephen Chenney, Tantek Celik, Di Zhang
Scribe: Chris and Mason

1. Review past action items
   1. Noam to open an issue for the existing blocking styles interop issue.
      1. Carry over.
   2. Keith to make a big table of loading vs. autoplay vs. preload as the next step for loading=lazy.
      1. Carry over.
   3. Chris to poke Anne on whether the interesttarget attribute/proposal is a problem worth solving.
      1. Agreed to move to stage 1.
   4. Mason and Olli to look at Missing attribute changed steps for dialog can cause assertions to be hit (Spec PR).
      1. Mason needs to review this some more.
2. Carryovers from last time
   1. [Mason] The interactivity property
      1. Everyone is encouraged to take a look and we'll discuss it again next time.
3. New topics
   1. [Keith] Clarify IDL reflection for closedby attribute
      1. Consensus to move forward with the proposed approach.
   2. [Joey] Customizable <select> element
      1. Olli will ask Henri to look at the Mozilla standards position. Olli and Anne will review the User interaction PR. Consensus to move this to stage 3.
   3. [Kurt] Support fragment references in the <link> tag's href attribute
      1. Consensus to mark this as stage 1.
   4. [Kurt] Add sheet attribute to the <link> tag's for CSS @sheet support
      1. Carry over.

Action Items

1. @noamr to open an issue for the existing blocking styles interop issue.
2. @keithamus to make a big table of loading vs. autoplay vs. preload as the next step for loading=lazy.
3. @mfreed7 to look some more at Missing attribute changed steps for dialog can cause assertions to be hit (Spec PR).
4. @smaug---- will ask @hsivonen to look at the Mozilla standards position. @smaug---- and @annevk will review the User interaction PR.

Minutes

Panos: starting with past actions, existing blocking styles.
Noam: I dropped this, keep as carryover, I need to do some testing of the interop difference before filing.
Keith: I didn't make the big table yet.
Chris: I did poke Anne, but haven't heard back. If we haven't heard by next week, presume we can promote to stage 1. [Anne joined later vv]
Mason: Missing attribute changed step done, but not completely yet. Dialog open attr is funny and needs special care.
Luke: encourage implementers to take a look at the spec PR now, though.
Anne: no strong objection to moving interesttarget attr proposal to stage 1.
Panos: One carryover, interactivity property.
Mason: Domenic has been giving it a thorough review, encourage other implementers to take a look and comment.
Panos: let's carry over to next week then. Keith, IDL reflection for closedby?
Keith: it's not (contrary to current spec) just a numerator to limited values. It's more like a runtime dependent value. I think I raised a PR to fix this, but there's a build failure I need to resolve - been swamped.
Luke: I added this to the agenda to get implementer interest, just needs reflecting on the PR.
Keith: seems easy enough to make the change, not out of line with other attributes.
Mason: If this is not the current Chrome behavior I'm happy to change.
Keith: I think this is the current Chrome behavior.
Joey: I'm wondering what else we can do to get to stage 3 on customizable select. The Alt text issue still doesn't sound agreed on. Is this the only blocker? I might be making some small tweaks to the parser PR for some edge cases, and how input closes selects.
Luke: Is this something we can make changes to after we go stage 3?
Joey: Yes.
Luke: It would be nice if we could add basic filtering as a thing in the future, but this is something web developers are going to do today.
Mason: Yes. We're just trying to deal with shipping, this change is fairly major.
Anne: this is forbidden by the content model, I think
Joey: Yes. We don't have a great way from the a11y point of view to make those accessible.
Anne: Maybe the ancestor chain should be part of this, like if my parent is select or only if it's an option.
Luke: Do we have use counters for this happening?
Joey: for input closing selects, yes, but no for what the parent is in this case.
Luke: I think it's possible to make it accessible.
Joey: I would love to work on that with a11y people after this.
Anne: if you implement the new parser where input just closes it, and add logging there, logging could log the tag names of the element stack and we could see how far above is the select. All that requires solving the a11y problem though.
Mason: one the parser change has landed, we can investigate things like this.
Panos: to go back to Joey's original question, can we move to stage 3?
Anne: I think we should find some solution to the alt thing
Joey: I think there's a bunch of different places that we could be using the alt text and there's varying levels of disagreement.
Anne: for web developers, I think it would be nice if the alt text was used. Just seems like a weird model.
Joey: I don't have strong opinions, except for the server submitted value. We want it to work well in browsers that do and don't support customizable select. If the server submitted value includes alt text in the browser that supports customizable select, that's going to cause different values on the server, and that's a big blocker to using this; it would discourage devs from using alt text.
MAson: this was our a11y people's feedback as well, it would discourage alt text usage.
Luke: Could you just specify the value on the option?
Joey: Yes, that's one option.
Mason: There's a comment in there from Aaron, one of our a11y people.
Anne: if no one else cares about this concern, I'm willing to drop it. We do have to specify what the rendered label is going to be. Maybe change it into there is an API label, and the label getter returns another computed label.
Joey: sounds like a good solution, happy to go implement that.
Panos: So if we go this route, can we mark this as stage three?
Anne: I wonder how much the PRs have been reviewed, but I guess they have been reviewed a fair bit.
Olli: I think the interaction stuff needs some review, but not sure that's enough to …
Anne: (some question about selected content leading to too much duplication from Henri?)
Olli: I don't know about that, I'll ask Henri. And take a look at the most recent updates.
Anne: I can't find his comment anymore.
Joey: it's here: mozilla/standards-positions#1142
Anne: no followup yet
Panos: we're probably not ready for stage 3 yet? But what are the concrete open issues? 1. Get Henri's feedback on the standards position (Olli to double-check), 2. Olli wants to review the event handling.
Olli: Still not sure if Apple has taken a look at that.
Anne: I don't think anyone has.
Panos: do they need to?
Anne: Probably. Probably me. Swamped lately.
Joey: one comment about it being terse, and I've updated it accordingly. No comments since then.
Mason: The action items are all to review the PRs. That sounds like being in stage 3. Should we keep waiting?
Olli: Maybe it's fine to go to 3.
Panos: we can always go backwards in the stages, if we find something unexpected.
Panos: which PRs are Olli and Anne to review?
Joey: added to notes
Mason: So stage 3 then?
Olli: I think so, yeah
Panos: if you discover something bad, we can go back to stage 2 next week.
Anne: I think it's ok. It's an unusual/new thing in general, so it needs some experimentation. But probably not worth deferring.
Panos: in that case, let's mark it as stage 3. Thanks in advance for the reviews still to come.
Panos: next topic is for Kurt, discuss in whatever order. Support fragment references in <link>
Kurt: I'm working on @sheets, stylesheets that you can define before you're ready
Kurt: Declarative shadow dom people want to share styles, end up writing components that use DSD to isolate the IDs, but then they have isolated styles. Could alleviate that problem - give me a style reference from a <style> tag somewhere else in the doc. This works without @sheet. Then that's proposal #2.
Kurt: Add a sheet property to selected sheets. So for now, can we just do the <link> with a reference to a style tag elsewhere.
Kurt: Let me know if there are strong opinions or if there are alternate solutions.
Emilio: the id would be in the owner document, so it needs to be top level. document.getElementById(foo). But you might want to disable those?
Kurt: That's @sheet. This gives you styles that are already applying to the document, you can share. If you want to define them and not apply them, that's @sheet. That's still in the spec stage, not quite ready. But in the meantime, at least the shared styles case can be solved.
Emilio: Same as having a <link> in both trees referring to the same sheet.
Kurt: Yes, basically. But not a file/URL.
Emilio: not top tree scope
Kurt: Any tree scope actually?
Noam: likely needs to be top level light DOM. Eventually maybe be able to refer to others? Same as link inside shadow dom, with fragment link - scrolls to that place in the top level doc.
Emilio: SVG fragment stuff looks across shadow trees.
Anne: It does?
Emilio: That's my recollection. Current tree, then ancestor trees.
Anne: Who did that?
Panos: nobody here!
Emilio: That's what I remember. Likely for SVG <use>.
Anne: I thought SVG was like others - same tree. I wonder what happened.
Emilio: I don't see much of the use case without being able to disable it.
Anne: foo.css#bar - what does the #bar reference?
Kurt: no foo.css. Same doc. foo.html you have a style tag, then shadow root, then <link rel="some style tag reference">. Base styles in light DOM, want to inherit, you get that.
Emilio: You can do that with today already. If the link is in the doc already, it blocks so you don't FOUC. It's cached, etc. I don't see the benefit in isolation.
Kurt: In Chromium today, link with external file, you can get FOUC.
Emilio: scripts have to wait for stylesheets, that works everywhere.
Luke: In terms of use cases, a big one is "I'm building an app that uses WC, and I want components to inherit styles". Here, you don't get that - this makes sense. E.g. global reset that applies everywhere. That makes sense. How often you'd like that to be inline styles though? Vs. external stylesheet. Useful if you come up with an agreement that the top level docs load some stylesheet with some ID and you can refer to it. Interesting if you could do this with id on link that is an external stylesheet. Does that work? There are CSP issues. Does this work for <link> at the top?
Kurt: I hadn't thought of that. Could include that - current proposal doesn't do that.
Keith: Why not use a link tag? The URL that the link references in the light DOM might have particulars - difficult to reconcile. Common to put a # to invalidate cache - propagating that all the way through would be difficult. If there's a hand-typed IDREF instead, that's easier. There's a valid use case therefore.
Noam: Use case is very strong. Personally I've hit this myself. We shouldn't make it hard - don't make them create external resources to do something simple. Basic use case to give importability. We should expand to <script> in the future. Inline script that can be imported with #foo. Separate from @sheet, import a certain sheet from css file. Also, regardless, there are CSP things, but there are also performance best practices that all say to put it in a <style> tag, rather than a <link>. Always security vs. performance best practice debates. Because of this gap, people are constrained. I helped shape this proposal, it's long overdue.
Emilio: Ok, I buy the completeness proposal, when <link> isn't feasible. I wonder what happens during mutations, etc. All DOM owned stylesheets from CSSOM are unique at this point. If you .insertRule on top level stylesheet, what happens? Also DOM mutations - what if you change IDs. Mutations need some thought. I get the use case - mostly static stylesheets. Still need a good story for mutations. A consistent thing would be to propagate those, but for CSSOM mutation, I'm not sure.
Kurt: This is an open question. Going back to SVG - references are live. CSS with imports - behave as separate instances, copy on write. I need to figure this out. What do people think about what makes sense, in HTML?
Emilio: at least DOM mutations should be clear. If you link, mutate the stylesheet, then link again and get different contents. That'd be weird. The CSSOM case is kind of a pain. Depends on impl. The obvious way would be to use a shallow copy mechanism. But that's a separate stylesheet object. Style.sheet would be different. CSSOM mutations - expect those to be different. When do styles get reloaded, what if you mutate inline reference links. Etc.
Anne: Syntax has to change. The href attribute - you parse this as a link, it'll point to the current document. If you have <base> you'll load another doc, etc. Need to define the same magic SVG thing that's local. That's not a concept HTML has. Maybe we shouldn't add it because it's confusing. Maybe a dedicated attribute for this, which won't trigger loads in old browsers.
Noam: We have a precedent: rel=expect local reference for render blocking on an element. Works the same. We do need to figure out the old browsers question - that's a good one. With mutations, we do need to figure out the details. Something like it's copied, but gets re-applied on mutations, etc. Judgement calls.
Kurt: for older browsers, quick thought: use the rel attribute e.g. <link rel=local_stylesheet>. Old browsers will ignore it. Some other string to differentiate. Then keep using href.
Kurt: Are we good to move to stage 1?
Panos: worth of exploration for the group? Any objections?
Panos: ok, moving to stage 1 for the first one (link href references)
Kurt: for the @sheet discussion, it'll be long. No time today.
Panos: follow up next time.