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

[Yoav Weiss]

>
>
> The hard part is deciding what to put in the optimized subset.  We
> already parse media queries in the preload scanner to find imported
> stylesheets to load.  We probably won't be able to support every media
> query under the sun, but we could support maybe min-width, min-height,
> and min-device-pixel-ratio (or whatever you think is best along these
> lines).
>

I'm pretty sure we could support every MQ here, either on the main thread
(as it's implemented now in Blink & WebKit) or inside the preloadScanner
itself, assuming a thread-safe CSS parser is available, which is something
we'd need anyway if we want the PreloadScanner to parse CSS.


> For selector matching, we wouldn't be able to support anything that
> needs to understand the structure of the tree (e.g., descendant
> selectors or sibling selectors).  I'd probably start with just single
> class and id selectors.
>
> In case it wasn't clear from the above, we wouldn't preload the image
> until we'd encountered the div with the appropriate class name.  When
> scanning that start tag token, we'd simulate CSS selector matching in
> the preload scanner to see if we've understood any rules that match.
>
> None of the above is all that difficult, and it's probably something
> we should do anyway to improve image preloading across the whole web.


I agree that such an optimization can improve loading of inline CSS
background images anyway.
OTOH, I'm not sure this is the right solution for content images.

On Tue, Nov 12, 2013 at 7:31 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Nov 12, 2013, at 9:50 AM, Adam Barth <w3c at adambarth.com> wrote:
>
>
> > We might even be able to make this work without inventing anything:
> >
> > <style type="text/css">
> > @media (min-width: 480px) {
> >  .artdirected {
> >    width: 30px;
> >    height: 30px;
> >    background-image: image-set(url(small.png) 1x, url(small-hires.png)
> 2x);
> > }
> > }
> > @media (min-width: 600px) {
> >  .artdirected {
> >    width: 60px;
> >    height: 60px;
> >    background-image: image-set(url(large.png) 1x, url(large-hires.png)
> 2x);
> > }
> > }
> > </style>
> > <div class="artdirected"></div>
> >
> > All the information is there.  We just need to teach the preload
> > scanner to parse a subset of CSS and match a subset of selectors.  If
> > you stay within the "preloadable" subset, then your images will be
> > loaded by the preload scanner.  Otherwise, they'll just be loaded
> > normally.
> >
> > What's most attractive to me about this approach is that it doesn't
> > require inventing anything new, which means the compatibility story
> > for older user agents is solid.  You don't need a polyfill or anything
> > like that.
>
> 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.

John's approach of splitting content & presentation seems better to me. It
enables to keep <img> semantic and maintain the variable resources in HTML.
I'm not sure it's better than src-N+custom MQs though.