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

[Boris Zbarsky]

On 2/6/12 12:33 PM, Ryosuke Niwa wrote:
> This might be a valid use case for a device capability API since
> different devices may have completely different platform conventions for
> UI and workflow such that using the same UI as the one served for
> desktop computers isn't desirable.

Yes, indeed.  "Supports touch input on multiple spots at once" vs
"supports only a mouse" seems like a much more important distinction
than the nominal CSS pixel size of the screen....

-Boris

[Charles McCathieNevile-2]

On Mon, 06 Feb 2012 18:33:56 +0100, Ryosuke Niwa <rniwa@...> wrote:

> On Feb 6, 2012 9:04 AM, "Boris Zbarsky" <bzbarsky@...> wrote:
...
>> This assumes that the entire page is onscreen at once, which is a pretty
> bad assumption for said scenarios.
...
> I agree with Boris' points. Some high-end smart phones already have HDMI
> outputs. Maybe people would start "docking" those devices to replace  
> laptop computers in near future.

Actually I do this already with my tablet - the idea is so my elderly  
family
can see it on the TV and we can use it together, and so they can learn to
use it on their own.

>> Sure.  I'm not entirely sure how sympathetic I am to the need to produce
>> "reduced-functionality" pages...  The examples I've encountered have  
>> mostly been in one of three buckets:
>>
>> 1) "Why isn't the desktop version just like this vastly better mobile
>> one?"
>> 2) "The mobile version has a completely different workflow necessitating
>> a different url structure, not just different images and CSS"
>
> This might be a valid use case for a device capability API since  
> different devices may have completely different platform conventions for
> UI and workflow such that using the same UI as the one served for desktop
> computers isn't desirable.

Yep. TV for example. (I'm still sympathetic to Boris' point that most often
the developer does a terrible job of this, but that's why I can choose to
use someone else's services instead of trying to tell all developers they
can only make things the way I like them).

cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

[Boris Zbarsky]

On 2/6/12 12:45 PM, Charles McCathieNevile wrote:
>> This might be a valid use case for a device capability API since
>> different devices may have completely different platform conventions for
>> UI and workflow such that using the same UI as the one served for desktop
>> computers isn't desirable.
>
> Yep. TV for example. (I'm still sympathetic to Boris' point that most often
> the developer does a terrible job of this, but that's why I can choose to
> use someone else's services instead of trying to tell all developers they
> can only make things the way I like them).

For what it's worth, I wasn't claiming that developers do a terrible job
of this.  In the cases when people actually do it, they do a reasonable
job.  It's just really hard to do, so most people don't really bother,
which makes total sense to me.

-Boris

[irakli-3]

Many thanks to everybody who has responded and for a lively and a productive discussion!

Quick clarification: the proposal is to include *device* capabilities in the HTTP headers, so when we say "screen width and height" we mean device screen width and height which is constant (but can have multiple values: for portrait and landscape).

There's no proposal or even need to capture user resizing a window and consequent change in viewport size. That is a completely different discussion.

Thank you

Irakli

[Bjartur Thorlacius]

On Mon, 06 Feb 2012 17:44:30 -0000, Boris Zbarsky <bzbarsky@...> wrote:
> Yes, indeed.  "Supports touch input on multiple spots at once" vs  
> "supports only a mouse" seems like a much more important distinction  
> than the nominal CSS pixel size of the screen....
>
I think CSS media queries could be extended to express multitouch  
capabilities. I don't think that would be useful for documents, but it  
could allow for per-device reimplementation of zoom and scroll. I'll leave  
deciding whether that's a fair use case to others. But that still doesn't  
warrant requesting different content.
--
-,Bjartur

[Boris Zbarsky]

On 2/6/12 1:55 PM, Irakli Nadareishvili wrote:
> Many thanks to everybody who has responded and for a lively and a productive discussion!
>
> Quick clarification: the proposal is to include *device* capabilities in the HTTP headers, so when we say "screen width and height" we mean device screen width and height which is constant

Again, it's not constant in the terms that the page sees, which are CSS
pixels, not device pixels.

-Boris

