[css-images-4] Queries for image support

[frivoal]

Converting an old mail thread to a github issue for ease of tracking.
The thread starts here: https://lists.w3.org/Archives/Public/www-style/2016Apr/0348.html

---

@AmeliaBR said:

Recently, while browsing the web with image downloads disabled to save data, I was struck by how broken some sites were, despite being coded to current best practices. Screen reader-accessible text labels (for icon buttons) that were "visually hidden" with CSS were completely inaccessible to me. If I turned off those styles in the inspector, the site became usable again.

Wouldn't it be nice if a media query could restrict those style rules so that they aren't applied for users who don't receive the image icons?

Other use cases for changing styles based on whether or not images are supported:

• elegantly styling the alt text for <img>, instead of shoving it into the width and height reserved for the image
• switching from a figure caption that is normally visible on hover/tap to one that is displayed by default in place of the image
• changing colors/blending modes when background images won't be displayed

Given that some browsers / accessibility modes support content images but not background images, the media query could distinguish between support for images in different contexts:
images: none
images: content
images: all (meaning content + stylesheet images)

A second aspect of image support that it would often be useful to test for in a stylesheet is which types of images are supported. Currently, CSS has no way to test this support: a url() reference in a property value is valid even if the downloaded file type would be unrecognized. Newer high-compression image formats cannot be safely used with fallbacks to older file types unless you use JS-based support tests. In contrast, the HTML <picture> element has already demonstrated the implementability of this type of fallback switch.

The <source> element for <picture> uses MIME type strings to distinguish image formats. It's a little verbose, but it adds consistency and extensability:
image-type: image/png
image-type: image/svg+xml
image-type: image/webp
Maybe the "image/" could be made optional for brevity.

Of course, if a browser does not currently support any images for this document, these should all evaluate as false. But the other media query is still useful for the general case and because it addresses the case when an image type is supported in content, but images are not downloaded at all for stylesheet properties. (Although I think that should also trigger an @supports test on the relevant CSS properties.)

---

I responded:

For this kind of use cases, especially the first one, I think a pseudo class that matches on images that fail to load would be easier to use than a media query.

A second aspect of image support that it would often be useful to test for in a stylesheet is which types of images are supported. Currently, CSS has no way to test this support: a url() reference in a property value is valid even if the downloaded file type would be unrecognized. Newer high-compression image formats cannot be safely used with fallbacks to older file types unless you use JS-based support tests. In contrast, the HTML element has already demonstrated the implementability of this type of fallback switch.

The <source> element for <picture> uses MIME type strings to distinguish image formats. It's a little verbose, but it adds consistency and extensability:
• image-type: image/png
• image-type: image/svg+xml
• image-type: image/webp
Maybe the "image/" could be made optional for brevity.

For this use case, it looks like using fallbacks in the <image> production would work as well, but maybe using media queries is still better.

---

@AmeliaBR responded:

For this kind of use cases, especially the first one, I think a pseudo class that matches on images that fail to load would be easier to use than a media query.

An element pseudoclass does have the benefit of applying to broken links as well as no-image settings. Mozilla already has a prefixed pseudoclass for this case. However, it puts constraints on which other elements you can effect with the selector (needs to be a direct sibling after the missing image in the DOM tree). This limits the use for doing things like un-hiding text labels and captions. Still better than nothing, of course.

---

I responded:

Right. Maybe we could make something along these lines to work, and it would solve the problem:

<style>
 label[for] { display: none; }
 image:failed-to-load { display: none; }
 label:for(image:failed-to-load) { display: block; }
</style>
<label for="foo">This is my nice image</label>
<img src="....." alt="...." id="foo">

---

@AmeliaBR responded:

Interesting, idea. Would be fun to generalize a :for(selector) pseudo-class for styling form element labels. Eg label:for(:required)

But doesn't address the too-common case where the image icon that failed to load is a CSS background image or generated content image.

---

@fantasai responded:

For this kind of use cases, especially the first one, I think a pseudo class that matches on images that fail to load would be easier to use than a media query.

I think that having a media query here would be useful
in many cases. While in some cases you care about whether
a specific image has loaded, if there are no images then
you might want to do something different layout-wise.

