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

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></div>
<style>
div::before {
  display: block;
  width: 400px;
  height: 100px;
  border: thin solid;
  content: "foo" url(http://xanthir.com/pony);
}
</style>

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
do.

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

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

Correct.

~TJ