[Boris Zbarsky]

On 2/6/12 1:55 PM, Bjartur Thorlacius wrote:
> On Mon, 06 Feb 2012 17:44:30 -0000, Boris Zbarsky <bzbarsky@...> wrote:
>> Yes, indeed. "Supports touch input on multiple spots at once" vs
>> "supports only a mouse" seems like a much more important distinction
>> than the nominal CSS pixel size of the screen....
>>
> I think CSS media queries could be extended to express multitouch
> capabilities. I don't think that would be useful for documents

Sure.  It would be useful for applications.

> But that still
> doesn't warrant requesting different content.

That really depends on what the application is doing.  Depending on
input capabilities, you may want to have multiple pages instead of a
single page for some sort of configuration setup, for example.

-Boris

[Ashley Sheridan-3]

On Mon, 2012-02-06 at 13:58 -0500, Boris Zbarsky wrote:

> On 2/6/12 1:55 PM, Irakli Nadareishvili wrote:
> > Many thanks to everybody who has responded and for a lively and a productive discussion!
> >
> > Quick clarification: the proposal is to include *device* capabilities in the HTTP headers, so when we say "screen width and height" we mean device screen width and height which is constant
>
> Again, it's not constant in the terms that the page sees, which are CSS
> pixels, not device pixels.
>
> -Boris


I think the idea of some device capabilities is useful, like the
multi-touch capability of certain devices browsers (i.e. iPad, Firefox4
+, etc) but the ways in which code gets written to take advantage of
these very separate devices it isn't that much of a leap to sniff the
capabilities and use some clever CSS/Javascript to tailor the content
appearance and behaviour to suit the environment it's used in.

I agree with others on the list who've said that sending across
resolution (of any kind, be it actual, available or other) is the wrong
approach, and it will lead to browsers intentionally sending the wrong
information just to get the content they think they want.

--
Thanks,
Ash
http://www.ashleysheridan.co.uk

[Ashley Sheridan-3]

On Mon, 2012-02-06 at 13:59 -0500, Boris Zbarsky wrote:

> On 2/6/12 1:55 PM, Bjartur Thorlacius wrote:
> > On Mon, 06 Feb 2012 17:44:30 -0000, Boris Zbarsky <bzbarsky@...> wrote:
> >> Yes, indeed. "Supports touch input on multiple spots at once" vs
> >> "supports only a mouse" seems like a much more important distinction
> >> than the nominal CSS pixel size of the screen....
> >>
> > I think CSS media queries could be extended to express multitouch
> > capabilities. I don't think that would be useful for documents
>
> Sure.  It would be useful for applications.
>
> > But that still
> > doesn't warrant requesting different content.
>
> That really depends on what the application is doing.  Depending on
> input capabilities, you may want to have multiple pages instead of a
> single page for some sort of configuration setup, for example.
>
> -Boris

That makes sense to me, I hadn't thought about it like that before.

--
Thanks,
Ash
http://www.ashleysheridan.co.uk

[Bjartur Thorlacius]

On Mon, 06 Feb 2012 18:58:00 -0000, Boris Zbarsky <bzbarsky@...> wrote:
> Again, it's not constant in the terms that the page sees, which are CSS  
> pixels, not device pixels.
>
We're discussing HTTP here, so the content might just as well be raster  
bitmaps.

Multiple and variable screen dimensions are quite common (in special for  
projection). That means a request for every screen the resource may be.  
For legacy HTTP servers that don't support the new and complicated  
If-Different-For-Device header that would have to be added would serve the  
same content once for every screen.

So you have UAs sending extra headers with every request, making extra  
requests with even more extra headers in the fairly common case of  
variable screen dimensions (multiple screens) and either extra response  
headers for servers that use the feature (perfectly acceptable) and double  
round-trip lag (probably terrible) while the UA waits for the extra  
response header to check if there are alternative versions of the resource  
for differently sized screens and fetches the alternative version if there  
is one, or redundant fetching of *all* resources in proportion to the  
number of possible screen dimensions (assuming the best case of screen  
dimension being the only variable).

