Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)

On 6 February 2012 19:24, Irakli Nadareishvili wrote: > Boris, > > if you don't mind me saying it, I am afraid you may be missing the point of > this request. In Responsive Web Design, device capabilities are used in a > high-level fashion to determine a class of the device: smartphone, tablet,

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)

On Mon, Feb 6, 2012 at 9:24 PM, Irakli Nadareishvili wrote: > if you don't mind me saying it, I am afraid you may be missing the point of > this request. In Responsive Web Design, device capabilities are used in a > high-level fashion to determine a class of the device: smartphone, tablet, > de

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

On Wed, Feb 8, 2012 at 2:41 AM, Henri Sivonen wrote: > On Tue, Feb 7, 2012 at 11:17 PM, divya manian wrote: >> This is the info I would love to see any time for my app to make the >> kind of decision it should: >> * connection speed: so I know how fast my resources can load, how quickly. >> * ban

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

+1 to everything Jason Grigsby just said. If not here, where? If not with you, with who? We've been doing this publicly for months and months...

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

On Feb 8, 2012, at 8:04 AM, Ronjec Viktor wrote: > People, this is really getting out of hand... > > 1. WHATWG is a standards body, meaning it _standardizes_ solutions. > Everyone who followed the discussion up until now can easily tell that > currently there is no unified, or even close to comm

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

People, this is really getting out of hand... 1. WHATWG is a standards body, meaning it _standardizes_ solutions. Everyone who followed the discussion up until now can easily tell that currently there is no unified, or even close to common approach to this topic yet. Someone says the solution is o

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

On Tue, Feb 7, 2012 at 11:17 PM, divya manian wrote: > This is the info I would love to see any time for my app to make the > kind of decision it should: > * connection speed: so I know how fast my resources can load, how quickly. > * bandwidth caps: so I know I shouldn't be sending HD images. Ho

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

On 02/07/2012 10:19 PM, Charles Pritchard wrote: > On 2/7/2012 1:14 PM, Matthew Wilcox wrote: >>> > Also, I am writing this on a laptop via a throttled mobile >>> connection. >> It'd be nice if sites had the capability to adapt to that throttle >> then wouldn't it... > > As I read through this th

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

On Tue, Feb 7, 2012 at 4:13 PM, Matthew Wilcox wrote: > Ahhh, ok. I was not aware that SPDY is intended to suffer from the flaws > inflicted by the dated mechanics of HTTP. Is it really different semantics > though? I don't see how it's harmful to enable resource adaption over SPDY > just because

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

On Tue, 07 Feb 2012 21:17:22 -, divya manian wrote: This is the info I would love to see any time for my app to make the kind of decision it should: * connection speed: so I know how fast my resources can load, how quickly. * bandwidth caps: so I know I shouldn't be sending HD images.

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

On 2/7/12 5:06 PM, Matthew Wilcox wrote: 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 pixelati

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

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

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

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

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

On 2/7/12 3:59 PM, Matthew Wilcox wrote: Fair enough. This then becomes a cost/benefit issue. But there's nothing to stop this working if the user's default is an opt out and a prompt is given to allow. In exactly the same way that things currently work for geo-location data. Right? Maybe.

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

On 2/7/2012 1:21 PM, Matthew Wilcox wrote: Whether screen-size is a good idea or not comes after. 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. I

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

> > It's only an example. My point is that the server ought to be able to > ask the client for data about *any given property* and if the client > is capable it should send a header back. Which allows the server to > then do whatever it needs with the information. This approach makes sense to me

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

Yes, you're getting the point I'm trying to make :D However, there most certainly IS a use case for screen size. The designers would kill me if I served up images that had to be up-sampled to fit the device width. And I'd kill them if I had to send an image 6 times larger than needed just to cater

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

I think somehow lines are getting crossed and misunderstandings are happening. For what it's worth, everyone seems to be getting hung up on screen size. It's only an example. My point is that the server ought to be able to ask the client for data about *any given property* and if the client is ca

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

