Upcoming WHATNOT meeting on 2024-11-7

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 https://github.com/whatwg/html/issues/10750):

Agenda

Attendees: Joey Arhar, Panos Astithas, David Baron, Keith Cirkel, Emilio Cobos Álvarez, Mason Freed, Chris Harrelson, Alex N. Jose, Olli Pettay, Noam Rosenthal, Kagami Rosylight, Benjamin VanderSloot, Anne van Kesteren, Yoav Weiss, Dominic Farolino, Di Zhang
Scribe: Joey Arhar, with Anne's help

Review past action items
1. Domenic will ping Dom Farolino in case he has context around [images] Lazy loading and out of band loads.
  1. Done. Adding more WPT tests will help.
  2. There are some already
Carryovers from last time
1. Anne will check with Ryosuke on his concern in Atomic move operation for element reparenting & reordering.
  1. The concern was not a strong one. Agreement from the group to not fire any other events after the move.
2. Khushal will incorporate the feedback to the Canvas Place Element explainer.
  1. No updates.
New topics
1. [Joey] Customizable <select> element
  1. Anne will take a closer look at the PR. We will reconsider the question of whether this is ready for stage 3 in 2 weeks.
2. [Alex] Add expect-no-linked-resources Document-Policy to Speculative parsing
  1. Olli and Anne will review Alex's latest comment and we'll discuss it again in the future.
3. [Dom/Noam]: Proposal to move atomic move to stage 3
  1. Carry over.

Action Items

@annevk will take a closer look at the Customizable <select> element PR.
@smaug---- and @annevk will review Alex's latest comment in Add expect-no-linked-resources Document-Policy to Speculative parsing.

Minutes

Topic: Lazy image loading compat issue

Domenic will ping Dom Farolino…
panos: the ping and the comment happened. anything else to mention there?
olli: we need to figure out what to do with that issue, or is there chromium bugs to fix? its a compat issue.
dom: are there tests written for that case?
olli: i dont know if there are wpts, i was hoping they would join this one. maybe not.
anne: writing wpts might help.
olli: it can be tricky because this is about caching.
anne: images are somewhat easily cached right? onload, second time you hit the cache.
dom: and no server requests. tests arent different from list of available images tests that are written. i can write the test but its not going to be for a bit.
olli: i can ask around.
panos: ill let you put it back in the agenda when theres more to discuss

Topic: moveBefore() and focus events

Anne will check with Ryosuke on his concern in …
panos: did that happen?
anne: ryosuke didn't feel strongly about that. it was just a thing he was thinking about that we might have to do, but not a comment that we have to do it. at least to me its ??? entirely unclear that we have to do that notification. for context, its about the - if you do a movebefore call, it moves an element that is focused, so then document.activeelement stays the same before and after. do you fire focus events? yes or no? and i tend to think not, and last meeting it was brought up, what about other state that may have changed? should we fire events for that? if we're going to fire events for that, that makes this operation more expensive than it was designed to be, but only if there's listeners.
panos: dom does this comment unblock you?
noam: we came up with a proposal for focus that would not mean firing a bunch of events. We already have the focus fixup in the rendering phase, so we proposed that if the focused event was moved, then at that time it would just fire a focus event without blur, as if the element was removed and reinserted, but only once per animation frame. However, it does add some complexity. I think we're fine with keeping it not fired and adding it later if we find that this is an issue. get community feedback.
anne: What was the other reason called? i can't find focus fixup
noam: update the rendering phase. it doesn't really matter, its the focusing steps. when we call the focusing steps on the document, if the focused element was moved, then we treat it as if its not the current focused element. in the focusing steps there's a thing that if the new focused element is the current focused element then we don't fire events. but if to say, it was moved, then treat it as if nothing is focused right now. it's not a big change in terms of spec, it aligns the focus event behavior with insertBefore, it works the same. It's also not a complicated state machine. not bombarding with events which we wanted to avoid. It's conceptually like an invalidation. it doesn't unfocus the element, but it does for the purpose of events.
anne: it might be reasonable but i wonder about is there other state that could have changed but doesn't actually change? like the mouse event thing that came up. The element is currently mouse hovered but it changed. Does that mean we need to fire mouse out?
noam: this can happen anyway with the moving thing. I think that focus is special in that way. when you remove and bring back an element, we don't keep its mouse hover state.
anne: but you move it, and you're still over it presumably, we would not fire new events maybe?
noam: yeah we won't fire new events
olli: browsers have different behavior there. if you remove elements, in gecko and blink you may get mouse move events but not in webkit. and then pointer events shouldn't ever fire extra events per current spec. although chromium folks might want to change that for the unspecified model. a bit unclear. but i think that's unrelated to any of this.
noam: if we wanted to fix that for mouse and pointer events, we could copy what we're doing for focus fixup. We also catch up with whatever state dom is in with the events.
olli: pointer events are clear. it's if the pointer has actually moved. mouse events are more ??? if your pointer is moved related to the target basically. that might be something to figure out there. not sure if we need to deal with that here.
panos: if we decoupled that, is there anything still open for debate?
noam: i think we're good to resolve for not firing the event or this invalidation thing. I think the invalidation thing would work better in terms of compat. for in page accessibility. add on kind of things with focus events. but also we can deal with it later and at least we have a model for it.
anne: Since I'm not really sure what the right thing is, I would prefer to do it later. maybe adding it is also dangerous but that's harder to see.
noam: i think adding it would be less dangerous because firing more focus events ??? focusing and unfocusing are things that the application should be able to handle it anyway.
panos: so we can resolve on that? no events fired? I'll capture that as the consensus of the group.

