Upcoming WHATNOT meeting on 2025-01-30

[annevk]

What is the issue with the HTML Standard?

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

[cwilso]

Note the explicit request to raise awareness of the model element proposal in #10901.

[schenney-chromium]

@whatwg/canvas I would like to discuss the interop of text direction getter values and the proposal for a new lang text attribute at this meeting.

PR #10873
Issue #10884

[past]

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

Agenda

Attendees: Brandel Zachernuk, Chris Wilson, Panos Astithas, Ada Rose Cannon, Keith Cirkel, Mason Freed, Dominic Farolino, Stephen Chenney, Benjamin VanderSloot, Anne van Kesteren, Tantek Celik, Olli Pettay, Peter Van der Beken, Andrew Sutherland, Henri Sivonen, Simon Pieters, Luke Warlow, Piotr Bialecki, Rik Cabanier, Laszlo Gombos, Sanket Joshi, Andres Ricardo Perez, Daly Realism, Kagami Rosylight, Neil Trevett, Chris Harrelson, Joey Arhar
Scribe: Chris Wilson, Benjamin VanderSloot

1. Review past action items
   1. Noam to open an issue for the existing blocking styles interop issue
      1. Not done yet, Noam wants to create a test that presents the problem.
   2. Noam to create a WICG repo for dedicated discussion of the async CSS use cases and anti-use cases:
      1. Done. Add your feedback to the request if you support this incubation.
   3. Keith to sketch out a design for making child elements into posters
      1. Done.
   4. Keith to make a big table of loading vs. autoplay vs. preload as the next step for loading=lazy
      1. Didn't get to it yet.
2. Carryovers from last time
   1. [Dom]: Composed live ranges (+ selection PR)
      1. People are encouraged to review asynchronously.
   2. [Stephen]: Canvas TextStyles direction getter
      1. No objection to the proposal.
   3. [Anne] Add Last-Event-ID to CORS-safelisted request headers
      1. This was sufficiently discussed last week.
3. New topics
   1. [Brandel] Display of an inline 3D model
      1. People are encouraged to review asynchronously.
   2. [Stephen] Add a lang IDL Attribute to CanvasTextDrawingStyles, and clarify "direction" on same
      1. No objections to the proposal, more feedback is welcome.
   3. [Joey] Content model and 'what' to render for stylable <select> elements
      1. The discussion will continue on the issue.
   4. [Joey] How to spec user interaction for select
      1. Resolved offline.

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.

Minutes

