[whatwg] Features for responsive Web design

[Matthew Wilcox]

On 19 May 2012 00:37, Kornel Lesiński <kornel at geekhood.net> wrote:
> On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox <mail at matthewwilcox.com>
> wrote:
>
>>> <picture> in its current form is unable to support bandwidth-based
>>> negotiation well
>>
>>
>> By all accounts no solution proposed can do this. This is not a
>> <picture> only problem.
>
> srcset allows UA to pick any image density regardless of actual screen
> density, so e.g. Safari on iPhone 4 on GPRS/EDGE connection could download
> 1x images, instead of 2x.

Yes indeed, but the problem is not about srcset, <picture> or anything
else: it's that, as has been pointed out repeatedly to those of us
asking about bandwidth media queries, the browser simply can't do
reliable bandwidth detection. That effects srcset as much as anything
else. So while technically srcset allows for this, the browser itself
does't, so it can never be used in the manner you're describing.

> UAs are also free to download 1x image first, and then 2x image after
> onload, etc. Declarative nature of descriptors, as opposed to imperative
> MQs, allows UAs to innovate in this area and come up with new uses that
> authors didn't predict/express in MQ.

This would be no better than current JS approaches, in fact making it
worse by adding to the page load size rather than optimising it.

> The syntax allows addition of "KB" descriptor later, which — assuming UAs
> will figure out how to measure actual bandwidth well enough — will allow
> even more sophisticated selection based on file size (rather than only 1x/2x
> scale factors which are only a proxy for the file size).

As above; this seems set not to happen. Besides, how is it going to
know the file size unless you explicitly state it in the srcset
somewhere?

>>> (and that's not simply a matter of adding bandwidth media
>>> query) and has no mechanism to specify scaling factor for intrinsic sizes
>>> of images.
>>
>>
>> Not actually sure what "intrinsic sizes of images" means.
>
>
> A default size of the image when you don't specify any size in HTML/CSS.

Ah, OK thanks :) I do not ever set intrinsic sizes, and nor does any
site I have seen that is responsive in nature. Precisely because it
has no meaning or use in a responsive site.

> To take advantage of 200dpi displays you need to tell UA to render a X px
> image at X/2 CSS px. Explicit width/height breaks adaptive mechanism.

Or you do what we do now and supply a double resolution image and set
it to a given CSS size. Or just any old size, from my experience of
the iPad3 you don't actually need to be that specific, just get an
oversized image and let it shrink a bit and it holds up well.

>> I see no difference between the end result of either syntax. Both
>> approaches fail utterly in abstracting the query from the mark-up,
>> which means both approaches are suited only to individual images.
>
> True. An URI template can be added later to either solution.

I'd like to see idea's on how this might work.

> The current URI template proposal is limited. I've pointed out few cases for
> which a single global set of breakpoints is not sufficient. I'd be nice if
> you tried to extend the proposal to support those cases as well (e.g. {case}
> → {case:category} and define breakpoints per category such as 'sidebar',
> 'gravatar', etc.)

All solutions are limited. The more I work on this the more convinced
I am that the nature or HTML and the layout system makes any truly
efficient solution impossible.

I actually prefer the limits of <meta> than any others simply because
<meta> does not postpone the issues until a re-design. <meta> is the
one and only solution I have seen that does not in some way
contaminate the mark-up with values dependent on the current design.
The price for that is less efficient image compression.

I can't see how to extend it as you're suggesting without also falling
to the same "presentational properties embeded" problem that <picture>
and srcset fall into. And that to me is a no-go. We already have
srcset if that's the compromise we want to make.

> And <meta breakpoint> has same limitations for DPI adaptation as <source
> media>.
>
>>> There are two categories of use-cases ("art-directed" and
>>> "dpi/optimization") and <picture> is suited for only one of them, so
>>> please don't frame the decision as "discarding" of a perfectly good
>>> solution, as it wasn't.
>>
>>
>> Picture dealt with both of these by simple use of the pixel density
>> media query - i.e, in exactly the same way CSS already does it. I do
>> not understand your argument.
>
>
> <picture>
> <source src="200px" media="(min-device-pixel-ratio:2)">
> <source src="100px">
> </picture>
>
> This will only choose between large pixelated image and small pixelated
> image, and will not make use of high display density.

On it's own you're right. But no-one actually builds a site like that.
If you're doing a fluid responsive site you've got img {
max-width:100% } in there, and in that case you do actually take
advantage of the high DPI.

> I've explained it in more detail previously (using srcset as an example, but
> it all applies to min-device-pixel-ratio: MQ as well)
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036051.html
>
> --
> regards, Kornel Lesiński