On 2/7/2012 1:14 PM, Matthew Wilcox wrote: > Also, I am writing this on a laptop via a throttled mobile connection. It'd be nice if sites had the capability to adapt to that throttle then wouldn't it... As I read through this thread -- all of these use cases are about bandwidth. a) Images ar

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

This is the info I would love to see any time for my app to make the kind of decision it should: * connection speed: so I know how fast my resources can load, how quickly. * bandwidth caps: so I know I shouldn't be sending HD images. * battery time: network requests are a drain on battery life, if

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

On 7 February 2012 20:05, Nils Dagsson Moskopp wrote: > Matthew Wilcox schrieb am Tue, 7 Feb 2012 > 19:38:31 +: > >> Can we not turn this into an option in the same way browsers handle >> requests to get the users location? With configuration too? >> >> Allow browsers to see my: >> >> screen

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

On 7 Feb 2012, at 20:19, Boris Zbarsky wrote: On 2/7/12 2:52 PM, Matthew Wilcox wrote: Reporting more information about the user's hardware and software to the server allows better fingerprinting and hence tracking. See https://www.eff.org/deeplinks/__2010/01/primer-information-__theory

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

On 2/7/2012 11:52 AM, Matthew Wilcox wrote: On 7 February 2012 17:59, Boris Zbarsky wrote: On 2/7/12 12:32 PM, Matthew Wilcox wrote: In what circumstances might this cause breakages? Whenever the server developer makes dumb assumptions. Which they do all the time. _All_ the time. And h

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

On 2/7/12 2:52 PM, Matthew Wilcox wrote: Reporting more information about the user's hardware and software to the server allows better fingerprinting and hence tracking. See https://www.eff.org/deeplinks/__2010/01/primer-information-__theory-and-privacy

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

Matthew Wilcox schrieb am Tue, 7 Feb 2012 19:38:31 +: > Can we not turn this into an option in the same way browsers handle > requests to get the users location? With configuration too? > > Allow browsers to see my: > > screen size That would be yet another way to push “This web site was d

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

Thanks again, you make some good points :) More responses inline... On 7 February 2012 17:59, Boris Zbarsky wrote: > On 2/7/12 12:32 PM, Matthew Wilcox wrote: > >>This is a case of browser vendors (or at least me with my browser >>implementor had on) thinking that sending this sort of i

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

Well given that the point you raise is about opting in and out, not about the capability of fingerprinting itself. Which as you say, already exists. Can we not turn this into an option in the same way browsers handle requests to get the users location? With configuration too? Allow browsers to se

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

On Tue, 07 Feb 2012 11:32:23 -0600, Matthew Wilcox wrote: , will cause their users to get more broken pages (which is what happens in many cases with browser sniffing right now), will lock new devices out of the market (which is what happens with new UA strings right now). And hence tha

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

On 2/7/12 12:34 PM, David Goss wrote: On 7 February 2012 17:11, Boris wrote: This is a case of browser vendors (or at least me with my browser implementor had on) thinking that sending this sort of information will hurt their users' privacy... Sorry if I'm missing something obvious, but how?

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

On 2/7/12 12:32 PM, Matthew Wilcox wrote: This is a case of browser vendors (or at least me with my browser implementor had on) thinking that sending this sort of information will hurt their users' privacy Can you clarify how this hurts privacy? I'm not sure how reporting back things

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

On 7 February 2012 17:11, Boris wrote: > This is a case of browser vendors (or at least me with my browser > implementor had on) thinking that sending this sort of information will > hurt their users' privacy... Sorry if I'm missing something obvious, but how? I don't think anyone's asking for th

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

Thanks for the feedback :) I've replied inline, but please be aware that I don't have a browser-vendor hat to put on so some of my questions may well be a bit naive (for which I apologise in advance) On 7 February 2012 17:11, Boris Zbarsky wrote: > On 2/7/12 9:13 AM, Matthew Wilcox wrote: > >>

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

On 2/7/12 4:28 AM, James Graham wrote: This basically amounts to "the requirements were wrong". Given the limited information I have so far, yes. Since the same developer made both the desktop and mobile frontends and he is one of the major users of the system, and the mobile frontend was pu

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

