Upcoming WHATNOT meeting on 2025-01-23 #10923
Comments
AgendaAttendees: Keith, Olli, Anne, Philip(!), Domenic, Noam Review past action items1a Olli and Anne will play with the Chromium implementation and review the proposal for How to spec user interaction for select more closely. Carryovers from last time2a [Noam] Async css New topics3 [Anne] Add Last-Event-ID to CORS-safelisted request headers Action Items
Minutes1a: Olli: Chromium Canary currently crashes. Makes it tricky to play with. 2a: Continue to carryover. 2b: Continue to carryover. 2c: Continue to carryover. 3a3a: Domenic: I think in principle the team responsible for this is willing to do it, but it would be fairly low priority. Anne: Okay, I guess it’s reasonable to move forward with test and specification changes here and then see if implementations adopt. Domenic: If rexxars is up for implementing that would certainly move it along more quickly. Olli: Usage might be too low to notice any impact in non-release browsers. [discussion of exactly how this works and what the compat risk might be] [conclusion: the compat risk is that this will sometimes trigger preflights, for when the header contains certain bytes] Noam joined, back to 2a! Noam: this is an open-ended topic. that doesn't block rendering of things after it. The discussion surfaced an existing interop issue around what exactly is blocked by normal . It would be a clear win to get interop on that. In the thread I was trying hard to get an answer to "what's the use case?" Many use cases I found non-legit, which would cause flash of unstyled content. (For example people wanting to use this for below-the-fold content, would experience FOUC when scrolling.) I found two cases that seemed reasonable: 1) For sheets containing font-display: swap, where you are deliberately causing FOUC. 2) things that are styling themselves into existence, e.g. display: none by default, and then the stylesheet comes in to make it appear. [side discussion about whether we like font-display: swap. foolip says: https://w3c.github.io/IFT/ might help.] Noam: should we build a generic async CSS thing? Or should we build something for these two specific use cases? No specific proposals yet but I'm curious about the group's opinions. [Noam proceeds to give specific proposals, verbally.] Yoav: similar to async script, there is confusion here between download and execution. I think there's something here but I'd like to flesh out the use cases further. When do people want this, can we fix the races that it would cause? Keith: I think this is a good primitive. You can do async CSS today using adoptedStylesheets or critical CSS or the style script hack. This doesn't add new footguns. Async font loading is fine. We had this problem at GitHub and there's no good solution. We'd like to defer CSS for dialogs, for example. Yoav: but this is indeed already possible today with script. I'd still like to hear more about the use cases. E.g. for the dialog case you still don't want the stylesheet to lose the race with the dialog. Keith: remove the attribute to reactivate render-blocking? Domenic: Since you can do this with script already, we already have the primitive. So if this is purely about making the use cases easier for people who want a declarative solution, then I think it should be aimed at not footgunning. Noam/Yoav: discuss use cases and whether we should build something for the two cases. Domenic: action item for Noam: make an explainer summarizing the thread, both the use cases and the things you believe are not good use cases. See if the community agrees. Maybe a WICG repo so that there can be separate issues instead of one big mega-issue that's too hard to read. Noam: Will do! And I'll open a separate HTML issue for the current interop issue. Olli: side note: async scripts do cause interop issues! Although CSS won't necessarily be as bad. Anne: well, getComputedStyle() could make it just as bad. Yoav: and across different issues. It's compat and interop. I think async scripts were a bit of a mistake and I'd like to not repeat that. Anne: defer is really good but there's very few use cases for async. [some discussion about best use cases for async and whether module scripts suffer from the same issue] Noam: should we have a label for "please go to a CG?" Anne: we have "needs concrete proposal" Noam: would appreciate something more specific, "this is not ready for WHATWG". Anne: "needs incubation" seems good. You can add a label in whatwg/meta. custom element registryAnne: Not on the agenda, but do people have more feedback? I tried to respond async. Olli/Keith: I've been waiting for the web components CG Anne: very European-unfriendly schedule, not sure I'll be able to make it… Keith: I'll try to make sure the chair makes it possible for you. Anne: sounds good. But also if you have async comments please give them! Anne: #10854 would be a good please to provide feedback. If it’s DOM-specific whatwg/dom#1339 is also fine. loading=lazy videoKeith: Delaying loading / downloading the poster until the video enters the viewport Domenic: and this is different from preload=none because it's viewport-centric. Domenic: lots of thumbs-ups! Anne: there's a general question about whether posters should get more Keith: if that's the preferred direction we can probably make it work. The thread has some ideas. Anne: I'm trying to channel the comments from Jer Noble at Apple who commented in the poster thread. Anne: preload=none plus loading=lazy is strange? Domenic: #10376 (comment) shows how it should work Philip: but preload=none with autoplay is kind of nonsense… Anne: maybe some of these combinations need to be made non-conforming, and we need to double-check the spec's processing model to make sure it's reasonable. Keith: so what do we do? Domenic: we need to make sure all existing combinations of autoplay and preload have good behavior. And then define exhaustively every combination of autoplay, preload, and loading attributes. Some can be disallowed in the conformance requirements or have one of the attributes ignored, that's OK. Philip: yeah there's an "effective preload" concept where preload gets ignored sometimes because autoplay. We can do similar things. Philip: ideally we only change things to load later than they already would. Loading sooner is a bit iffy. Philip: [looks at the spec] the spec is unclear because preload is a hint. And there's a non-normative note saying "The autoplay attribute can overload the preload attribute" [general consensus we all want to see the big matrix of preload x loading x autoplay] |
What is the issue with the HTML Standard?
Today we held our weekly triage call (#10906) and I will post the meeting notes there in a bit. The next one is scheduled for January 23, 1am PST. Note that this is 1 week 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: