[whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Charles Pritchard]

On 2/7/2012 2:06 PM, Matthew Wilcox wrote:
>>>> And, screen size is useful when understood to mean "CSS Pixels".
>>>> Because that's what a browser renders. If a device has a screen 1900px
>>>> CSS px wide, you know you never need send anything larger.
>>> It's getting in the way, and it's certainly been a strong topic.
>> I know that if a screen is 480px wide that I know nothing. I spent a lot of time on work-arounds for DPI issues on mobile and desktop.
> I agree about this. But realise that if we take your zoom use case to
> it's logical conclusion, we'd need to supply images at an infinite
> resolution. Which is patently absurd. With visual media, it is
> expected, and the only practical thing, to have pixelation at zooms
> higher than one CSS pixel.

The logical conclusion is that images are supplied at the highest 
resolution the author sees fit.
It's common to make that a 2x CSS pixel ratio.

Works well for density on items like the iPhone.


>> Unless you go out and disable zoom, the user can zoom into the image. That applies to mobile for sure. I hate it when I can't zoom in on some sites. Google news is a prime example.
> I would never disable zoom, it's completely irresponsible. But so is
> trying to supply an image that stands up to zoom. It's irresponsible
> to every other user who doesn't zoom.

Well, I can script things, with javascript. But sure, in CSS it's not 
nice to waste someone's bandwidth.
Nor is it nice to cripple their computer by having it download dozens of 
huge images.

Thumbnailing is really what happens here. Tiling and thumbnailing. 
Common practices.

You're aiming too low on your mobile thumbnails. It's great on a 
resource-constrained pipe, or for a phone that has a 1:1 dpi ratio,
it's not nearly as nice on an iPhone sitting on an unmetered 3G connection.


>> But I'll try to bend my mind around it, now that we're over the initial hurdle about screen size.
>> Sure, if you want to have something like this, it's not the end of the world:
>> <style server="viewport-width, media, min-width" src="http://server.com/dynamic.css">
>> That'd result in some kind of header when requesting that style sheet.
> CSS already has methods for this. We are not talking about CSS. We are
> talking about HTML, which has no methods for this.

CSS is the method for HTML to do this work. If we're talking about HTML, 
we're talking about semantics like <article> and <nav>.


>> It could be used for really nasty purposes if it automatically updated.
>> Such as, if you set set "width", it might re-request the CSS file every time the user resizes the browser.
> This use case was considered and worked around when I developerd
> http://adaptive-images.com - it is precisely and exactly why that
> solution sends images at the maximum size the device can output to
> it's screen, rather than the size of the current viewport.

And by that you mean "the maximum size" at the standard zoom level.

We've got two issues floating here. I'd like to treat them as such. One 
of them is bandwidth preservation. I'm fine using server headers for 
that on various elements.

The other one is just sending CSS media values to the server, so they 
can be processed there instead of processed in CSS media selectors, for 
the purpose of limiting unnecessary fetches based on the CSS results.

Does that sound about right?

If you're solely trying to do <img src="myThumbnailer.php" />, I think 
you're overdoing it.

-Charles