On 2/7/12 9:13 AM, Matthew Wilcox wrote: To be clear: this is a case of browser vendors deciding it's too expensive and therefor not allowing it to be implemented This is a case of browser vendors (or at least me with my browser implementor had on) thinking that sending this sort of informatio

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

I don't agree that it's a good idea to have to have the server query some massive device database in order to find out what the requesting device does and does not support. Device databases are, by their nature, going to be hard to maintain, hard to support, and not tell us all we need to know. How

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

On Tue, 07 Feb 2012 15:13:03 +0100, Matthew Wilcox wrote: Personally, I think the issue of adapting resources to client capabilities is here to stay. For sure, although the mechanisms might evolve. Devices of significantly varied size and performance are here to stay, Yes... and adapt

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

Then yes, I can get behind the idea of that such a communication method would be very useful. On Feb 7, 2012, at 4:55 AM, Matthew Wilcox wrote: > Absolutely agree that we should not be concentrating on one specific thing. > What I want is the ability to have the server ask for whatever info it

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

Ahhh, ok. I was not aware that SPDY is intended to suffer from the flaws inflicted by the dated mechanics of HTTP. Is it really different semantics though? I don't see how it's harmful to enable resource adaption over SPDY just because browser vendors have decided that HTTP is too expensive to do i

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

On Mon, Feb 6, 2012 at 5:52 PM, Matthew Wilcox wrote: > Also, as indicated, with SPDY this is much much less of a problem than for > HTTP. SPDY transfers the HTTP semantics more efficiently when supported. You aren't supposed to communicate different semantics depending on whether SPDY is enable

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

On 7 February 2012 00:12, Jason Grigsby wrote: > I agree that this is a problem. I’ve spent far too much time trying to > find solutions for images in responsive designs and none that I reviewed > work. (research at http://cloudfour.com/responsive-imgs-part-2). > Seconded, my work has been http:

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

Can I suggest you read http://24ways.org/2011/adaptive-images-for-responsive-designs-again then please? It does not work "fine" at all. Cheers, -Matt On 6 February 2012 20:23, Charles Pritchard wrote: > Scripting on the client side works just fine. It's pure markup situations > where you run i

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

On 02/06/2012 11:05 PM, Boris Zbarsky wrote: On 2/6/12 3:20 PM, James Graham wrote: 1) Same URL structure as the main site OK, makes sense. 2) Less (only citical) information on each screen Why not do this for the "desktop" version as well? Alternately, if it's nice to see the information

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

I agree that this is a problem. I’ve spent far too much time trying to find solutions for images in responsive designs and none that I reviewed work. (research at http://cloudfour.com/responsive-imgs-part-2). But I find the arguments that Henri Sivonen made against putting the information in th

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

On Mon, 06 Feb 2012 20:08:05 -, Matthew Wilcox wrote: On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote: 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 m

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

On Mon, 06 Feb 2012 19:49:43 -, Boris Zbarsky wrote: 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 [the] former half. Not without script. Or (fragment) Accept-Ranges (so a mobile device could

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)

2012/2/6 Kornel Lesiński > On Mon, 06 Feb 2012 20:00:45 -, Irakli Nadareishvili > wrote: > > 1. Adaptive images: >> To optimize user-experience on smart-phones (most of which have >> relatively small screens, and are on slow connections most of the time) >> > > Be careful with generalizatio

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)

On 2/6/12 5:21 PM, Ashley Sheridan wrote: I can't remember where right now, but I do recall seeing an article which said that it was a common misconception that mobile devices were most often on a slow connection. Personally, I tend to make most use of my mobile for browsing when I'm on a wireles

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)

On Mon, 2012-02-06 at 22:16 +, Kornel Lesiński wrote: > On Mon, 06 Feb 2012 20:00:45 -, Irakli Nadareishvili > wrote: > > > 1. Adaptive images: > > To optimize user-experience on smart-phones (most of which have > > relatively small screens, and are on slow connections most of the ti

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)

On Mon, 06 Feb 2012 20:00:45 -, Irakli Nadareishvili wrote: 1. Adaptive images: To optimize user-experience on smart-phones (most of which have relatively small screens, and are on slow connections most of the time) Be careful with generalizations like that. Mobile devices can be con

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