This is frightening in so many ways. You're better off discussing some of  
the details on httpbis though, in special if you intend to propose this  
formally to the Internet Engineering Task Force. When bandwidth savings  
are more important than download speed, and for tremendous size deltas  
(such as for heavy graphics with available downsamples), please consider  
HTTP 300 Multiple Choices client side negotiation and linking to multiple  
representations of the same resource.
--
-,Bjartur

[Bjartur Thorlacius]

On Mon, 06 Feb 2012 13:49:35 -0000, Matthew Wilcox  
<mail@...> wrote:
> We need the server to know about the device. We need headers.
We need renderings tailored to our devices. Device tailoring is best done  
by someone with access to the device in question. Judging how rendering is  
best done is up to the user, who should most of the time accept whatever  
default the device manufacturer (or whoever writes software for said  
device or class of devices) suggests.

We need servers to serve content.
--
-,Bjartur

[Bjartur Thorlacius]

On Mon, 06 Feb 2012 18:59:14 -0000, Boris Zbarsky <bzbarsky@...> wrote:
> That really depends on what the application is doing.  Depending on  
> input capabilities, you may want to have multiple pages instead of a  
> single page for some sort of configuration setup, for example.
>
Whether to use monolithic forms or paginated wizards is a presentation  
thing, that need not even have anything to do with HTTP. You can fetch  
half the monolithic form and fetch the rest when the user has filled in  
most of former half. Or you could fetch a whole form and paginate it.
--
-,Bjartur

[Boris Zbarsky]

On 2/6/12 2:26 PM, Bjartur Thorlacius wrote:
> On Mon, 06 Feb 2012 18:59:14 -0000, Boris Zbarsky <bzbarsky@...> wrote:
>> That really depends on what the application is doing. Depending on
>> input capabilities, you may want to have multiple pages instead of a
>> single page for some sort of configuration setup, for example.
>>
> Whether to use monolithic forms or paginated wizards is a presentation
> thing

Not on the HTML level.  Not if you want to allow useful non-scripted
semantic submission of partially-filled-in info in the paginated case.

> that need not even have anything to do with HTTP. You can fetch
> half the monolithic form and fetch the rest when the user has filled in
> most of former half.

Not without script.

-Boris

[Charles Pritchard-2]

On Feb 6, 2012, at 11:49 AM, Boris Zbarsky <bzbarsky@...> wrote:

> On 2/6/12 2:26 PM, Bjartur Thorlacius wrote:
>> On Mon, 06 Feb 2012 18:59:14 -0000, Boris Zbarsky <bzbarsky@...> wrote:
>>> That really depends on what the application is doing. Depending on
>>> input capabilities, you may want to have multiple pages instead of a
>>> single page for some sort of configuration setup, for example.
>>>
>> Whether to use monolithic forms or paginated wizards is a presentation
>> thing
>
> Not on the HTML level.  Not if you want to allow useful non-scripted semantic submission of partially-filled-in info in the paginated case.
>
>> that need not even have anything to do with HTTP. You can fetch
>> half the monolithic form and fetch the rest when the user has filled in
>> most of former half.
>
> Not without script.

I really didn't like the consequences of server-side scripting to manage dependencies. It was always more work than simply doing the scripting in the client side. It was more prone to error. It let our coders get away with less rugged design.

I'm in the responsive and universal design camp. I'm in the accessibility camp. At present, it does require scripting. I'm building web apps, so, scripting comes with that territory.


It seems to me like these folk are looking for <iframe defer> and <style defer> and some sort of media selector for the network information API, to minimize bandwidth on metered connections without needing to use scripting to do that work.

I'm interested in seeing a solution here. I do not think server-side management is the right one.


-Charles

[Ryosuke Niwa-2]

On Mon, Feb 6, 2012 at 11:08 AM, Ashley Sheridan
<ash@...>wrote:
>
> I think the idea of some device capabilities is useful, like the
> multi-touch capability of certain devices browsers (i.e. iPad, Firefox4
> +, etc) but the ways in which code gets written to take advantage of
> these very separate devices it isn't that much of a leap to sniff the
> capabilities and use some clever CSS/Javascript to tailor the content
> appearance and behaviour to suit the environment it's used in.
>

