Upcoming WHATNOT meeting on 2025-04-17 #11192
Comments
|
Thank you all for attending the meeting today and a special thank you to Domenic for taking meeting notes! Here are the notes from this meeting (the next one is at #11233): AgendaAttendees: Luke Warlow, Keith Cirkel, Emilio Cobos Álvarez, Domenic Denicola, Olli Pettay, Noam Rosenthal, Kagami Rosylight, Anne van Kesteren
Action Items
MinutesPopover does not know what triggered it Luke: need to be careful about exposing things, e.g. cross-tree, because currently invokers are not exposed Support fragment references in the Noam: I feel like this space needs some incubation and holistic thinking. A joint CSS-WHATWG session (or more than one session) would be helpful. I'm happy to work with Microsoft on preparing that after I'm back from holiday in two weeks. I feel like as an issue it's too broad and is getting bogged. Domenic: I remember steering them in this direction, and suggesting a solution like this, so I feel bad that the issue ended up being very controversial… Noam: it's an intrinsically tough issue. Domenic: any feedback this room can give to the issue before such a joint meeting? Anne: feels like this is a piecemeal solution for declarative custom elements. If you use declarative shadow DOM this helps you deduplicate CSS, but not your actual DOM tree. Should we solve the larger problem? Luke: for what it's worth, I agree, reusable declarative shadow DOM is important and the current repetitive version is less useful. But there are probably use cases with shared stylesheets across multiple components, so CSS reuse without markup reuse has a use case. Keith: It's related to the bundling case for CSS. Noam: JS modules have the same problem, you can only reuse things that are external. Domenic: that was my original feedback, either solve this for all scripts (or at least module scripts), or do something CSS specific. Not their original solution of CSS module scripts only. Anne: scripts being special has always been dissatisfying… Domenic: it seems like you can either do web bundles, which we seem to be failing to do, or everyone can do bespoke per-type things, like TC39 is doing for modules and CSS content-visibility content relevancy section should be in the HTML spec Domenic: I agree we should move monkeypatches into the main spec! No opinion on the actual fix. Olli: asking for feedback from browser vendors on the correct fix. Noam: I'll ping Vlad/find the right people Anne: generally not clear on the principle for coalescing for loops over documents Noam: I think that's mostly about the focus fixup? Anne: probably applies to both Noam: I think the difference is about whether iframes affect their parents. Anne: Also note that it can only be observable for same-origin documents. Noam: the event loop processing algorithm is already scoped to one agent, so that's taken care of. Emilio: (has just joined) it makes more sense to me to incorporate focus fixup into the loop. It felt odd to do a whole document walk again for the same sort of "run script and layout" loop that ResizeObservers do. Noam: in Blink we try to put the least possible amount of things inside that loop, since it's potentially infinite and capped with resize observer depth. Emilio: We could put it right outside the loop but the same step. Noam: feels cleaner to do phase-by-phase instead of document-by-document. Matches other steps. Emilio: feels naturally part of this loop to me, but I don't feel super strongly. Noam: I think part of the loop strategy could be buggy with two frames changing display: none… (didn't catch the whole details) Emilio: the same issue can occur with the phase-by-phase strategy Noam: a bit more constrained by just having the blur event Emilio: To me, arbitrary script is arbitrary script. But I don't feel super strongly. Domenic: back to content-visibility specifically? Emilio: that one seems more clearly like it should be part of the loop, the loop already deals with content-visibility. Once at the beginning of the loop. (Or in a step right before the loop.) On the other hand maybe it doesn't matter since it doesn't run script. After the loop doesn't make sense: that would change the layout that ResizeObservers have observed. Not sure how I feel about inside the loop. Anne: Do we have tests? Emilio: no, but I can write some! I'd be curious what browsers do; there are some existing differences around content-visibility. Anne: if we can get some perf with better iteration strategy that'd be good. Emilio: there usually aren't that many documents in an agent so it's not so bad. Domenic: number of operations are the same with any iteration strategy, right? Anne/Emilio: layout-updating disrupts that, which is why we try to keep stuff in that inner loop step. Noam: would the content visibility thing fire contentvisibilitychange? Emilio: no, they get posted as a task. Noam: I wonder if we could do a similar thing with blur events… Domenic: probably we could? We already moved from sync blur events to update the rendering timing. One extra task on top of a potential 16 ms delay is probably fine. Noam: after user-visible rendering updates is riskier Domenic: conclusion for content-visibility: Emilio will write the PR to put it before the loop. And tests. … trying to conclude on focus fixup … Emilio: I have a slight preference to do it after the inner loop is over Noam: I feel like patching things is not ideal unless we go all the way, it's simpler to just say if you do weird things in the blur event then your site might get confused. Going all the way to putting it inside the inner loop might work, but not sure we have enough motivation to do that. Emilio: even with that case another document can mess with your state. Noam: we'd do like resize observers, continually checking until it's settled… Emilio: doesn't work, the loop is per-document. Emilio: So my suggestion is to move it up to keep all the layout updates in one step. It won't ensure that web developer code always sees up-to-date state. I'm willing to try putting it in the loop if you think it's better, but I'm not convinced it helps that much. Noam: Let me discuss internally. Dialog requestClose causes several issues with regard to interplay of CloseWatcher Keith: there are several things within requestClose which make the interaction with close watchers redundant. Seems like it's just for code cleanliness. But the bypasses increase complexity and cause lots of little issues. I proposed 3 solutions. Luke: We need (3) from your list regardless. Keith: light dismiss request close could also skip close watcher by calling into request close Luke: the closedby attribute in theory created close watchers for all dialogs, possibly in a disabled state. Luke: We could definitely simplify this by stopping using the close watcher machinery. Keith: there is another strategy for closedby=none. Domenic: I don't think requestClose() should work in disconnected states at all! Keith: not congruent with the rest of the API, which dispatches events while disconnected. E.g. close(). Anne: might make sense to throw like showModal() does. Keith: Anyway, there's still complexity around close watcher with light dismiss. Luke: IMO not too big a deal with light dismiss, because you can only light dismiss visible dialogs. Keith: more an implementation issue, e.g. the requestClose return value. Luke: I think that's more the nature of the flow of data Keith: but if you interleave close() and requestClose(), things can get messed up Luke: I don't think so because it's synchronous Keith: but nested event listeners Domenic: (big speech on how this is complex, he's sorry, and still thinks close watcher is in theory a good architecture, but maybe we'll need to fix stuff or abandon it in parts.) |
What is the issue with the HTML Standard?
We skipped our last weekly triage call (#11170) and I will also cancel the one on April 10, as discussed on Matrix. The next one is scheduled for April 17, 1am PDT. Note that this is 2 weeks later in an APAC + 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.
The text was updated successfully, but these errors were encountered: