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

[Adam Barth]

On Fri, Nov 15, 2013 at 1:55 AM, Yoav Weiss <yoav at yoav.ws> wrote:
>> On Tue, Nov 12, 2013 at 7:31 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>> Content authors can already do what is described above, and in fact often
>>> do. However, a <div> with a background-image property set is not the same as
>>> an <img> in practice. Here are a few differences:
>>>
>>> (1) There's no ready way to have an element size automatically to its
>>> background-image (the way an <img> will to its src by default).
>>>
>>> (2) In general, browsers will not provide the same user interaction
>>> operations for a background image as for a content image in an <img> element
>>> (e.g. ability to drag it elsewhere, context menu items to save it, etc).
>>>
>>> (3) Assistive technologies will ignore background image holding divs for
>>> which no textual equivalent has been provided (as opposed to <img>, where
>>> they do something like reading the filename, or just indicate the presence
>>> of an image without labeling it).
>>>
>>> (4) Software that processes content to look for images may treat content
>>> images in <img> differently from images specified as backgrounds, for
>>> instance by assuming background images are decorative and therefore less
>>> meaningful and/or less related to search terms in text on the page.
>>>
>>> Some of the above may be addressable by using the 'content' property
>>> instead of the 'background-image' property, though using 'content' on an
>>> element as opposed to a :before or :after pseudo does not work reliably
>>> cross-browser.
>>
>> I agree with Maceij's concerns here.
>> I also think that writing inline CSS will be cumbersome in a CSP world.
>> Hashes will make it easier for "static" inline CSS, but if we're going to
>> write down frequently-changing, content images' resources in inline CSS,
>> that'd be a lot of hash calculations. A build step can help, but it's a
>> downside of this approach.
>
> Can any proponent of the inline-style based methods address the concerns
> Maciej and myself have raised?

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.

Adam