Right. On the other hand, the distinction between tablets and actual PCs
are getting blurry each day. e.g. I used Fujitsu P1510 throughout my
college to take notes during classes. It had 8.9" screen was fully capable
of running Windows XP and Vista to some extent.

But browsing regular websites on that machine was somewhat painful due to
most websites assuming every desktop computer to have at least XVGA or
above. I suspect I might have had a better UX if I could choose to view
tablet-version of websites on my laptop instead (there were iPad back then).

I agree with others on the list who've said that sending across
> resolution (of any kind, be it actual, available or other) is the wrong
> approach, and it will lead to browsers intentionally sending the wrong
> information just to get the content they think they want.
>

While I do agree with this statement, I have to admit that there are cases
where the screen resolution of a device gives a better hint on how to
layout your website than the type of the device.

- Ryosuke

[Matthew Wilcox-5]

>
> Scripting on the client side for the purposes of content negotiation *does
> not work*
>
Please, understand this. Because browsers pre-fetch as soon as a node is
> created there can be no client-side solution to this issue with the current
> HTML/JS specifications and browser behaviour. The image linked in the HTML
> is *always* requested, and it is requested before the client can do a
> damned thing about it.
>

>
> On 6 Feb 2012, at 20:03, Charles Pritchard wrote:
>
> > On Feb 6, 2012, at 11:49 AM, Boris Zbarsky <bzbarsky@...> wrote:
> >
> >> On 2/6/12 2:26 PM, Bjartur Thorlacius wrote:
> >>> On Mon, 06 Feb 2012 18:59:14 -0000, Boris Zbarsky <bzbarsky@...>
> wrote:
> >>>> That really depends on what the application is doing. Depending on
> >>>> input capabilities, you may want to have multiple pages instead of a
> >>>> single page for some sort of configuration setup, for example.
> >>>>
> >>> Whether to use monolithic forms or paginated wizards is a presentation
> >>> thing
> >>
> >> Not on the HTML level.  Not if you want to allow useful non-scripted
> semantic submission of partially-filled-in info in the paginated case.
> >>
> >>> that need not even have anything to do with HTTP. You can fetch
> >>> half the monolithic form and fetch the rest when the user has filled in
> >>> most of former half.
> >>
> >> Not without script.
> >
> >
> > I really didn't like the consequences of server-side scripting to manage
> dependencies. It was always more work than simply doing the scripting in
> the client side. It was more prone to error. It let our coders get away
> with less rugged design.
> >
> > I'm in the responsive and universal design camp. I'm in the
> accessibility camp. At present, it does require scripting. I'm building web
> apps, so, scripting comes with that territory.
> >
> >
> > It seems to me like these folk are looking for <iframe defer> and <style
> defer> and some sort of media selector for the network information API, to
> minimize bandwidth on metered connections without needing to use scripting
> to do that work.
> >
> > I'm interested in seeing a solution here. I do not think server-side
> management is the right one.
> >
> >
> > -Charles
> >
>
>

[Matthew Wilcox-5]

> On 2/6/12 1:55 PM, Irakli Nadareishvili wrote:
>> Many thanks to everybody who has responded and for a lively and a
productive discussion!
>>
>> Quick clarification: the proposal is to include *device* capabilities in
the HTTP headers, so when we say "screen width and height" we mean device
screen width and height which is constant
>
> Again, it's not constant in the terms that the page sees, which are CSS
pixels, not device pixels.

Media queries and explicit widths make this statement false, in a practical
way. We adjust for physical pixels quite happily by specifying a width on
the image. This is done routinely in all responsive designs simply by virtu
of the images having a width of 100%. They're then down sampled into
physical pixels even though CSS is using CSS pixels.

[Matthew Wilcox-5]

On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote:

> On Mon, 06 Feb 2012 18:58:00 -0000, Boris Zbarsky <bzbarsky@...>
wrote:
>> Again, it's not constant in the terms that the page sees, which are CSS
pixels, not device pixels.
>>
> We're discussing HTTP here, so the content might just as well be raster
bitmaps.

