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

[John Mellor]

On Sun, Nov 17, 2013 at 11:22 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> I can't speak for all WebKit developers or even all with an interest in
> this, but my thoughts are as follows:
>

Thanks for explaining your position Maciej.

The src-n proposal with the following changes seems likely reasonable:
> - In a single attribute (ideally named "srcset" to avoid gratuitous
> renaming) with || or some other separator
> - viewport-urls syntax removed or changed to be more human-understandable
>

Can I focus on the viewport-urls syntax for a moment?

Everything else (single attribute with ||s/multiple attributes/multiple
elements/split between inline CSS & HTML) is mainly just aesthetics. But
the viewport-urls syntax provides a crucial bit of functionality, and I'd
like to make sure people understand why it's so important.

It resolves the fundamental tension between what authors want, "chose image
source based on layout size", and what browser developers want, "don't
break the preload scanner", in the very common variable-sized images
(viewport-switching) case.

Satisfying both conditions requires the author to tell the browser's
preload scanner what the layout size of the image will be, in terms of the
viewport size (and/or fixed sizes). That's all viewport-urls does: you
express your layout image size as a CSS length (whose containing block is
the viewport, as if you'd used position:fixed). For example:
- 400px
- 33%  // equivalent to 33vw
- calc(50vw - 80px)  // flexible width with fixed padding

It doesn't need to be exact (it's ok if most authors don't bother with
calc), it just needs to approximate the layout image size such that the
browser can determine the closest matching source.

Finally, in cases where you have a nonlinear relationship between viewport
width and image width (primarily in responsive designs where the number of
columns changes due to a media query), you can provide a CSS length to
either side of the discontinuities, where the discontinuity is expressed as
a CSS min-width MQ, hence for a 1-3 column responsive grid you end up with
something like the "100% (640px) 50% (960px) 33%"
example<http://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/>you've
probably seen.

But again, while using this correctly will give you the optimal tradeoff
between page load performance and image quality, it's generally ok if the
long tail of websites don't bother dealing with the discontinuities, and
just provide a rough estimate of image size, e.g. they approximate "100%
(640px) 50% (960px) 33%" as simply "600px".

Finally, xanthir.com/b4Su0 explains why without viewport-urls, the markup
complexity balloons (as an author still has to figure out the relationship
between viewport width and layout image size, but then furthermore has to
do a bunch of maths and sprinkle the breakpoints above as subtle variations
in densities of the images they provide).

Does this all make sense? Hopefully that helped explain why viewport-urls
syntax (or something similar) is essential; but I'd definitely welcome
suggestions to make it more human-understandable. The CSS lengths seem
clear enough, but it's possible there's a better way of expressing the
breakpoints...

The latest style-based <img>/content proposal seems reasonable if the
> following issues could be addressed:
> - Always loads src per current browser behavior (might be fixable by
> omitting 'src' attribute).
> - Not obvious if preload scanning can reasonably be expected to resolve
> CSS selectors (hopefully parser/preloading experts can weigh in).
>
> I personally somewhat prefer the style-based proposal if the issues are
> addressed, as it has less surface syntax.
>
> It would probably also have to be combined with vanilla x-only srcset to
> do resolution scaling combined with art direction, without forcing sizes to
> be set explicitly.
>
> Regards,
> Maciej
>
>