On 2/6/12 3:20 PM, James Graham wrote: 1) Same URL structure as the main site OK, makes sense. 2) Less (only citical) information on each screen Why not do this for the "desktop" version as well? Alternately, if it's nice to see the information at a glance on desktop, why not make the UI

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

On 2/6/12 3:10 PM, Matthew Wilcox wrote: On 6 Feb 2012, at 18:58, 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* capabilitie

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)

On 2/6/12 3:00 PM, Irakli Nadareishvili wrote: 1. Adaptive images: To optimize user-experience on smart-phones (most of which have relatively small screens, and are on slow connections most of the time) we need to send lower-resolution or resized versions of high-resolution images that would be

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

On Feb 6, 2012, at 12:20 PM, James Graham wrote: > 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 mos

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

Scripting on the client side works just fine. It's pure markup situations where you run into problems. I'm well aware that Image nodes are alive. I'm keeping an eye out on the DOMParser method to see if they're alive when it parses as text/html. I recently wrapped some noscript tags around HTML

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

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 vers

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

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 wrote: > On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote: > > > On Mon, 06 Feb 2012 18:58:

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

On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote: > On Mon, 06 Feb 2012 18:58:00 -, Boris Zbarsky 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.

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

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

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

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

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

On Mon, Feb 6, 2012 at 11:08 AM, Ashley Sheridan 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

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

On Feb 6, 2012, at 11:49 AM, Boris Zbarsky wrote: > On 2/6/12 2:26 PM, Bjartur Thorlacius wrote: >> On Mon, 06 Feb 2012 18:59:14 -, Boris Zbarsky wrote: >>> That really depends on what the application is doing. Depending on >>> input capabilities, you may want to have multiple pages instead

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)

Boris, fair enough. Two use-cases off of my head that do not currently have a non-ugly solution and could if browsers reported device class: 1. Adaptive images: To optimize user-experience on smart-phones (most of which have relatively small screens, and are on slow connections most of the ti

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

On 2/6/12 2:26 PM, Bjartur Thorlacius wrote: On Mon, 06 Feb 2012 18:59:14 -, Boris Zbarsky 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 exa

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)

On 2/6/12 2:24 PM, Irakli Nadareishvili wrote: if you don't mind me saying it, I am afraid you may be missing the point of this request. I certainly hope I am! What I understood the request to be doesn't make any sense. In Responsive Web Design, device capabilities are used in a high-leve

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

On Mon, 06 Feb 2012 18:59:14 -, Boris Zbarsky 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

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)

Boris, if you don't mind me saying it, I am afraid you may be missing the point of this request. In Responsive Web Design, device capabilities are used in a high-level fashion to determine a class of the device: smartphone, tablet, desktop. There is no need for exact viewport state. All the ima

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

On Mon, 06 Feb 2012 13:49:35 -, Matthew Wilcox 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

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

On Mon, 06 Feb 2012 18:58:00 -, Boris Zbarsky 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 co

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

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 -, Boris Zbarsky wrote: > >> Yes, indeed. "Supports touch input on multiple spots at once" vs > >> "supports only a mouse" seems like a much more important d

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

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

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

On 2/6/12 1:55 PM, Bjartur Thorlacius wrote: On Mon, 06 Feb 2012 17:44:30 -, Boris Zbarsky 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

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

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 widt

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

On Mon, 06 Feb 2012 17:44:30 -, Boris Zbarsky 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 ex

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

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 mu

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

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

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

On Mon, 06 Feb 2012 18:33:56 +0100, Ryosuke Niwa wrote: On Feb 6, 2012 9:04 AM, "Boris Zbarsky" 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 HD

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

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

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

James Graham schrieb am Mon, 06 Feb 2012 17:42:16 +0100: > […] > A typical thing that people want to do is to deliver and display > *less* content in small (measured in arcseconds) screen scenarios. If > you are only going to show a subset of the full content it would be > nice to only do a subs

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