Are we? Why, what makes HTTP the relevant factor? SPDY is the future and
already supported in two major browsers., As it compresses headers and
multiplexes, I don't see the issue.

> Multiple and variable screen dimensions are quite common (in special for
projection). That means a request for every screen the resource may be. For
legacy HTTP servers that don't support the new and complicated
If-Different-For-Device header that would have to be added would serve the
same content once for every screen.

No, it means we as a standards body define which gets sent. The sensible
thing is to send the maximum screen size in use on the device.

> So you have UAs sending extra headers with every request, making extra
requests with even more extra headers in the fairly common case of variable
screen dimensions (multiple screens) and either extra response headers for
servers that use the feature (perfectly acceptable) and double round-trip
lag (probably terrible) while the UA waits for the extra response header to
check if there are alternative versions of the resource for differently
sized screens and fetches the alternative version if there is one, or
redundant fetching of *all* resources in proportion to the number of
possible screen dimensions (assuming the best case of screen dimension
being the only variable).

Again, read the proposition I mentioned and you'll find non of this is
true. Extra headers would only be sent by the browser if the browser
received a request for the client to send those headers.

[Matthew Wilcox-5]

PS, sorry all if some mails here are duplicates. I am fighting my mail
client which keeps sending mail from the wrong account, which is then
rejected by the list.

On 6 February 2012 20:17, Matthew Wilcox <mail@...> wrote:

> On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote:
>
> > On Mon, 06 Feb 2012 18:58:00 -0000, Boris Zbarsky <bzbarsky@...>
> wrote:
> >> Again, it's not constant in the terms that the page sees, which are CSS
> pixels, not device pixels.
> >>
> > We're discussing HTTP here, so the content might just as well be raster
> bitmaps.
>
> Are we? Why, what makes HTTP the relevant factor? SPDY is the future and
> already supported in two major browsers., As it compresses headers and
> multiplexes, I don't see the issue.
>
> > Multiple and variable screen dimensions are quite common (in special for
> projection). That means a request for every screen the resource may be. For
> legacy HTTP servers that don't support the new and complicated
> If-Different-For-Device header that would have to be added would serve the
> same content once for every screen.
>
> No, it means we as a standards body define which gets sent. The sensible
> thing is to send the maximum screen size in use on the device.
>
> > So you have UAs sending extra headers with every request, making extra
> requests with even more extra headers in the fairly common case of variable
> screen dimensions (multiple screens) and either extra response headers for
> servers that use the feature (perfectly acceptable) and double round-trip
> lag (probably terrible) while the UA waits for the extra response header to
> check if there are alternative versions of the resource for differently
> sized screens and fetches the alternative version if there is one, or
> redundant fetching of *all* resources in proportion to the number of
> possible screen dimensions (assuming the best case of screen dimension
> being the only variable).
>
> Again, read the proposition I mentioned and you'll find non of this is
> true. Extra headers would only be sent by the browser if the browser
> received a request for the client to send those headers.
>

[James Graham-7]

On Mon, 6 Feb 2012, Boris Zbarsky wrote:

> On 2/6/12 11:42 AM, James Graham wrote:

> Sure.  I'm not entirely sure how sympathetic I am to the need to produce
> "reduced-functionality" pages...  The examples I've encountered have mostly
> been in one of three buckets:
>
> 1) "Why isn't the desktop version just like this vastly better mobile one?"
> 2) "The mobile version has a completely different workflow necessitating a
> different url structure, not just different images and CSS"
> 3) "We'll randomly lock you out of features even though your browser and
> device can handle them just fine"

The example I had in mind was one of our developers who was hacking
an internal tool so that he could use it efficiently on his phone.

AFAICT his requirements were:
1) Same URL structure as the main site
2) Less (only citical) information on each screen
3) No looking up / transfering information that would later be thrown away
4) Fast => No extra round trip to report device properties

AFAIK he finally decided to UA sniff Opera mobile. Which is pretty sucky
even for an intranet app. But I didn't really have a better story to
offer him. It would be nice to address this kind of use case somehow.