Also, your suggestion doesn't address the stylesheet
images question, it would only work for content images.

[Malvoz]

If you transform: rotate(Xdeg) an image which fails to load, currently the alt text naturally stays rotated which this could solve, e.g. img:failed-to-load { transform: none|unset; }.

Also this may be related to whatwg/html#3631 if it is decided that appearance of image placeholders is to be controlled by CSS.

[emilio]

FWIW, in Firefox you can do img:-moz-broken, which does something like what you want.

Though I think we shouldn't expose that to content...

[frivoal]

it seems that conditional rules that apply only if a particular type of resource is both supported and actually loaded is not specific to images. We have a very similar request for fonts in #2540. We have not resolved on a way to solve it yet, but it seems on first approximation that whatever we eventually do to solve that problem should solve both.

Maybe we should close this issue or that issue as a duplicate of the other, and broaden the scope of the one that isn't closed.

[Zhang-Junzhi]

Maybe it would be better to be generalized to any elements with external resources.

I guess a browser or its extensions can, in many ways, disable/block any scripts, including inline scripts, in that case, I still would like to see a fallback mechanism to give users with some friendly hints about the current load status of various external resources, even including load failure of script files. Please refer to the issue @Malvoz referenced above.

[AmeliaBR]

I remembered about this discussion following a twitter thread asking how to test for WebP support. Tim Petrusky reports that having to use JPEG instead of WebP for background images increases download size by 50%. Bumping the thread to get some more attention on it.

For image format support, there are two ways we could handle it:

• inside the image() or image-set() functions (if we get commitments to actually implement such things!)
• as a conditional @-rule, such as a media query or a special @supports rule syntax

For "did this particular content image (or other element linking an external resource) fail to load/parse correctly", I think standardizing the Mozilla broken image pseudo-class is valid. We could also add a second pseudo for the "waiting to load" state, which becomes more important with native lazy loading.

For overall image / external resource download settings, I still think this makes the most sense as a media query. But at least some use cases could be handled by the other features above.

[tabatkins]

While I probably want to add type() to image() as well, I've just added it to image-set() so far, to match the functionality of HTML's picture.

Agenda+ for review and approval.

[css-meeting-bot]

The CSS Working Group just discussed [mediaqueries] Queries for image support, and agreed to the following:

• RESOLVED: Republish Images 4

The full IRC log of that discussion

<dael> Topic: [mediaqueries] Queries for image support
<dael> github: https://github.com//issues/656
<dael> TabAtkins: This one is me
<dael> TabAtkins: This is in fact a CSS Iages topic.
<dael> TabAtkins: Some time ago had resolution to have image set discriminate on format. I added that into spec
<dael> TabAtkins: Let me add a link ^
<dael> TabAtkins: Alongside resolution you can pass a type function that spec a mime type. Same as picture.element in html. Skipped if invalid. Has no effect on image.
<dael> TabAtkins: Questions, does this look good?
<dael> TabAtkins: Second is aI used type function but fontface uses format function for similar. Should I make html or fontface?
<dael> fantasai: fontface jsut uses arbitrary keywords, right?
<dael> myles: Yes
<florian> seems fine to use type()
<fantasai> s/jsut/doesn't uses MIME types, but/
<dael> TabAtkins: Weakens the argument. Then I guess use type.
<dael> TabAtkins: Does this look fine to everybody? This would go into Images 4. It's a WD. If it looks good I want to republish Images
<dael> florian: lgtm. One question. As we mentioned this was tagged as MQ. Is that b/c initial request was to have a MQ and you're proposing this?
<dael> TabAtkins: Separate thread I could not find. I was mistaken and grabbed this. We have one elsewhere to do what I explained. I found this first and didn't go find the right issue
<dael> florian: So this resolution doesn't have any relevence to if we need MQ
<dael> TabAtkins: Right
<dael> Rossen_: So you're just looking for draft republish?
<dael> TabAtkins: Yes. General confirm this is fine and a resolution to repub
<dael> Rossen_: Anyone feel this is not in right direction?
<dael> Rossen_: If not we'll resolve to republish
<dael> RESOLVED: Republish Images 4