On Feb 6, 2012 9:04 AM, "Boris Zbarsky" wrote: > > On 2/6/12 11:42 AM, James Graham wrote: >> >> No, but there is a different *typical* screen size/resolution for >> mobile/tablet/desktop/tv and it is common to deliver different content >> in each of these scenarios. Although people could load the

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

On Mon, Feb 6, 2012 at 9:52 AM, Matthew Wilcox wrote: > I agree that headers are expensive. But are they expensive compared to a > few hundred kilobytes of saved bandwidth because we were able > to successfully negotiate content? Yes. The problem is the word "we". Everyone in the world has to

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

On 2/6/12 11:42 AM, James Graham wrote: No, but there is a different *typical* screen size/resolution for mobile/tablet/desktop/tv and it is common to deliver different content in each of these scenarios. Although people could load the same site on desktop and mobile set up to have the same viewp

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

On 2/6/12 11:27 AM, Matthew Wilcox wrote: I disagree. Screen size is at times *exactly* what is needed, as it *is* constant throughout the experience. No. It's just not, for at least two reasons: 1) Screen sizes are reported to the page in CSS pixels, and the number of CSS pixels per device

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

Matthew Wilcox schrieb am Mon, 6 Feb 2012 16:27:29 +: > I disagree. Screen size is at times *exactly* what is needed, as it > *is* constant throughout the experience. Do you ever use projectors or change monitors? Because I do. -- Nils Dagsson Moskopp // erlehmann

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

On Mon 06 Feb 2012 05:00:55 PM CET, Boris Zbarsky wrote: On 2/6/12 10:52 AM, Matthew Wilcox wrote: 1) client asks for spdy://website.com 2) server responds with content and adds a "request bandwidth& device screen size header" Again, the "screen size" is not invariant during the lifetime of a

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

I disagree. Screen size is at times *exactly* what is needed, as it *is* constant throughout the experience. *Viewport* size is what we shouldn't be using. I've ran up against this with Adaptive Images ( http://adaptive-images.com ) - which is all about the use case of supplying appropriate images

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

On 2/6/12 10:52 AM, Matthew Wilcox wrote: 1) client asks for spdy://website.com 2) server responds with content and adds a "request bandwidth& device screen size header" Again, the "screen size" is not invariant during the lifetime of a page. We should not be encouraging people to think that

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

The server can not rely on client side *anything* with resource negotiation. This is because clients now pre-fetch resources; as soon as the node exists the resource is requested - before any script has had a chance to run or cookies have been set. It's a tripping point that Filament Group have wri

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

On Mon, 06 Feb 2012 14:50:03 +0100, Matthew Wilcox wrote: I've asked Bruce Lawson (one of the Opera boys) about this, and it's not likely to happen with HTTP. However, SPDY compresses headers as well as multiplexes, and it's a much more realistic request to get useful headers sent over a SPDY c

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

On 2/4/12 5:57 PM, Bjartur Thorlacius wrote: Do make note of the dynamic nature of many viewports* and the fact that user agents may wish to render resources to multiple medias. The latter is rare enough to tolerate an extra roundtrip. Actually, printing an already-loaded page typically can't t

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

On 2/4/12 2:28 PM, irakli wrote: Something as simple as if browsers passed along device's width/height information This information can change between page load and page unload (and in fact, it can change between the HTTP request being sent and the HTTP response being received). All passing

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

On Sat, 04 Feb 2012 19:28:17 -, irakli wrote: The most optimal way to handle responsive images and optimize CSS/JS would be on the server-side. However, server-side does not have enough information about device capabilities, resulting in emergence of all kinds of cruft-y solutions (e.g.

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

Feel free to propose e.g. Accept-Media to httpbis[1]. Bandwidth negotiation would be most useful. Do make note of the dynamic nature of many viewports* and the fact that user agents may wish to render resources to multiple medias. The latter is rare enough to tolerate an extra roundtrip. Resiz

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

On 2/4/12 11:28 AM, irakli wrote: We have some significant obstacles on the path of fully optimized Responsive Web Design, however. Responsive Images (smaller images for smaller screens to optimize download times) and optimized CSS/JS (mobile devices don't need the same JS/CSS as desktop browsers