[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':
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