- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 05 Nov 2025 17:50:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[selectors-4] additional resource state pseudo-classes for img / picture elements`, and agreed to the following:
* `RESOLVED: Add :broken (with alt fallback semantics) and make progress on defining :loaded or :loading`
<details><summary>The full IRC log of that discussion</summary>
<SebastianZ> https://github.com/w3c/csswg-drafts/issues/7467#issuecomment-1412653946<br>
<emilio> SebastianZ: there was a question about where to add additional resource state pseudo-classes, there was a proposal by crissof (?)<br>
<emilio> ... the proposal is to accept those pseudo-classes<br>
<TabAtkins> q+<br>
<noamr> q+<br>
<emilio> ... I saw noamr had a few remarks<br>
<emilio> ... regarding those<br>
<emilio> ... which is when we introduce them for images in the future we might have issues if we want to extend those for other media types<br>
<emilio> q+<br>
<TabAtkins> ack TabAtkins<br>
<emilio> ... second thing is that non-ok status and broken are different in his opinion<br>
<weinig> q+<br>
<emilio> ... and what about cross-origin and no-cors images<br>
<emilio> noamr: with cross-origin no-cors is that we can't expose whether the image is a 404 or anything else<br>
<emilio> ... we should start with something a bit more conservative<br>
<emilio> ... to just reflect that perfectly aligns with whether the image emitted a load or error event<br>
<emilio> ... so load event means it's complete, error is bad url or network error or ...<br>
<Rossen9> ack noamr<br>
<emilio> ... all kinds of things can cause an error event<br>
<emilio> ... something that reflects those two states would be a good start<br>
<smfr> agree with the more conservative approach first<br>
<emilio> ... and maybe not try to be more detailed than that<br>
<dholbert> emilio: I was going to propose something very similar, start with broken...<br>
<dholbert> emilio: more complicated than load event -- fire a load event, start an image load<br>
<dholbert> emilio: you want to remove the broken state as soon as you fire image load [?]<br>
<SebastianZ> q+<br>
<dholbert> emilio: gecko does have something like this; you need that concept to show alt feedback<br>
<Rossen9> ack emilio<br>
<dholbert> emilio: I think we should match our alt-feedback behavior<br>
<dholbert> emilio: if we would show alt-feedback, the image should match broken<br>
<dholbert> emilio: we can expand from that, but there's a lot that's proposed, and I don't think we need all of them. FWIW you mostly need 'broken' (trying to load an image, doesn't load, so you want to show a placeholder or something)<br>
<dholbert> emilio: a lot of the different states you can't really expose. So: I'm ok starting with 'broken'; I don't care about the name<br>
<dholbert> emilio: can improve if more use cases come up<br>
<Rossen9> ack weinig<br>
<emilio> weinig: has any thought been put into how this might be exposed for CSS images?<br>
<emilio> ... long-standing goal of representing <img> as content: url or so<br>
<emilio> ... lots of issues here<br>
<emilio> ... but do we know which parallel states we'd need<br>
<emilio> noamr: css images don't show broken state<br>
<emilio> weinig: sure but still have similar loading states<br>
<emilio> noamr: there's a different issue<br>
<emilio> fantasai: not clear which pseudo-classes are being proposed concretely<br>
<noamr> q+<br>
<emilio> ... agree with emilio and others that we don't want to implement all of them<br>
<emilio> ... whatever names we're going to pick for these is it going to apply to only img or do we need to be more specific?<br>
<emilio> ... or are they generic enough?<br>
<emilio> ack fantasai<br>
<Zakim> fantasai, you wanted to ask which set of pseudos, specifically, we're proposing to add there are lots of lists in this issue<br>
<Rossen9> ack fantasai<br>
<emilio> ack SebastianZ<br>
<emilio> SebastianZ: iterating on which ones can we agree on<br>
<emilio> ... emilio said :broken<br>
<emilio> ... what about :loading and :complete? I think those are the most pressing ones<br>
<emilio> fantasai: I think :complete is too ambiguous<br>
<noamr> q+<br>
<emilio> ... but :loading might make sense?<br>
<emilio> q+<br>
<emilio> fantasai: complete in the context of selectors is very ambiguous<br>
<castastrophe> +1, :loading and :loaded is a nice pairing<br>
<bkardell> :borken<br>
<emilio> noamr: I think if we had broken and either :loaded or :loading the rest can be derived<br>
<Kurt> q+<br>
<Rossen9> ack noamr<br>
<emilio> ... I think there's a strong use case for loading or loaded<br>
<emilio> ... animating when it's already loaded<br>
<flackr> +1<br>
<SebastianZ> q+<br>
<kbabbitt> I like :loading, :loaded, :broken as a starting set<br>
<emilio> ... we could also bikeshed the names later<br>
<dholbert> emilio: one of the issues with :loading and :loaded is...<br>
<dholbert> emilio: when you already have an image, and you trigger a new load, the browser will keep displaying the previous image<br>
<dholbert> emilio: so it's :loading and :loaded at the same time, in a way<br>
<dholbert> emilio: I could see use-cases where you'd want one or the other<br>
<dholbert> emilio: I'm not opposed... I like :broken because it's corresponds well to an existing state (alt feedback stuff)<br>
<noamr> q+<br>
<Rossen9> ack emilio<br>
<dholbert> emilio: we need to decide how to handle the subtlety around :loading/:loaded in this case though. Various outcomes be unexpected for authors<br>
<dholbert> s/be/might be/<br>
<dholbert> emilio: that's why I like :broken as a start<br>
<emilio> Kurt: wanted to add that there's :-moz-{broken,loading}<br>
<emilio> ... maybe they could be investigated<br>
<Rossen9> ack Kurt<br>
<emilio> ... and standardize those<br>
<emilio> q+<br>
<emilio> ... worth investigating current usage and so on<br>
<dholbert> I don't see `moz-loading` in our source tree at all... https://searchfox.org/firefox-main/search?q=moz-broken&path=&case=false&regexp=false<br>
<dholbert> emilio: we (Gecko) remove those from content so authors cannot use them anymore<br>
<dholbert> emilio: we still have support for -moz-broken, but I removed -moz-loading<br>
<dholbert> emilio: mostly because we didn't have a use-case for the semantics of that pseudo-class<br>
<dholbert> emilio: I guess we could add telemetry to see how often we find -moz-broken in the wild (but it's not-parsing)<br>
<dholbert> emilio: I could tell you the use-cases from inside the Firefox codebase (where it's parsed) if that's useful<br>
<lea> q?<br>
<lea> q+<br>
<Rossen9> ack SebastianZ<br>
<emilio> q-<br>
<emilio> SebastianZ: if we resolved on that would that also cover other media like <audio> and <video>?<br>
<emilio> noamr: I think <audio> and <video> have their own pseudo-classes right?<br>
<emilio> SebastianZ: yeah, :seeking, :buffering, :stalled<br>
<emilio> ... which go into that direction but not completely covering that thing<br>
<emilio> noamr: It's very likely that <video> and <audio> are different<br>
<emilio> ... I think :seeking, :buffering, :stalled make more sense there<br>
<emilio> ... other concepts are a bit different, :broken has the poster image and so on<br>
<Rossen9> ack noamr<br>
<emilio> ... maybe we should define them a bit differently<br>
<emilio> noamr: something that we can come out with is to define :broken and :loading with an open issue for the specific semantics<br>
<Rossen9> ack dbaron<br>
<emilio> dbaron: I was going to say that the thing that lead for the implementation of these was bzbarsky about the default styles for img / object<br>
<emilio> ... possibly plugin and embed<br>
<djmarland> q+<br>
<emilio> ... some of the reason is because the default styles for these things have evolved over time<br>
<emilio> ... object might have evolved over time<br>
<emilio> ... that's my memory of why Gecko found these pseudo-classes<br>
<Rossen9> ack lea<br>
<djmarland> q-<br>
<emilio> lea: sorry if this has been said before, :loading / :loaded doesn't paint a full picture before of lazy loading<br>
<flackr> q+<br>
<castastrophe> :queued ?<br>
<djmarland> The issue suggests :pending<br>
<djmarland> https://github.com/w3c/csswg-drafts/issues/7467#issuecomment-3257156796<br>
<emilio> ... would it be useful to have that state?<br>
<emeyer> q+<br>
<bkardell> why not just style the img element by default?<br>
<keithamus> Presumably `:not(:loading, :loaded)` suffices?<br>
<bkardell> right<br>
<emilio> castastrophe: pending might be more translateable<br>
<emilio> flackr: what would you do in that state? there's no image<br>
<djmarland> :deferred<br>
<emilio> Rossen9: prevent it from loading? that's the only thing I can imagine you can do<br>
<emilio> ... or you can have a different visual for when it's loading or queued or whatever we call it<br>
<lea> keithamus: wouldn't that be `:not(:loading, :loaded, :error)`? I've lost track of what we've resolved around that<br>
<bkardell> I think what keithamus said<br>
<dbaron> there are other possibilities, e.g., loading failed for some reason, loading was blocked for some reason, etc.<br>
<emilio> flackr: but it basically means it's off-screen right?<br>
<Rossen9> ack flackr<br>
<emilio> flackr: there might be a difference between having nothing to render and the low-res version of a progressive image?<br>
<lea> q?<br>
<lea> q+<br>
<Rossen9> ack emilio<br>
<emilio> ... maybe we don't need to distinguish that just yet but it might be useful to fade a placeholder color into the image<br>
<Rossen9> ack emeyer<br>
<emilio> emeyer: was going to say something similar to what flackr said<br>
<castastrophe> Should we go back to the issue with this additional discussion and gather use-cases?<br>
<fantasai> +1 castastrophe<br>
<kbabbitt> +1 castastrophe<br>
<emilio> ... I can imagine authors doing simple style for an image that is neither loading nor loaded<br>
<emilio> ... whatever we call it<br>
<lea> +1 castastrophe<br>
<emilio> ... this might be doable with a `:not()`<br>
<emilio> ... since these are inexactly defined that there would be states that an image could have that would be neither<br>
<emilio> ... maybe with clear definitions we could resolve that concern<br>
<castastrophe> I would find it helpful in the issue to put together a table of the proposed states and when an image would meet those requirements<br>
<Rossen9> ack lea<br>
<emilio> ack lea<br>
<dbaron> +1, this stuff is complicated so we shouldn't expect authors to write the correct complicated expression...<br>
<emilio> lea: apparently UAs still support lowsrc<br>
<castastrophe> To give authors a prompt to provide use-cases<br>
<emilio> ... so we should probably define how that works<br>
<SebastianZ> castastrophe I'd like to resolve on the ones that we agree on, at least.<br>
<keithamus> q+<br>
<emilio> ... there might be consensus on going back to the issue and collect use cases<br>
<Rossen9> ack keithamus<br>
<castastrophe> yeah +1, not opposed to a resolution<br>
<emilio> ... even if we take some of it back to the issue there might be consensus on `:broken` or so?<br>
<emilio> keithamus: For :loading placeholder content and transitions feel like the big use case for those?<br>
<lea> It seems we'd have consensus between a state for "has successfully loaded" and "is broken"<br>
<castastrophe> +1, I would support resolving on :broken at least<br>
<emilio> ... not sure if you want more concrete use cases<br>
<djmarland> q+<br>
<dholbert> emilio: similar for :broken, showing a placeholder or something when the image has failed to load is the same kind of use case<br>
<lea> we do want to be able to target succesful loading too, e.g. to not apply placeholder backgrounds<br>
<dholbert> keithamus: you might want to do that on an ancestor, too (collapsing borders, etc. on a container element)<br>
<emilio> keithamus: Yeah if you have a broken image hiding some of the card borders or so<br>
<emilio> djmarland: :not() can get complicated with :has()<br>
<Rossen9> ack djmarland<br>
<dholbert> emilio: why? you'd need to type 'img' directly, but that's not too bad<br>
<emilio> djmarland: Yeah maybe you can, but feels a bit more complicated<br>
<emilio> ... would be simpler with a more obvious selector<br>
<castastrophe> I could see reflowing :has(img:not(:loaded))<br>
<flackr> Something like :has(img:not(:loaded)) ?<br>
<lea> +1<br>
<emilio> noamr: let's resolve on having :broken and :loaded with details of how :loaded works tbd<br>
<emilio> PROPOSED: resolve :broken (with alt fallback semantics) and :loaded (with semantics tbd)<br>
<flackr> +1<br>
<lea> +1<br>
<SebastianZ> +1<br>
<smfr> +1<br>
<dholbert> emilio: not an objection, but I wonder about :loaded vs :loading... Depending on how we define it, there might be interesting interactions with :broken<br>
<flackr> I think :loaded will be easier to precisely define than :loading where things like progressive loading<br>
<dholbert> emilio: maybe resolve on :loading and :loaded simultaneously?<br>
<fantasai> Is a broken image :loaded?<br>
<castastrophe> What if just resolve on :broken for now?<br>
<castastrophe> It seems to have more consensus<br>
<emilio> dholbert: not objecting, but :loaded without semantics seems weird to add, for the replaced image case<br>
<emilio> ... I guess I don't see a lot of value on adding :loaded without knowing what the semantics are going to be<br>
<flackr> qq+<br>
<emilio> ... maybe we should resolve on :broken + exploring :load*<br>
<emilio> PROPOSED: Resolve on :broken (with alt fallback semantics) and make progress on defining :loaded or :loading<br>
<Rossen9> ack flackr<br>
<Zakim> flackr, you wanted to react to djmarland<br>
<emilio> flackr: was going to propose that :loaded is "there's no loading going on"<br>
<emilio> q+<br>
<emilio> dholbert: I think that might not be the state we want to target<br>
<noamr> :broken is already good progress, I'm fine with that<br>
<emilio> flackr: fine to defer if contentious<br>
<emilio> RESOLVED: Add :broken (with alt fallback semantics) and make progress on defining :loaded or :loading<br>
<noamr> +1<br>
<dholbert> emilio: we may want to explore :loaded and :loading in terms of HTML img element states<br>
<dholbert> emilio: e.g. img has .complete() which maybe would correspond to :loaded state<br>
<dholbert> emilio: though that may not be what we want<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7467#issuecomment-3492573205 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 November 2025 17:50:25 UTC