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

[matmarquis.com]

On Nov 15, at 12:12 PM, Shane Hudson wrote:

> Could I just please clarify, since its been hard to follow the
> conversation, that having the style internal means that the prefetcher can
> still handle the images properly?

Also, we seem to be operating under the assumption that requiring in-page CSS is going to fly with implementors and/or authors. I can only speak to the latter being false, in my own case, but the former seems a little hard to believe.


> Thanks,
> Shane
> 
> On Fri, Nov 15, 2013 at 4:20 PM, Adam Barth <w3c at adambarth.com> wrote:
> 
>> 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
>>