Upcoming WHATNOT meeting on 2025-02-20

[past]

What is the issue with the HTML Standard?

Today we held our weekly triage call (#11010) and I will post the meeting notes there in a bit. The next one is scheduled for February 20, 1am PST. Note that this is 1 week later in an APAC + 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]

Hey @whatwg/triage, there are only carryover topics in the agenda right now. Please tag anything else you'd like to discuss in this meeting.

[past]

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

Agenda

Attendees: Oll Pettayi, Simon Pieters, Philip Jägenstedt, Keith Cirkel, Noam Rosenthal, Kagami Rosylight, Domenic Denicola, Emilio Cobos Álvarez, Mike Smith, Luke Warlow
Scribe: Noam

1. Review past action items
   1. Noam to open an issue for the existing blocking styles interop issue.
      1. Let's take it off the agenda, Noam has it on his to-do list.
   2. Keith to make a big table of loading vs. autoplay vs. preload as the next step for loading=lazy.
      1. Let's take it off the agenda, Keith will bring it back up when he's ready.
   3. Mason to look some more at Missing attribute changed steps for dialog can cause assertions to be hit (Spec PR).
      1. Mason did the work, currently in Luke's court. We'll keep monitoring.
   4. (Customizable-<select>) Olli will ask Henri to look at the Mozilla standards position. Olli and Anne will review the User interaction PR.
      1. [Olli] did ask hsivonen
      2. [Olli] did look into the user interaction part which was rather vague on keydown handling, a PR was created after that. And mousedown/up handling should probably check that we're dealing with the primary button.
2. Carryovers from last time
   1. [Kurt] Add sheet attribute to the <link> tag's for CSS @sheet support
3. New topics
   1. [Luke] Add request-close command for dialogs
   2. [Philip] Heads up about html-build Bikeshed experiment
   3. [Luke] Commandfor buttons with missing or invalid type attributes currently work as command buttons
   4. Lift restriction on buttons with implicit type=submit and command/commandfor being no-op #10832

Action Items

1. @noamr to convey generally positive feedback and minor points of concerns about sheet attribute to the issue

Minutes

Removing Noam's carryover from the past action items
Keith: I'll bring back the AI when I'm ready.
Domenic: I didn't get the sense the spec PR for the attribute changed steps is ready. (re action item C)
Domenic: last comment is from Mason, that it's ok in chromium, asking Luke to sync the PR. Seems to be in Luke's court
Philip: I talked to Mason yesterday, he said we could leave that
Olli: I pinged Henri, it's a winter holiday week. I was looking at the user interaction part and chatted with Joey, it's a bit too vague. Not sure how we can make this interoperable. I didn't see comments from Apple, would be good because of different OSes etc. But overall looking good
Philip: specific things with the PR, Olli?
Olli: spoke to Joey about this. e.g. the spec says "any keydown handles the select box", and mousedown, it probably needs to be the primary button only.
Domenic: you linked to the commit from Joey. Are you happy at that level.
Olli: We at least need to get the keyboard interaction part, I think I'm happy with how it is now, not sure the mouse bit is there yet. E.g. it doesn't check primary button
Olli: I may not know about certain things, would be good to get a look from Apple

Sheet attribute

Domenic: Kurt isn't here but maybe someone knows things?
Noam: there are two issues, complementary. This is one of them. In the last meeting we talked about importing from a <style> in the document. This is about partially importing from a <style> (either in the document or out of the document). Based on CSS @sheet. Kind of CSS bundling. We'd need this change in the HTML spec for <link>, as a counterpart to (something like) CSS @import subsheet from "bundle.css". Kurt isn't here but I suggested he bring it to WHATNOT to get directional blessing.
Domenic: generally seems good. Possibly an issue if older browsers ignore the sheet="" attribute.
Noam: Yes, although if you write your CSS file to only have things inside @sheet, it's fine.
Keith: a small gotcha, but we can explain it to developers.
Simon: the IDL sheet attribute already exists, so we couldn't do straightforward IDL <-> content attribute reflection.
https://drafts.csswg.org/cssom/#the-linkstyle-interface has .sheet already ("includes" in https://html.spec.whatwg.org/#htmllinkelement )

[general dismay]

Noam: It's solvable, although we might have to get awkward.
Emilio: from Gecko's perspective, generally makes sense. There are other issues with @sheet but this particular issue isn't blocking.
Olli: dynamic mutation of the sheet="" attribute?
Emilio: yep that's one of the issues. CSSOM mutations and DOM mutations usually behave differently.

Domenic: new topic, Add request-close command for dialogs

Keith: it's more the appetite than the technical details
Keith: Are we comfortable with adding more commands? I'm supportive. Are others supportive?
Domenic: very supportive. Request-close is defined to be more useful than close. Centralized logic
Domenic: request-close acts like a user did that, with a cancel event etc, while close just shuts down the dialog
Olli: Need to make sure the events happen at a safe time
Keith: They all fire synchronously
Olli: We need to be in some reasonable state if the event handler changes things, we need to be careful with this
Domenic: there is some handling of this in the close watcher infra itself. I suspect it's applicable but good to check
Olli: TrustedTypes had quite a few issues like this about scripts running at unexpected times
Olli: It's the mutation-event style issues
Domenic: that feels a bit strong
Olli: e.g. same attribute nodes for multiple elements
Domenic: I feel the command API is not that bad
Keith: it checks at the beginning of request-close whether the open attribute is open, but not at the beginning of the close watcher. So there's a bit to do there
Domenic: We need tests for these horrible things
Domenic: generally positive though

Philip: I'm trying a thing with HTML wattsi/bikeshed etc
Philip: Our first answer is that perf is not good enough. We tried with DOMx12
Philip: Hacking up html-build preprocessor steps (in rust). My idea is to put enough into the preprocessor so that bikeshed can build it
Philip: If anyone is interested in this, or knows of additional reasons why bikeshed wouldn't work, please let me know. I want the list of potential blockers. I realize it's not easy. Exploring, no commitment. Checking if this is possible
Keith: feel free to ask Rust questions
Philip: How much is it a hassle for you that we have bikeshed and wattsi?
Noam: I think the mental load of the difference between specs is still very big
Keith: I don't think HTML is rebase friendly as a language. In bikeshed we kind of avoid this problem. Also individual tooling, e.g. HTML errors can be avoided. Also the tooling doesn't feel robust enough to pinpoint mistakes
Philip: it's because the preprocessor is changing everything, so the line numbers are not close
Domenic: it runs it twice, once with preprocessor and once without, to look at the errors
Philip: OK, that's good to know it's worth looking into this
Domenic: Interested in Luke's perspective
Luke: I find bikeshed more robust syntax. Would be good to be consistent about shorthand/longhand syntax
Luke: I run specfmt and hope for the best, but it's hard to know if what I'm writing is editorially correct. E.g. the optional DOM tags… it would be good to get to a more consistent model
Domenic: My experience is largely about that point, more than about bikeshed/wattsi, but rather about different styles between bikeshed specs. With wattsi we're forced into HTML, but it's not different from some of Anne's specs that require raw HTML. It would be great if we had Markdown style rather than raw html
Philip: I assume people prefer the more compact form of bikeshed
Simon: I have mixed experience with Markdown, e.g. when it comes to nested tables within lists etc. you can get unexpected results using markdown, at that point I usually switch to HTML
Domenic: it's more of a Markdown issue, e.g. MarkDown tables are annoying. Other weird things that are more of a bikeshed thing, that make you want to use <p> tags rather than the bikeshed variant.
Simon: perhaps HTML syntax for structure and markdown for inline?
Domenic: would be a good discussion
Philip: This is down the line, performance permits.
Domenic: maybe a feature requests for bikeshed is to have different lint flavors
Olli: the animations are annoying with the popups
Philip: also bikeshed stability. But this is a heads up that I'm looking into this
Simon: if bikeshed doesn't need to support markdown for structure level, it might be a perf boost.
My main annoyance with wattsi is cross-references from other specs, keep having to do those manually. There is no checking, those are just links.
Philip: This is tricky, might have to be a manual spec. There's a long list of those in the spec.
Domenic: I tried to fix this at some point. But people pushed back.

Luke: I looked at the request-close thing, seems positive overall? There was some complexities with commandfor. One thing that wasn't discussed is buttons in the auto state for command/commandfor.
Luke: #11044 buttons that have an implicit/ambiguous type currently act as a submit button. When you have command/commandfor, it no longer acts like a submit button. It also doesn't act as a command button. We want the developer to set a type for backwards compat. When we added the auto status this got a bit muddled. I have a PR that sets this back. We probably want to add an explicit type here. The implementation and tests assert the original plan rather than the spec
Luke: The difference is when you're handling a command button, it says that it's in the submit state, do nothing. The original idea was also to do nothing when the state is auto. The idea is that in the future we'd be able to remove this restriction. We don't want to do that now because it would submit the form in older browsers. For invalid types, the spec says that they're still submit buttons.
Simon: We should switch to the behavior we want long term immediately and have document conformance rules to catch the unexpected behavior in older browsers. Otherwise authors would have to add type=button for longer, and it would be messier as we'd have 3 behaviors instead of two.
Keith: The prior conclusion was that we'd have a "do nothing" transition period, we have an open issue to lift that, because there is a substantial dev facing issue about form submitting to end points with difficult to debug requests, because they look like form submission but do unexpected things. The auto state is mostly an editorial thing. The implementations sort of do that, even without reflecting "auto".
Luke: I was against this behavior initially. If you use command/commandfor, you probably have a polyfill that can prevent default on the click. Or add that logic. It's not the end of the world if you need that for a while. If we were to have this middle step, it would need to be shorter than previously planned. Waiting would probably mean it never happens and is never useful. I'm fine with changing the implementation to do the new things. Re the invalid type, because that acts the same as a missing type. It introduces potentially a forward compat problem, if we make it so that it fires the command, perhaps we add a type in the future that doesn't fire. It's worth clearing it up. Would be good to get implemented interest.
Keith: Joey offered to add use counters for invalid attributes. Perhaps we can check the HTTP archive?
Simon: The current behavior for invalid types is to submit. If there is a web compat constraint, that's the expectation. The future compat is also interesting. What's the most useful fallback behavior going forward
Keith: there is prework for invalid types, which is to deprecate invalid buttons being submit button.
Keith: we can start compat analysis now, for deprecation
Philip: I wasn't aware of this discussion. I reviewed the activation behavior, I don't exactly understand the proposal re. Activation. I don't think you can be both a submit and a command button? Perhaps there's some overlap where both can happen? Does the command button always win over submit/reset? Or the opposite? It's not clear from the spec
Luke: the original intention was that submit/reset only submits and resets. It turns out that a reset button can act like a popover button, and thus also for command. Chrome doesn't implement this. So basically the reset button can be a popover/command, and submit cannot.
Olli: I think we should fix this, the spec is confusing
Keith: there is a valid use case for running a command as a result of reset. It gets tricky with the auto states. More towards backwards compatibility than towards a desired behavior, because it's going to be a mess. You shouldn't have to write type=button command commandfor where it should be implicit by command. Command should mean command, command+submit should be a noop, submit should be submit.
Luke: not sure command+submit should be submit. We can change this for command, even if we don't change it for popovertarget.
Noam: we're adding a new feature here, I don't think we need to worry about invalid types etc.
Simon: I don't like the noop thing for any case. It's a surprising behavior. It's surprising that a button that has two commands does nothing. We should clarify who wins. Same about reset.
SImon: the type attribute can be useful for fallback in current browsers. My preference would be to let the command attribute win, and let type be a callback. Also OK with letting type win
Luke: my preference would be "type wins" because of unexpected behavior. People would have a polyfill until browsers that care about it have it work.