Panos: blocking styles: not done yet. Async: seems done?
CW: If someone could +1 in the async css WICG proposal I could move it into the WICG.
Panos: child elements into posters?
Keith: I proposed 2 solutions, seem to be steering toward some kind of attribute on the video element to denote that - posterchild, posterimage, something like that. Let the bikeshedding commence.
Panos: big table of loading vs autoplay? Keith: didn't get to, carry over.
… carryovers: composed live ranges.
Dom: this has to do with the get composed ranges method we're working on to standardize in theselection api. We don't have to agree on algorithms, but wanted to know if we generally agree on the shape of the path. Sel API golds on to endpoints, so can never span shadow dom roots etc, and we're kind of changing how this selection works internally . New: composed selection range, new type of live range IDL object which is what would be used to return the range from that API. This model of composed selection range that represents the visual selection range on screen and the traditional live range inside it begs the question of how do e we keep the two synchronized. The composed selection range will fairly span the outside of the shadow dom, while the internal live range would be snapped to the inner shadow range. If you make changes to the internal live range the selection api manages to reflect those back to the composed range. The composed selection can span multiple shadow routes, but the the internal live range just behaves how it does today. We try to keep the two relatively synchronized.
Olli: can we used this to solve the issue of reordering elements visually when the slots are reordered visually?
Dom: worth a look
Mason: that is an issue but it spans the whole string, may not apply?
Dom: we're trying to introduct a new mechanical internal range w/ endpoints that can span shadow roots. But we need to define how changes to that influence the selection range.
Stephen Chenney: in reflecting composer range back to internal browser range, if you only change one endpoint, would it change the other end?
Dom: ideally not; I think we'd be open to either way. Any opinions?
Anne: I had some editorial concerns, mainly. Two weeks? Little busy at the moment. Generally sympathetic; I think I proposed something like this in 2018 or so but never got around to doing the work.
Panos: bring back in a couple of weeks. Canvas text styles?
Stephen: computed value should be inherited while Firefox returns the inherited string/ This would change blink and webkit use counters. Doesn't seem like it's important to rely on. Proposal is to standardize to return the actual value, even if that's ‘inherit'. [no complaints heard]
Shui: need to resolve the live dynamic. In terms of returning the value, on board.
Stephen: yes
Panos: last-event-id: was this closed last week?
Anne: yes
Panos: new topics:
Brandel: on behalf of webkit and immersive web community group. Demo. Problem with existing features: in the context of webpage rendered in VR, "head tracked stereoscopic", and how it interacts in the room. First discussion: is the element a good idea and how do we proceed? Questions?
Stephen: What does it look like in a flat screen browser?
Brandel: Could be exactly the same as the currently available above the platform models. Could use the webcam for lighting, head tracking. But the real benefit is in head-tracked stereoscopic.
Stephen: Standardizing content delivery is nice.
Brandel: A lot of people are just showing an object and loading a much heavier set of features
Chris: This is being incubated. It'll probably go on there since that is the community. Google thoughts: cautiously supportive, but with concerns. Format concerns are high, usability is a concern but not as high.
Brandel: Other editors in the room from Meta and Samsung.
Olli: Are you expected to be able to interact with these models?
Brandel: This is a representation of a given 3d model (static or animated). This is only to show it- no stateful manipulations. Sufficient utility without other manipulations. We support the play button and manipulate the view.
Ada: interaction mode. Pointer events, permitting custom defined pans and rotations rather than the default orbit.
Brandel: DOM matrix for CSS transforms is probably what we need for the "entity transform".
Panos: Implementer interest from WebKit. Feedback from HTML editors? Any blockers beyond multi-implementer interest
Dom: I'll have to take a closer look.
Panos: Please read and comment. We will bring it back. Lang IDL text styles?
Stephen: no way to localise the text in offscreen rendering. Soln is to add a lang attribute to the canvas text drawing styles. I Think Chromium is on board, Webkit tentatively. There's a PR up that implements it, so I'd like to ask for positions but also two questions: dynamic behavior that was raised earlier, and the second issue is if we solve that in a particular way should we call this value "initial" so we can go back and forth with initial behavior.
Andres: we're on board, but maybe making the initial route just a snapshot of what the initial value was. We like it being a context attribute.
Tantek: Does this mean canvas context could only have a single language of text?
Stephen: you can set the lang to a local before each string you render, so no, it's supported to have multiple languages in a single canvas context. But this is setting the initial default.
… any guidance (from mozilla in particular) on whether to call it initial or inherit?
Tantek: keep the same semantic name pairing as in CSS ‘initial' or ‘inherit' keywords? Not sure how that lands.
Stephen: It applies a bit differently.
Panos: sounds like no big objection. Will hash out in PR. Good to move forward.
Joey: content-model: Anne, did you see the alt-text-in-options comment?
Anne: no. I thought domenic's opinion was that it also shouldn't be included in option label
Simon: I think I agree with Dominic that its should only be included in the a11y model, not in label.
Joey: I think that means no changes?
Anne: I don't really like it; how is this comparable to text content? I think we're designing specific semantics for a specific element and how it behaves.
Simon: I can see with images it would be more content you're omitting.
Anne: if we don't add image support to the natic rendering, what's gonna be the rendering? The label or this new visual thing?
Joey: Do you also see the issue with exposing ALT text in this?
Anne: this is all opt-in, though. It's new behavior.
Panos: let's continue on Matrix or in the issue.