Upcoming WHATNOT meeting on 2025-02-27

[past]

What is the issue with the HTML Standard?

Today we held our weekly triage call (#11026) and I will post the meeting notes there in a bit. The next one is scheduled for February 27, 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.

[ADKaster]

Can we discuss #10296 at the next meeting?

A ladybird contributor has created a WPT for the specified margin collapsing rules: web-platform-tests/wpt#48138, and an implementation for Ladybird based on the spec'd rules: LadybirdBrowser/ladybird#3621

• Should we proceed with the specified rules in our implementation?
• What do implementers other than Blink think about the specified rules?
  • Blink developer in the issue suggests removing the rules altogether

Please also send an invite to our contributor, https://github.com/Psychpsyo

edit: contributor has been invited to the meeting properly now

[past]

Of course, I just added the agenda+ label to it. I would need the contributor's email to add them to the calendar invite, but you can also add them yourself.

[eqrion]

@past I'd like to attend for the discussion of #11031. Could I get an invite? It's ryan '@' mozilla.com.

[past]

Sure thing, I added you to the invite.

[past]

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

Agenda

Attendees: Luke Warlow, Psychpsyo, Michael Smith, Joey Arhar, Panos Astithas, Guy Bedford, Stephen Cheney, Keith Cirkel, Mason Freed, Rakesh Goulikar, Ryan Hunt, Ian Kilpatrick, Noam Rosenthal, Kagami Rosylight, Yulia Startsev, Benjamin VanderSloot, Anne van Kesteren, Chris Wilson
Scribe: CWilso

1. Review past action items
   1. Noam to convey generally positive feedback and minor points of concerns about sheet attribute to the issue.
      1. Done.
2. Carryovers from last time
   1. [Mason] The interactivity property (spec PR is editor approved and just needs implementer support)
      1. No opposition to this, but we'll discuss it in the joint task force meeting with the CSSWG to understand how likely the CSS draft is to change.
3. New topics
   1. [Ian] Slowly removing/reducing the margin collapsing quirk
      1. General consensus is that this sounds like a good direction, but we will discuss it again next week at the joint meeting with CSSWG so the right people can be in the room.
   2. [Guy] WebAssembly JS String Builtins & the ESM Integration
      1. More discussion will continue on the issue.
   3. [Luke] Add request-close command for dialogs (needs implementor support)
      1. Luke will file standards positions and Ben will ping Olli.
   4. [Domenic] CanvasRenderingContext2D: Add getImageDataAsync method
      1. Carryover.
   5. [Anne] Web Compatibility of Scoped Custom Element Registries
      1. Carryover.

Action Items

1. @lukewarlow will file standards positions and @bvandersloot-mozilla will ping @smaug---- on add request-close command for dialogs.

Minutes

Panos: Past action items, Noam to convey feedback on sheet attribute. Done. Carryover, interactivity property?
Mason: one comment from Emilio, just looking for implementer support. Half of this lives in CSS, a property called interactivity. CSS way to control inertness. Both CSS and HTML get to control this (e.g. modal dialogs) Inertness cannot be overridden by the CSS version; current implementations can be. The PR I link to is the HJTML side, CSS side has already landed in drafts in CSS side.
Ben: I can ping
Mason: I'm not sure this needs an AAM spec change but I'm looking into it.
Panos: is Webkit interested in this?
Anne: Potentially? Not clear what stage this is in the CSS WG. I don't think this should land here before it lands in CSS. CSS specs have been known to change at various points in time up until CR. And we'd be introducing a dependency on the CSS spec. The CSS spec needs to change to a point where we know it won't change anymore.
Mason: What point is that, for you?
Anne: I guess once they've published CR.
Mason: Why do we always link to the drafts then?
Anne: fair question. I don't have a good answer for that. The drafts don't mess around with established features, but they might catch them up? (with fixes that aren't in the CR version)
Mason: I don't think we want to chain everything to having everything in CR
Panos: this sounds like a good topic for the joint OpenUI TF
Mason: yes
Noam: we have a lot of precedence for this in the HTML spec. The entire spec might be a lower maturity level, but the feature is pretty stable.
PAnos: I'm hearing we don't necessarily have support from Webkit but don't have opposition either; will put it on the agenda for next week. Moving on to new topics: removing margin collapsing
IanK: probably not removing but reducing and making closer to reality. Quirk is when the parent is either the body or table cell. If an element with default margins like <P> gets to the top of the container it collapsed, but in the early 2000 this got implemented one way in webkit, similar in edge/mshtml, FF implemented in a substantially different way for all margins, not just collapsing. In about 2012/13, margin collapsing quirk got pulled into the HTML spec. Not a lot of layout experts, so it just specified what FF implements; unfortunately FF expanded to all margins, not just the table cell like one. Currently the quirk is on a whole bunch of elements like XMP that we likely don't need, so trying to reduce the incidence. We'll probably need to keep the quick, but specify it to just be on collapsing margins and not all margins. I'd previously talked to dholbert and emilio at FF, but not about the details yet.
Ryan: I'll ping
Cameron: makes sense to define in terms of margin collapsing rather than FF rules. Need to look at compat. Also mention: form element in some cases in IE gets an extra em of space at the end in some cases.
Ian: I've removed quite a few quirks; at worst, just a small shift down on the page. Even with a change that caused changes to a non-trivial amount of pages, zero bug reports.
Anne: I think this is fine but need someone like Tim to take a look. I think I already pinged him.
Ian: reduction in quirk in webkit will be very similar to blink.
Luke: At least it seems to make sense to me to spec Chrome/WebKit rather than Firefox behaviour, Even if it doesn't get reduced any further initially
Anne: shouldn't we maybe make a console message for quirks mode or something?
Ian: I think that would be more annoying. It would be good to get the FF people here to discuss interest in reducing the quirk. I'd really like it to be defined in terms of margin collapsing, not in terms of how FF currently implements it.
Anne: this does seem like a useful topic, but I think this should really go to the CSS WG. We can then take their recommendation.
Ian: CSS doesn't have a great definition of how margin collapsing works.
Panos: seems like another good topic to discuss in the joint meeting with the TF next week?
Ian: Yes.
Ben: from Emilio: removing the quirk shouldn't be too hard, and speccing it to how blink/webkit works
Cameron: the FF way of doing it is web-incompatible on quite a few pages I found.
Ian: Your intent for ladybird is to implement it the webkit/blink way?
Cameron: Yes.
Panos: seems like general consensus is this is the right direction, discuss next week. On to Wasm JS string builtins.
Guy: This is a proposal Ryan previously worked on.
Ryan: With wasm we have an issue where people want to write wasm code and access certain JS primitives like strings but wasm doesn't have concepts like JS strings in it. It's a lot of overhead to call into JS to do things like string type access. I champion a proposal called JS strings builtins. Uses Wasm import mechanism, interacts with the rest of the web platform.
Guy: has implications with behavior of wasm string builtins as a compile time import. Wasm.modules doesn't import them. Since this builds on top of the existing wasm import string func, it reserves certain sets of specifiers.
Ryan: what browsers have shipped today is using the JS API.
Guy: very subtle semantic distinction here module specifiers are not URLS.
Anne: You can say that in theory, but if it's not resolved at the first layer it's not resolved as an URL.
Guy: same as if you try to import a node.js file into a browser today you get an error. Import maps can map these things in the fallback path.
Luke: Node using node: and that being a URL would follow the same problematic behavior that Anne mentioned. Node modules are not running in the browser, so that's their problem. But if we are having these in the browser the scheme feels weird.
Anne: presumably no one would use HTTP: at the start of their modules just because they could.
Guy: under the framing of reserving a WASM scheme, what do we need to do? Register with IANA?
Anne: yes, at a minimum, to prevent reuse. If you used something that did not resolve as a URL, you would not have this problem, probably needs an RFC? Revisits the built-in modules debate we had in TC39, but it is a little bit different.
Yulia: Where are we with built in modules? Is this still completely ruled out as a bad idea, or has there been any movement?
Anne: no movement I'm aware of.
Yulia: still interested in "known libraries" that are blessed. Definitely not a given, but being explored.
Ryan: if we went with a different syntax for module specifiers, is there any space that's not a scheme that we could use here?
Anne: depends on what the goals are; do you want it to parse as a URL, is it okay if it does, etc.
Ryan: these really can't be used by anything outside of wasm. We were trying to avoid some of the larger issues around modules.
Yulia: if we go in the direction of this quest of if we had built-in modules, maybe this can be treated separately as a specialized case, but we should explore further.
Panos: let's put a pin in this discussion here. Not a full resolution, but enough for Ryan to follow up on.
Luke: I'm looking for implementer support on request-close for dialogs. Would be nice if we could ship in chromium alongside ??. Ollie was somewhat supportive last week but had some concerns about events.
Luke: I can file standards-position requests if needed.
Anne: That might make it easier, yes.