W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2016

[csswg-drafts] [mediaqueries] Queries for image support

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Thu, 27 Oct 2016 07:54:51 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-185597778-1477554889-sysbot+gh@w3.org>
frivoal has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [mediaqueries] Queries for image support ==
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 <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.

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.

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/656 using your GitHub 
account
Received on Thursday, 27 October 2016 07:54:57 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:04 UTC