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

Tab Atkins Jr. jackalmage at gmail.com
Mon Nov 18 14:54:16 PST 2013

On Mon, Nov 18, 2013 at 1:35 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> 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:

Ah, right, WK/Blink violate the spec wrt 'content' on real elements.
They don't support the normal value set, but do support a single
url(), which makes the element replaced.

Try it on a ::before pseudo, which implements the actual spec for 'content':

<!DOCTYPE html>
div::before {
  display: block;
  width: 400px;
  height: 100px;
  border: thin solid;
  content: "foo" url(http://xanthir.com/pony);

Even if you remove the "foo" string, so it's just a single image, it
still just sits there in the pseudo-element at its normal size,
ignoring the div::before's size entirely.

The "replaced" keyword will be a new branch in the 'content' grammar,
which allows a single url() after it, and does what WK/Blink currently

>>> (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

Right, there's always a tension between "preload the most
important/fallback version" and "preload nothing until I'm ready" for

> (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).



More information about the whatwg mailing list