Upcoming WHATNOT meeting on 2024-07-11

[annevk]

Yesterday we held our weekly WHATNOT meeting and #10441 contains the details of that including minutes. The next one is scheduled for July 11 at a time reasonable for Europe and Asia-Pacific (or so we hope).

People interested in attending the next call please respond here or reach out privately to @past, @cwilso, or the spec editors. We will be tagging issues for the next call again using the agenda+ label in all WHATWG repos and we would like to invite anyone that can contribute to said issues to join us.

[past]

Thank you all for attending the meeting today and special thanks to Domenic Denicola for copiously taking meeting notes! Here are the notes from this meeting (the next one is at #10471):

Agenda

Attendees: Keith Cirkel, Kagami Rosylight, Freddy Braun, Domenic Denicola, Anne van Kesteren, Panos Astithas, Michael Smith, Daniel Vogelheim
Scribe: Domenic Denicola

1. Review past action items
   1. None
2. Carryovers from last time
   1. None.
3. New topics
   1. [Anne] Enhance <input type=color> with alpha and colorspace=display-p3
      1. Domenic will ping Mason/Joey for implementation interest from Chromium. Kagami will ask Emilio/Olli to chime in.
   2. [Keith] Tie in AbortControllers with CustomElements
      1. The discussion will continue on the issue. Keith will summarize the proposed options and tradeoffs.
   3. [Daniel/Freddy] Upstreaming from the Sanitizer API
      1. Consensus in the room that this is ready for stage 2.

Action Items

1. @domenic will ping @mfreed7 / @josepharhar for implementation interest from Chromium on Enhance <input type=color> with alpha and colorspace=display-p3. @saschanaz will ask @emilio / @smaug---- to chime in.
2. @keithamus will summarize the options and tradeoffs on Tie in AbortControllers with CustomElements.

Minutes

Topic: input type color extensions

Anne: #10456. Most OSes already support expanded color pickers. Also changes the underlying data model from HTML's "simple colors" to CSS colors. There's been some on-issue feedback on how to serialize sRGB with alpha, we should use rgba(x, y, z, w) so that it's the same as canvas (instead of the modern CSS serialization). Looking for review and implementer interest.

Panos: is this related to recent CSSWG discussions around color gamut mapping algorithm?

Anne: not aware of that discussion so probably not. This would support out-of-gamut colors in theory, like CSS does. For limited-SRGB mode we have to round down to stay compatible with what's available today. We could in the future allow non-limited SRGB mode that allows out-of-gamut values, but I didn't want to add that in v1 since nobody seems to implement that. (Nobody seems to want to make colors take more than 32 bits.)

Domenic: there is a consistency vs. goodness tradeoff here. Continue using old canvas serialization (consistency), vs. new CSS serialization (goodness). I don't feel strongly just wanted to raise the possibility.

Anne: Don't feel strongly, maybe leave a comment if you want that way.

Domenic: will leave a comment. And try to summon appropriate Chrome folks for implementer interest.

Anne: There is some weirdness in CSS that we'd want to explore around preserving input formats and color spaces…

Topic: tie in AbortControllers with custom elements

Keith: pitches whatwg/dom#1296 . This is a common pattern, we'd like to have the browser do it for us. Olli suggested this should go beyond custom elements. One sticky point of that proposal is that it doesn't make a lot of sense to use AbortSignal for connected reaction.

Domenic: I liked your original proposal. Not entirely sure the direction Olli took it in. If we just want events, you could use mutation events/observers. You tried to solve an ergonomic problem and for that having a disconnect signal makes sense.

Keith: I think the placement on Node is reasonable. I can see how it can be useful for generic nodes to know when they are disconnected.

Domenic: That makes sense, but I don't think it generalizes to all types of mutations. Disconnect only, since disconnect is about teardown and aborting.

Keith/Domenic: Exact details TBD. Method vs. property.

Anne: you have to be careful about when you grab the signal

Keith: I like the method approach.

Domenic: let's write down this approaches and discuss tradeoffs in the issue. E.g. should you be able to get the signal before connection, or should that be null.

Keith: Also some discussion in the web components CG about debouncing the signal. Seems like it'd be somewhat magical and complicated. Probably there are alternate approaches.

Domenic: agree, sounds complicated.

Anne: this discussion makes me think maybe we should explore more as a JS library?

Domenic: what is the timing? Especially if we're on Node.prototype, then this probably means using the CEReactions timing, despite it not being custom elements?

Keith: to the point about exploration as a JS library, it's pretty common already in custom element base classes.

Anne: if there are pointers to existing libraries, that's very helpful and we should use them as precedent. (whether or not it's part of a framework, it's fine)

Domenic: we should look into and understand what decisions these libraries make

Keith: our decision at GitHub was to only create the signal in connectedCallback, and lint against usage elsewhere. I'll talk to other library authors to see if they made a conscious decision there.

Topic: upstreaming the sanitizer API

Daniel: introduces #7197 . I learned about the stages process! We're not stage 3, there are still disagreements. But I think we're stage 2.

Freddy: I'm here to say +1, Mozilla's on board.

Anne: WebKit is on board, stage 2 makes sense.

Panos: OK, let's make it stage 2!!

Domenic: congrats! How can we help you during stage 2?

Daniel: Once we're in stage 3, there will be questions about how to actually upstream. But still working on some things.

Freddy: e.g. API usability tweaks. But, summer and holidays will delay that for a bit. Probably mid-August.

Panos: one thing that makes sense to me is to use this meeting to check in on proposals that are in the later stages. What do people think?

Anne: sounds good, and maybe we should have a document listing them all?

Domenic: An automated generator based on labels, or just use GitHub itself, would be good. I don't want to maintain that.

Anne: yeah maybe we'll make a generator.

Domenic: pre-warning that converting from Bikeshed to HTML source is kind of a pain; sorry about that. Some people have a good amount of experience with it and maybe you can enlist them.