- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 21 Aug 2025 07:37:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-selectors-4] CSS reflection of HTML parsing state`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> noamr: this is part of making navigation smoother and more declarative, rather than with manual JS<br> <TabAtkins> noamr: specifically, streaming navigation and same-doc navigation<br> <TabAtkins> noamr: part of that is desire to expose better states of the parser<br> <TabAtkins> noamr: in this case, it's about elements that are opened but not yet done parsing<br> <TabAtkins> noamr: while you're streaming html, you might open an <article> with a lot of text, it's starting to display but there's still content streaming in<br> <TabAtkins> noamr: some issues in the past with wanting an element to only appear when it's done, or have some indication<br> <TabAtkins> noamr: this is a very specific thing in the html parser spec<br> <emilio> q+<br> <TabAtkins> noamr: so the idea's pretty simple, a pseudo-class for whether an element is still open<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask if this should be distict from whether stuff is loaded<br> <TabAtkins> fantasai: are the use-cases different from those for querying an elemetn is loaded?<br> <TabAtkins> noamr: like an image?<br> <TabAtkins> fantasai: any element, you want parsed and all its resources loaded<br> <TabAtkins> fantasai: do you want a query distinct from that? parsed and not yet loaded?<br> <TabAtkins> noamr: a lot of things can be parsed and dont' have laoded resources<br> <TabAtkins> fantasai: yeah, those'll be done loading immediately<br> <TabAtkins> fantasai: but for something that has loaded stuff, do you need to distinguish?<br> <TabAtkins> noamr: unsure. it's a level of granularity down. don't mind starting from something a little more general like :loaded<br> <TabAtkins> noamr: and then taking it down if needed<br> <TabAtkins> noamr: if you think aobut containers, or things parsed in a chunked way, often the sub resources arne't loaded, lots of child elements<br> <TabAtkins> noamr: does "loaded" mean all the hcildren are loaded?<br> <TabAtkins> fantasai: is that what you want?<br> <TabAtkins> fantasai: specifically, what's the use-case you're trying to solve<br> <TabAtkins> noamr: people want to control their progressive loading experience better. articles coming in, but don't want it to show while it's mid-loading<br> <TabAtkins> noamr: want to either indicate it's loading, or make it invisible until it's loaded<br> <TabAtkins> astearns: looking thru web components issue, i don't see any discussion about the current :loaded trigger we have<br> <TabAtkins> astearns: i think it woudl be good to see if our existing :loaded selector woudl be sufficient<br> <TabAtkins> fantasai: so q is, rather than using a new selector, is it good to reuse the existing selector?<br> <TabAtkins> fantasai: if you haven't thought about this yet, coudl be worth thinking about<br> <TabAtkins> fantasai: so do users *want* to distinguish between parsed and loaded?<br> <astearns> ack emilio<br> <TabAtkins> emilio: to impl this, you need add a [??] notification that elements have loaded, which some elements alreayd have<br> <ydaniv> this one is somewhat related, https://github.com/w3c/csswg-drafts/issues/8175<br> <TabAtkins> emilio: when previously discussed, i think there were perf constraints with doing this for all elements<br> <TabAtkins> emilio: there's a similar thing with... like having this pseudo-class - presumably if element is empty this'll never apply, only while getting chidlren<br> <TabAtkins> emilio: i'm a bit concerned about the number of style changes it adds to page loads<br> <TabAtkins> q+<br> <TabAtkins> emilio: like :has(:loading) suddenly invalidates constantly<br> <fantasai> s/loading/parsing/<br> <TabAtkins> emilio: my udnerstanding is in the past, blink folks objected to the more general idea here<br> <TabAtkins> emilio: in the html discussions<br> <TabAtkins> noamr: that was a JS thing, this is a style thing<br> <TabAtkins> emilio: at least for us, the "children are done" thing is an extra operation the parser send to the dom<br> <TabAtkins> emilio: i think rn we only use that for select and textarea, maybe two or three more<br> <TabAtkins> noamr: from chromium perspective, we do that- it's expensive, but we can do it based on existing selectors<br> <TabAtkins> emilio: there could be a stylesheet loading in flight, don't think you can do it conditionally<br> <TabAtkins> emilio: just saying, this has been dsicussed in the past. doesn't necessarily block, but would be good to have more feedback<br> <TabAtkins> emilio: but my udnerstanding is our parser folks wouldn't be very happy with this<br> <TabAtkins> noamr: i'll check, i have more parser knowledge than i did a year ago, not too concerned<br> <TabAtkins> noamr: when we added blocking for link rel=expect, similar thing<br> <TabAtkins> emilio: yeah, that's conditional tho<br> <TabAtkins> emilio: something that might be interesting is restricting this to elements the page cares about<br> <TabAtkins> emilio: so that might be good to investigate. you usually care about just one or two elements, not all sub-children<br> <TabAtkins> emilio: just like a main article<br> <TabAtkins> emilio: would be good to get some hint from the page about what elemens i care about<br> <astearns> ack TabAtkins<br> <emilio> TabAtkins: was going to suggest exactly that<br> <emilio> ... it's not a state we care about for ~all elements<br> <emilio> ... so maybe we can opt in at the markup level<br> <emilio> ... with an attribute or so, which would opt into the pseudo class<br> <emilio> ... that'd make me happier with reusing :loading/:loading<br> <emilio> ... usually that's a thing that applies more to images / videos<br> <emilio> ... but if it's just a handful of articles you have marked or so it seems fine<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12578#issuecomment-3209370494 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 August 2025 07:37:35 UTC