[selectors-4] additional resource state pseudo-classes for img / picture elements

[voxpelli]

The Resource State Pseudo-classes section mentions (emphasis mine):

The pseudo-classes in this section apply to elements that represent loaded resources, particularly images/videos

Yet none of the currently defined pseudo classes seems to actually apply to any images.

Following up on a recent popular tweet that used onerror on img-tags to style failed images, I would like to mimic #3821 and resurrect a few of the pseudo-classes suggested in #3134

Primarily I would like to see:

• :failed – a replacement for the use of onerror to style images that fail to load
• :loading – a way to style images that are in the process of loading (would include both downloading and decoding I think)

Could also be useful to support the existing:

• :stalled– as images on bad internet connections can very much stall to load as well, especially a progressive JPEG which could me stuck in a low quality state.

[fantasai]

Makes sense to me. I wonder if :buffering and :loading should be interchangeable?

Also :failed should probably be :loading-failed, since lots of things can fail in a lot of different ways. :)

Agenda+ to ask the CSSWG what it wants to do here.

[css-meeting-bot]

The CSS Working Group just discussed Additional resource-state pseudo-classes for img/picture.

The full IRC log of that discussion

<TabAtkins> Topic: Additional resource-state pseudo-classes for img/picture
<TabAtkins> fantasai: someone asked about pseudos for images to indicate whtehr they're loading, failed, stalled
<TabAtkins> fantasai: So does the WG think this is reasonable?
<dbaron> I think Gecko has internal pseudo-classes that do this
<TabAtkins> fantasai: do we make loading & buffering both amtch when a video is trying to buffer and when an image is loading?
<TabAtkins> TabAtkins: Like allow both to apply to either condition?
<TabAtkins> fantasai: Yeah they're both loading, tho i'm not sure if the words are appropraite
<TabAtkins> TabAtkins: I'm happy to defer that to editors
<bradk> applies to any element that can take time loading, eg iframes?
<TabAtkins> Rossen_: Sounds like there's general approval, should we reoslve on "yes, details TBD"?
<bradk> +1
<bramus> +1
<chrishtr> +1
<TabAtkins> fantasai: We can propose edits and come back.

[06b]

If it is any help for whoever creates the proposal, Firefox has the :-moz-broken pseudo-class which could be used as a model for broken images. This allows for the use case of setting a fallback via content: url() only when the image fails (as it currently always replaces an element as noted in #2831).

img:-moz-broken {
    content: url("placeholder.jpg");
}

[Crissov]

I’d like to suggest that HTTP status codes, particularly those commonly encountered in response to GET requests, be associated with some of the pseudo-classes proposed herein and in #3134. They may also inform the selection of some other states that may have frontend presentation, e.g.:

• :partial — 206, 416
• :complete — 200
• :broken — 404, 410
• :failed – 401, 402, 403, 406, …; 500
• :loading – 30x, before receiving 200 or 40x
• :stalled – 503, 504
• :cached — 304
• :redirected — 300, 301, 302, 307, 308 encountered in the request process, i.e. not mutually exclusive with most of the other pseudoclasses

[Mouvedia]

• :loading – 30x, before receiving 200 or 40x

Something that might be worth discussing is whether it should copy :-moz-loading matching mechanism or not.
i.e. match elements which are waiting to be loaded

Note that images that are in the process of loading are not matched by this pseudo-class.

which sounds more like :queued to me.

---

Concerning ad blockers, is a :-moz-suppressed alternative missing as well?

[Crissov]

I guess there is also value in something like :delayed or :scheduled for lazy-loading scenarios.

[freedimension]

Came here to propose a :loaded or :complete pseudo attribute for iframes specifically, but then found this issue. Would be really nice to expose such states for all kinds of post loaded contents.

[SebastianZ]

I think @Crissov's suggested pseudo-classes are a valid proposal. And seeing no objections on the suggestion so far, let's bring this to the agenda again.

Sebastian