Upcoming WHATNOT meeting on 2024-11-14

[past]

What is the issue with the HTML Standard?

Today we held our weekly triage call (#10734) and I will post the meeting notes there in a bit. The next one is scheduled for November 14, 3pm PST. 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]

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

Agenda

Attendees: Joey Arhar, Chris Harrelson, Alex N. Jose, Panos Astithas, Domenic Denicola, Di Zhang, Mu-An Chiou, Mason Freed
Scribe: Joey Arhar

1. Review past action items
   1. Anne will take a closer look at the Customizable <select> element PR.
      1. Anne took a look.
      2. [smaug] Event handling will likely lead to some more PRs.
      3. Panos will file a meta issue to clarify what stage 3 means. Domenic will add some examples of how he imagines this should work.
   2. Olli and Anne will review Alex's latest comment in Add expect-no-linked-resources Document-Policy to Speculative parsing.
      1. Carry over.
2. Carryovers from last time
   1. [Dom/Noam]: Proposal to move atomic move to stage 3
      1. [smaug] There has been some reviewing, and I think it isn't quite ready for stage 3, just given the nature of issues found while reviewing.
      2. [Dom]: Issues around ranges are trivial to fix (treating them like ordinary removal). Would like to know if people have other issues in mind
3. New topics
   1. [Di/Anne] Discussing how to focus navigate absolute position elements that are focusable in CSS reading-flow
      1. Di will add a comment with the current consensus.
   2. [Noam] Deferring (same-origin) navigation commit
      1. Domenic will add some thoughts to the issue.
   3. [Joey] How to spec user interaction for select
      1. <...discussion of various options...>

Action Items

1. @past will file a meta issue to clarify what stage 3 means. @domenic will add some examples of how he imagines this should work.
2. @dizhang168 will add a comment with the current consensus to Discussing how to focus navigate absolute position elements that are focusable in CSS reading-flow.
3. @domenic will add some thoughts to Deferring (same-origin) navigation commit.

Minutes

topic: anne will take a look at select
panos: Anne was supposed to take a look. There were a number of PRs. joey do you know if that happened?
joey: yes he looked at them
panos: ok
domenic: so what does stage 3 mean? I can give some clarification on that. Olli is saying that event handling is blocking stage 3, I can give some clarification on that. In the tc39 process that this is based on, stage 3 means that we've done as much review as we possibly can and the only way that we can find something missing now is by implementing and saying that there's no spec for this part of the code I'm writing. its fair that when an implementor says that by inspection "event handling what are we going to do about that" because we don't know what code we would write. similarly for atomic move, i don't know the details there, but there's some issues about ranges. if there's a question about i don't know what code i would write, its in theory a stage 3 blocker. stage 3 in tc39, they have a process that's less functional where they write spec then tests then implement. you should be able to write tests in stage 3 just by writing the spec. We do it differently by writing tests while implementing, but that's the level of detail expected by stage 3. stage 3 to stage 4 is pretty trivial. stage 3 is at least in tc39 which is what we were going for is the big hard one to get to.
chris: I think that makes sense and is fine. The discussion about stage 3 has been useful to the feature. it might have prompted olli to think harder about the event handling and stuff. always good to know what the concerns are.
domenic: i agree, the fact that you're pushing and they say what about this means that its working.
panos: i will say that i am one of those people who was surprised and thought that stage 3 would be short. I was thinking about changing the language. i am fine with either direction, that we are moving to tc39 as close as we can and that stage 3 is going to be short, or that we are departing from that which is was i thought and that stage 3 would have a lot of back and forth and substantial updates. Either way we should clarify in the stages doc what we're doing here so there's no more confusion. Anne said that we should have a discussion in the last meeting we had on matrix. Next week we should touch on that briefly.
mason: we should have some examples. I understand what you said but it's nuanced. the issues in stage 2 vs in stage 3. In both cases you found a problem. if you could make some examples, these are the kind of issues you find in stage 3 vs these are the issues in stage 2.
domenic: lets file some action items for me to find examples and of panos to update the stages.
chris: Once you get to 2, you're sure that you're solving a problem everyone thinks is worth solving and that in general your approach is sound. 3 is there's nothing but details left and it's definitely going to land once those details are done.
domenic: i agree with that
chris: when the stages were designed there was a discussion like do we need 4 or is 3 ok? I think that distinctions like this as well as aligning with tc39 were reasons to have 4 stages. Anyway, that's a distinction I can think of that's at least useful.
domenic: yeah i agree and what is the entering the stage signal. we would like to think that everyone is committed to customizable select, even if we haven't reached the level of specification detail that stage 3 says.
panos: people who monitor whatwg development would start paying attention during stage 3. maybe we should ask them to pay attention at stage 4 to start creating training material or blogging.
domenic: they should definitely pay attention at stage 3, it's so close to landing. Maybe they should pay attention earlier? at 2, that's the point at which we're going to do something. for customizable select we've already seen a lot of material produced, and that material has to change because we keep changing the names. for the bleeding edge of people asking what's coming, stage 2 is where to do that.
panos: ok. Any other thoughts on stage 3 definition?
chris: mason you dont know of any reason to think that delaying stage 3 would somehow have a downside in terms of outcome right?
mason: at all or for select?
chris: at all i guess or specific reasons for a feature.
mason: we have to get to the end where all the issues are resolved. As domenic said, the process is working because we are getting people's attention. it wont delay us to stay in stage 2 and talk about the issues.

topic: action item for alex's issue
panos: i don't think we have seen the actions. the expectation was that anne and olli – domenic left a useful comment – should we carry it over?
alex: the idea that taking hints from the page of the dev is not necessarily a bad thing or a new thing. in my mind it's pretty close to link preload for example, which is also a hint from the page that this is higher priority resources. This is very analogous to that. basically being a hint it can be chosen to ignore it. The second point is about priority of constituencies, about putting the user first. it's not contradicting that. The downside is that if you don't take that hint and action on it then it's not putting the user first because we're going to run more and not provide the best experience possible. the ua is actually optimizing for user experience. I don't know if we have enough people in quorum to talk about that.
panos: hopefully next week olli and anne are here.
chris: domenic do you have any feedback?
domenic: i added some in the issue. on the technical points. In general these document policy features are a weird place on the web. I would prefer a mode where we were more liberal in adding them. if another engine does not implement them it doesn't hurt anything. Olli's point was that it adds complexity to the web platform. I tried to ask him if it's an objection or thought.
panos: given what i saw in the webperf discussion, what points the mozilla folks made there, not super clear what their stance will be
alex: I thought their stance was positive at the web perf group. This was a very direct header to control the header. if we specify this as a document policy as a hint - those were the two changes we made. that comes from the forum and mozilla and apple were there.
panos: i'll carry that over to next week

topic: spam stage 3
panos: anything else people want to mention on this one? if not i'll let the discussion continue next week

topic: focus navigate absolute position elements
di: this is for the reading flow algorithm. I have updated the spec pr for reading flow. This step is kind of explaining there. we are defining a reading flow container in css, and it is user effect so im continuing with having reading flow property set. given that we are able to get the layout information about the in flow children. elements that have position absolute are fixed, are not in flow with those containers and do not have an order that we can base ourselves on . The preferred solution that i've implemented uses the information that we have and will visit them in dom order. if you have position absolute it will be visited after reading flow items. I think that's the easiest implementation and i havent had any pushback, but we are keeping the issue open in case.
panos: it sounds like you need implementor opinions? Is domenic useful in this conversation?
di: of course, but i guess that it's more on the implementor or end user view, does it make sense to visit absolute positioned elements at the end
chris; from a user and dev point of view is there consensus that this is good? Is it just a question of impl difficulty?
di: we haven't received any strong opposition because it's kind of an edge case.
mason: super corner case
chris: In terms of the - do the people who participate in whatnot seem to agree that this is generally good and just confirming that it's easy to implement? or is there open disagreement about some aspect of it?
di: anne added the agenda+ for this week so i thought he would have opinions. at TPAC it was brought up and nobody gave negative feedback about the negative approach
chris: So the feedback was about other parts, not this part?
mason: anne put a comment about why he put this on the agenda, and he just said that it's still open so we should discuss it, but people seemed happy, so maybe we should say we discussed at TPAC and close the issue? i dont think youve heard any feedback that this is a bad way to do it.
chris: panos do you think we should leave a comment saying what we just said? has nobody raised previous concerns at TPAC or elsewhere?
panos: i wanted to capture that in the meeting notes but i suspect that anne might have more to say so i'm inclined to leave it open so he can chime in.
domenic: we should leave a comment on the issue saying this is our conclusion based on TPAC and so on, so that's what the PR is going to do.
chris: that might be the issue, then we can get that information to anne with a comment. close it at the next meeting if he doesn't raise a concern.
panos: i will wait for Di to add the comment and wait for anne to put the label back on.
panos: anything else before we move on?

topic: deferring commit
panos: is anyone familiar with this? Anne did have some concerns.
domenic: we had a discussion about this internally and what's the best place to put this? it's about the scope. same origin cross document and then anne said maybe it shouldn't be for back forward. that is the hard part, and while we are discussing it, should it be on page swap or navigation api or something like that. I think Noam's got it in hand, just giving some background.
panos: anything else for today?

<long discussion of options around "How to spec user interaction for select">