Topic: Khushal will incorporate the feedback to the Canvas Place Element explainer.

olli: it hasn't been updated. Should we remove it from the agenda?
noam: i think khushal was taken out of things so ill speak to him offline.
panos: what olli proposed makes sense, i won't carry it over.

Topic: Joey to ping Chromium folks for [images] Lazy loading and out of band loads

anne: its just topic 1a and 2c
emilio: i also commented on the issue

Topic: customizable <select> element

Joey: We have more discussion in Open UI about the behavior of the selectedoption element. There was also a discussion about renaming that element. The result is to no longer observe mutations. Instead we mutate during parsing or when the end user selects an option.

Joey: Jake found selectedoption a confusing name. Selectedoption can mean two things verbally which makes it kinda confusing. As such it was suggested to rename it to selectedcontent. I put both changes in the PR.

Olli: Potential for confusion with selection.

Mason: It captures that only the content of the option is cloned.

Joey: Anyone else has any blockers to bring up for Stage 3?
<long discussion on whether stage 3 is appropriate>
Agreement to reconsider the question of whether this is ready for stage 3 in 2 weeks after Anne has had a chance to take a closer look at the PR.

Topic: [Alex] Add expect-no-linked-resources Document-Policy to Speculative parsing

panos: tell us more why this is useful, interesting
alex: the spec that's linked is the second version of this. the first version ?? w3 perf wg in august. feedback that would be suited as a document policy. In terms of usability, it started getting ?? second draft. one would be long pages of long running html that doesn't have external dependencies. A good example would be a quarterly earnings report. or the html spec page would be an example of mostly text heavy. a page would be better off declaring the assets itself. normal link that would need to be preloaded. That's a niche really targeted use case, but it's substantial in its own that it would impact the web performance. those kinds of pages - if i leave the tech field, it would be a passenger declaring to the airline that its not going to check any suitcases. the airline can use that or not. it's a hint that the page is indicating that i'm not packing external resources you need to spend time on. you're free to do any resource planning. gecko doesn't have a separate resource scanning step and can choose to ignore it. User agents that are spending time preloading and parsing and blocking can choose to use that time doing other stuff. Last night I did some digging in terms of electing some benchmarks when I posted those as well. reading the complexity of the dom ?? for small underpowered computers can be substantial, it can make it very worthwhile to invest in. thats that the spec and pr is about.
olli: my issue is that this feels like a hint to overcome certain implementation details in blink because it happens to have that kind of speculative parsing. if we start adding these kind of hints then we just change the impl to do something else later. changing this preloading mechanism would be a better way.
alex: first version i proposed was not a hint, it was a page telling the ua don't preload scan me. but the webperf group said we don't want to have it - that binds the ua into a contract that it's difficult to ?? if they forget about this signal later they could shoot themselves in the foot. better as a hint so ua can improve later. about the preload scanner being ?? html document parsing, this predates me, but there was already an experiment in chromium of an integrated preload scanner but it didn't have the same performance characteristics. for the majority of the web it benefits from preload scanning. this is for a page that wants to be extra mindful of the performance and that the preload scanner is blocking. page can say that i dont have resources.
olli: It's a hint for a certain kind of implementation only. if we add this to the platform then people need to know about it and they have to be there forever, even though in this case gecko could ignore the hint altogether. if we add tons of hints that affect scheduling of animation frames during load because it happens to improve performance, but i don't think we should be doing that.
panos: we are at time. please read alex's long comment on the thread and then add your further message you have and then we can bring it up again in a few weeks.

whatwg / html