Upcoming WHATNOT meeting on 2024-10-17

[past]

What is the issue with the HTML Standard?

Today we held our weekly triage call (#10666) and I will post the meeting notes there in a bit. The next one is scheduled for October 17, 4pm PDT. Note that this is 1 week later in an Americas+APAC friendly time.

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]

Hi @whatwg/triage, there are no agenda items for tomorrow. I will cancel this instance unless new proposals come up in the next 24 hours.

[KurtCattiSchmidt]

I would like to discuss #10673

Also, please send me a meeting invite.

[alisonmaher]

I would be interested in joining the call this week, as well

[past]

I added you both.

[dandclark]

Can you please add me as well? I'm on the Thursday 9am PDT calls but not the 4pm one.

[past]

Can you please add me as well? I'm on the Thursday 9am PDT calls but not the 4pm one.

You were actually in the invite, but I removed and readded you to send a new notification.

[past]

Thank you all for attending the meeting yesterday! Here are the notes from this meeting (the next one is at #10709):

Agenda

Attendees: Michael Smith, Joey Arhar, Kurt Catti-Schmidt, Dan Clark, Sanket Joshi, Alex Keng, Alison Maher, Tien Mai, Olli Pettay, Ajay Rahatekar, Ana Sollano Kim, Anne van Kesteren, Chris Wilson
Scribe:

1. Review past action items
   1. Joey to respond to concerns on the select cloning/timing issue
      1. Done.
   2. Anne and Dom to review select PRs
      1. carryover
   3. Khushal will incorporate the feedback to the Canvas Place Element explainer.
      1. carryover
   4. Dom will follow up with Noam and loop in ARIA folks on Atomic move operation for element reparenting & reordering.
      1. carryover
2. Carryovers from last time
   1. Simon will take a look at content model and 'what' to render for stylable <select> elements.
      1. [smaug] pinged zcorpan
      2. carryover
   2. [Emilio] [images] Lazy loading and out of band loads
      1. Someone from the Chromium side needs to take a look. Joey to ping chat.
3. New topics
   1. [Kurt] Declarative CSS Modules and Declarative Shadow DOM adoptedstylesheets attribute
      1. Consensus to move to stage 1; Kurt to start working on filing issues and drafting incubation.
   2. [Dan] Reference Target
      1. Consensus to move to stage 1, for phase 1 and phase 2; phase 1 might be nearing stage 2, but concern that some amount of phase 2 needs to be understood first.

Action Items

1. @josepharhar to ping Chromium folks for [images] Lazy loading and out of band loads

Minutes

select cloning timing issue:
chris: Is this done?
joey: yes

select element PRs:
anne: i haven't had a chance to look at those yet

canvas place element:
olli: those were updated 3 weeks ago

atomic move operation:
chris: not seeing anything happening on this one

content model for select:
joey: feedback would be appreciated
chris: So, carry over?
joey: yes

lazy loading:
olli: if someone from the chromium side could take a look that would be good
joey: i'll post in a chat about it

css modules declarative shadowdom:
kurt: i'd like to get stage 1 for this
anne: given what was presented at TPAC, stage 1 sounds reasonable. additional work needed.
kurt: yeah start speccing and prototyping and filing issues was next. i think that it seems like that's the kind of stuff once you're in between stage 1 and 2. Is it reasonable to start drafting PRs for spec updates?
anne: it's always reasonable to create a PR. I'm not sure we have complete agreement on the shape of the api. you might want to do that first before you invest the work in a spec PR. but maybe it's easier for you to do the spec PR first. depends on your mode of operation.
kurt: So should I file bugs and resolve them there?
chris: i think what anne is getting at is that you don't want to spend your time on precise spec updates when you're still trying to map out the shape of the api. if that's the most comfortable way to work on it then that might be valid. given the support of investigating the problem at least in the issue, stage 1 is appropriate. that's not a commitment to do anything beyond that
anne: The way you go about it is up to you. you can try to make issues and get sufficient buy in. or you can write a spec pr and hope that people review that.
olli: it might be slower to get reviews for prs.
kurt: I have a list of stuff, I'll file the issues. Once those get some traction, I can start on spec prs or in parallel and then we can update based on resolutions. I have some on the top of my head and I can raise those. then ill start filing issues and drafting a spec in parallel.
dan: Right now we've got some issues open in the ms edge explainers repo. I'm wondering if it makes sense to open a separate issue in the whatwg/html issue tracker. would it make sense for us to open 7 issues for the open discussions?
anne: We need at least one issue in whatwg/html and it's fine to open more if you want to keep all the discussion there. the other thing is that you could have one issue in whatwg/html and keep the others in ms edge explainers…
olli: this is all in the early stages. it might change quite a bit. The proposal might need to change quite a bit. it doesn't matter too much where this discussion happens.
chris: if it's easier to keep it in edge explainers that's fine. if you want to move it and create a PR, that's fine too.
sanket: its easiest to track it in whatwg/html so we can agenda+
kurt: And then I just link to the specific issue?
chris: its valid to do that for a while
anne: it's not formalized, so it's what works best for you.
chris: i marked it as stage 1

referenceTarget:
dan: reference target has been discussed in several venues but hasn't been raised here. I think we got positive reception at TPAC, and it has been prototyped in chromium. i'd also like to ask for a stage 1 label here. the questions I wanted to ask were already answered with the last one.
olli: at TPAC we were focusing on phase 1, so that one got most of the feedback. This is unusual because we have this phase 1 and phase 2.
dan: Did I say phase 1?
anne: i didn't know there's multiple phases
dan: we're talking about stages of whatwg and phases of referencetarget. phase 1 is referenceTarget alone that forwards all properties, phase 2 is referenceTargetMap where you can retarget specific properties. maybe some more questions about referenceTargetMap, whether we want microsyntax. if we can split these and say that referenceTarget is stage 1.
anne: from our perspective, both of those can be stage 1. i have one question about - did we agree on solving the label element case based on the discussion at the igalia hackfest? or is that an open issue?
dan: there was agreement on that yeah, there was an issue and a merge into the explainer
anne: in the label element description, look up my target element and use this thing in a way. sounds good.
chris: Anyone opposed to stage 1?
sanket: ???
chris: i think sanket is saying that we're thinking of both of these as stage 1
olli: i guess that's fine, even though referenceTargetMap might need some changes. The concept is probably fine.
chris: stage 1 only says that we have consensus that this is a problem that's worth looking at and trying to solve and in scope of the spec, but not committing that we are going to solve the problem. no hard commitment or that this is the right api.
olli: yeah i think that's fine
chris: i'll just go ahead and mark that
sanket: ???
sanket: now that we resolved for stage 1, for stage 2, one of the things was consensus on the rough api shape. Do we have consensus on the rough api shape? the single identifier and that all the ids will forward over to that element. Do we have consensus on that part?
anne: I think so. i don't want to speak for anyone else, but from our perspective for that one you could start writing the pr and might be big and spread across multiple specs.
olli: but we need to understand the referenceTargetMap better before we start writing referenceTarget spec. just to avoid any inconsistencies later.
sanket: were there any specific inconsistencies that you're worried about?
anne: emilio did spend a bunch of time at igalia hackfest in 2023
olli: the whole concept has been discussed for years
anne: honing in on the map thing
dan: The open issues about the map are about how you express the behavior. one thing with microsyntax or across a bunch of attributes. doesn't really change how it interacts with referenceTarget. referenceTargetMap overrides anything, other stuff falls back to referenceTarget. as part of asking for stage 2 we will at least have the reference target spec drafted.
anne: when you want to handle the multiple of one kind going in and end up targeting different things. I'm not sure where we landed on that. if a custom element has two labels for instance, and each label has to go to another thing in a subtree. I'm not sure if that's a case that has to be solved. That might also be something we want to do which might impact this thing. if you want to target a particular named thing. Does that make sense?
dan: i don't know if i follow, i might need a code sample.
anne: so if you have all these relationships, described relation etc. what if the custom element needs to broker two relations of the same kind? so the custom element has two labels, and then inside of it it has two controls. one label needs to go to one control and the other label needs to go to another one. maybe that's just not a case we want to solve.
dan: That kind of thing has not been a goal.
anne: initially we had a thing for that, additional syntax where you could target a specific part of the custom element. I would be ok with not doing that at all i guess. i'm just… it was one of the use cases that was originally presented.
dan: if there's a compelling use case for that, but we have not looked at that as a goal. for each attribute type, the custom element can forward that to some element and that's it.
anne: and this has been under discussion in the accessibility group for a while? they would have given feedback if that was important.
dan: yeah that aom group is where a lot of this happened. when they handed it off to the wc working group ??? the accessibility folks have been all over it
anne: Still involved?
dan: aaron leventhal and alice boxhall are yes
anne: in that case i'm not sure i see a big conflict. you would end up overriding individual relationships. although maybe having separate attributes for each relationship is clearer. it would give an easier api at least, we wouldn't have to invent a new api.
dan: I'm kind of undecided on that myself.
sanket: ???
sanket: the thing that would be good to get to in chromium impl as well is if we can figure out an incremental path between stage 1 and 2. If you think that issue should be talked about first, phase 1 is probably closer to stage 2 than phase 2.
sanket: as proposed, there's referenceTarget and referenceTargetMap ideally we would like referenceTarget to stage 2 and done sooner than referenceTargetMap. Do you feel like there is anything we need to agree on besides the initial proposal for referenceTarget to reach stage 2? or is it that we need to write a draft spec?
anne: ollli's argument that we should understand referenceTargetMap. I think the amount of work is identifying all the places you need to patch. If you do that, then doing these together as a single thing is not much more work than doing a single one of them, unless there's something I'm not seeing. The work is just enumerating the places you need to patch. then you have some branching on that. I would tend to say just solve them together and bypass the problem of how to divide the work.
dan: The concern maybe is that we don't want to get too hung up on … if there's bikeshedding around referenceTargetMap we don't want to delay shipping referenceTarget which has value for partners. We want to get a spec out and have developers play with referenceTarget.
anne: the simplest api is just doing a bunch of properties, and that's what i would advocate for. but the other thing is that you can say at a high level what the referenceTargetMap is. If we know what is going to do even though we don't know the api shape that's fine.
dan: I'd say our current explainer does that. it has referenceTargetMap on top of referenceTarget.
anne: Is this in a different repo? this explainer?
dan: It's on the whatwg agenda. at the end of the issue I opened.

selected option cloning:

• cloning at select end tag doesn't sound good
• cloning at option end tag parsing is more acceptable
• </select> tag is a long way away, you don't need all the options to display something. option is the smallest possible unit that can work, including its end tag.
• could require selected tag in option after parsing selectedoption, or we could just eagerly clone the first option when its end tag comes, then clone again if we see another one with selected attribute
• dom diffing concept is not ideal