[whatwg] Features for responsive Web design

[=?GB2312?Q?Kornel_Lesi=A8=BDski?=]

On 19 maj 2012, at 10:46, Matthew Wilcox <mail at matthewwilcox.com> wrote:

> 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.

iPhone knows when it's on GPRS/EDGE, so it can implement logic exactly as I've described it. 

What it doesn't know is exact numerical value representing current bandwidth and latency. 


> 
>> 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 point is UA can do whatever gives better experience. UAs can innovate in this area. For example phones know when they're on expensive roaming connection and always download lowest-res images, without needing authors to add (bandwidth-cost:expensive) MQ. 

>> 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?

Setting explicit filesize may be an option. With current spec UA can safely assume that 1x image is smaller than 2x. 

>>>> (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.

intrinsic size is the one you don't set. Size in <img width> or CSS width: overrides intrinsic size. 

>> 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.

That requires relatively large amount of effort ¡ª putting image sizes for all breakpoints in CSS, with same media queries, and ensuring you have unique selector for the image.

That's 5-10 lines of code for what you get with mere 2 characters in srcset. 

And when intrinsic size is usable you can use it for images with variable size (e.g. known width, but height dependent on aspect ratio of the image)

> 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.

That is true for devices which use zoom a lot, but may be suboptimal on desktops. 

> 
>>> 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.

Just throwing an idea here:

<img srcset="gravatar?s={grsize}">

<style>
@breakpoint "grsize":"80";

@media (max-width:320px) {
   @breakpoint "grsize":"40";
}
</style>

I'm not sure about using <style>, as it cannot work in external CSS (we can't ask UAs to wait).
However declaration may need more syntax than just <meta> to allow separate groups of breakpoints. 

> 
>> 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.

Scaling is awful for 96dpi displays. You may want to have floated images or buttons/banners at exact size. 

max-width is OK in many cases, but the solution would be limited if it were the only usable option. 

I believe 200dpi images will be more important in the future than 1x images, so no easy method to embed non-100%-wide highdpi image will be a pain for developers. 

-- 
> 

regards, Kornel