[whatwg] <imgset> responsive imgs proposition (Re: The src-N proposal)

[Maciej Stachowiak]

On Nov 15, 2013, at 9:00 AM, Yoav Weiss <yoav at yoav.ws> wrote:

> On Fri, Nov 15, 2013 at 4:20 PM, Adam Barth <w3c at adambarth.com> wrote:
> 
>> 
>> My apologies.  I thought Christian Biesinger addressed all these
>> concerns with his proposal:
>> 
>> On Tue, Nov 12, 2013 at 5:56 PM, Christian Biesinger
>> <cbiesinger at google.com> wrote:
>>> For a bit more presentation, and while we're inventing new syntax
>>> anyway, how about this:
>>> 
>>> <style>
>>> @media (min-width: 480px) {
>>>  .artdirected { content: replaced url(attr(src-small)); }
>>> }
>>> @media (min-width: 600px) {
>>>  .artdirected { content: replaced url(attr(src-medium)); }
>>> }
>>> @media (min-width: 800px) {
>>>  .artdirected { content: replaced url(attr(src-big)); }
>>> }
>>> </style>
>>> ...
>>> <img class="artdirected" src="foo.jpg" src-small="foo-small.jpg"
>>> src-medium="foo-medium.jpg" src-big="foo-big.jpg">
>> 
>> Specifically, his approach uses an <img> element, which addresses all
>> four of Maciej's concerns.
>> 
> 
> You're right, Maciej's concerns were addressed by Christian's proposal (and
> John's followup proposal).
> 
> Any thoughts on my concerns with making inline CSS mandatory (especially
> from the CSP angle)?


To be clear, I really like the idea of a style-based responsive image solution, as it involves significantly less additional syntax and may avoid some repetition. I just want to make sure whatever we come up with does not have any undesirable side effects.

I can't get this particular example to work in Safari, Chrome or Firefox. Is it meant to? It seems to always show foo.jpg. Here's a worked version with distinct images for each filename:

-------------- next part --------------


The reason I tried is because I want to see what side effects this approach might have without having to guess that from the specs.

It seems like the blockers to this syntax working as-is are:
- For Safari and Chrome, url(attr()) doesn't work.
- For Safari and Chrome, content: replaced url() doesn't work. I couldn't find a spec for the 'content' property that includes the 'replaced' token so I am not sure what it is even supposed to do.
- For Firefox, the 'content' property doesn't work on an element (as opposed to :before and :after)..

I did not get a chance to test IE.

I was able to get Safari and Chrome to work by getting rid of 'replaced' and specifying the images in CSS instead of using url(attr). With those changes, I noted the following possibly undesirable effects:

(1) Saving the image from the context menu (or opening in a new tab or window, or other context menu operations like copy) always uses the "src" image instead of the selected image. Dragging it uses the correct image.
(2) Preloading will always preload the src (and I suspect the normal loader would do it to so that both the image src and the content: replaced source will be loaded).

#1 would likely be fixed by a more thorough 'content' implementation. #2 could presumably be fixed by a CSS-aware preload scanner and by tweaking the img implementation, but the scanner would have to know how to apply CSS selectors as it scans, since resolution of a CSS selector is what determines the right attribute to load. The problem though is when attempting to implement a polyfill of some kind. The polyfill would not be able to prevent 'src' from loading as an additional resource. This could possibly be addressed by not specifying a regular 'src' at all when using a polyfill.

Other than these two details, it seems like a good solution to the problem. Implementing url(attr()) and these quality-of-implementation improvements would possibly be simpler than src-n as currently specified, and it exposes a lot less new syntax.

Regards,
Maciej