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

[Shane Hudson]

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?

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
>