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

[Maciej Stachowiak]

On Nov 18, 2013, at 9:05 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

> On Sun, Nov 17, 2013 at 3:11 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> It seems like the blockers to this syntax working as-is are:
>> - For Safari and Chrome, url(attr()) doesn't work.
> 
> This will never work; for legacy compat reasons, url() is not a
> function, but a syntax construct specially recognized and handled by
> the parser.  (Don't nest incompatible microsyntaxes, kids!)
> url(attr()) is compatibly a bad-url token right now.
> 
> However, "attr(foo url)" does work, at least per spec.  I don't think
> it's been implemented yet.

Thanks for the clarification. Modulo the syntax change, it still seems like something eminently implementable.

> 
>> - 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.
> 
> Yes, this has been a longstanding suggestion to make a 'content' image
> actually make the image replaced, as opposed to its current behavior
> which inserts an anonymous replaced-element child into it.  As
> fantasai and I haven't significantly picked up the Content spec
> lately, we haven't added it yet.

I'm not enough of a CSS expert to understand the implications of that change. What would be the observable behavior changes that 'content: replaced' would produce?

> 
>> - For Firefox, the 'content' property doesn't work on an element (as opposed to :before and :after)..
> 
> This is just a lack of implementation.
> 
>> 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:
> 
> It didn't actually work - if you try to size the element, you'll note
> that the images don't care.

Not sure what you mean by this. Do you mean that explicitly sizing the <img> will be ignored by the replaced 'content' image? Because that does not seem to be Safari or Chrome's current behavior. In particular, this markup always gives me a 10x10 image but the contents change with the window size:

<style>
.artdirected {
    width: 10px;
    height: 10px;
}
@media (min-width: 480px) {
 .artdirected { content: url(foo-small.jpg); }
}
@media (min-width: 600px) {
 .artdirected { content: url(foo-medium.jpg); }
}
@media (min-width: 800px) {
 .artdirected { content: url(foo-big.jpg); }
}
</style>
<img class="artdirected" src="foo.jpg" src-small="foo-small.jpg" src-medium="foo-medium.jpg" src-big="foo-big.jpg">



> 
>> (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.
> 
> Sounds like something that could potentially be fixed.
> 
>> (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).
> 
> This is because the preloader doesn't understand CSS yet.

Yes, but this affects (a) polyfill deployability and (b) the level of cleverness required in the preloader's CSS parsing (it has to not only start preloads from CSS but inhibit natural image preloads).

Regards,
Maciej