subject:"\[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 ch...@jumis.com wrote:

 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 image nodes to prevent
 them from blocking my onload. Works fine.


 -Charles



 On Feb 6, 2012, at 12:16 PM, Matthew Wilcox m...@matthewwilcox.com
 wrote:

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

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

On 7 February 2012 00:12, Jason Grigsby ja...@cloudfour.com 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://adaptive-images.com


 But I find the arguments that Henri Sivonen made against putting the
 information in the header to be compelling:

 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034642.html




 FWIW, there was an RFC back in 1996 describing a similar request:
 http://tools.ietf.org/html/draft-mutz-http-attributes-01

 Personally, I’d rather see a new element or a new image format a la the
 add html-attribute for 'responsive images' thread going on right now. Or
 if it is headers, I’d like to see something that is more inclusive and
 could be used for servers requesting different information instead of
 codifying something only for screen size.


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
needs about the client device/environment, and have that sent as a header.
And only sent if the server has asked. I don't mean we want screen size
alone, that is but one example of something the server might care about.
Bandwidth is another, as is viewport size, and I am sure there are a lot
more. I want to see a *communication method* defined here, not a one-issue
semi-solution to an overly specific example of what is in reality a much
broader problem (the server not having reliable information about the
client).

-Jason


Also, as I've mentioned whenever I talk about this stuff: server side is
ONE half of the solution. The other is new HTML. They do two different
things, and they appear superficially similar when they aren't. Server side
adaptation is about the times when it's right for the server to take
automated action based on the client's capabilties: e.g., sending lower
quality graphics when it detects the bandwidth is low. Mark-up solution is
about sending actual different URLs. e.g., an about page mug-shot. At high
device sizes this may be a full-length body shot. At smaller sizes it's not
practical to simly shrink it as you no longer recognise what's important,
so you substitute a head and shoulders shot for lower screen sizes.
Different content that's doing the same semantic job.

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

2012-02-07 Thread Henri Sivonen

On Mon, Feb 6, 2012 at 5:52 PM, Matthew Wilcox m...@matthewwilcox.com 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 enabled. That would be a layering violation.

That is, SPDY is supposed to work as a drop-in replacement for the old
way of putting HTTP semantics over IP. You aren't supposed to send
different headers depending on whether SPDY is there or not.

And the old HTTP is going to be around for a *long* time, so even if a
bunch of important sites start supporting SPDY, if browsers send the
same headers in all cases to avoid the layering violation, the long
tail of plain old HTTP sites would be harmed by request size bloat.

So I think SPDY will fix it is not a persuasive argument for
allowing HTTP request bloat to cater to the bandwagon of the day.
(Sorry if that seems offensive. You've worked on responsive images, so
they evidently seem important to you, but in the long-term big
picture, it's nowhere near proven that they aren't a fad of interest
to a relative small number of Web developers.)

If there is evidence that responsive images aren't just a fad
bandwagon and there's a long-term need to support them in the
platform, I think supporting something like
picture
source src=something.jpg media=...
source src=other.jpg media=...
img src=fallback.jpg
/picture
would make more sense, since the added to transfer this markup would
affect sites that use this stuff instead of affecting each request to
all sites that don't use this stuff. This would be more
intermediary-friendly, too, by not involving the Vary header.

The points Boris made about the device pixel size of the image
changing after the page load still apply, though.

But still, engineering for sites varying the number of pixels they
send for photos seems a bit premature when sites haven't yet adopted
SVG for illustrations, diagrams, logos, icons, etc.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

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
it? To be clear: this is a case of browser vendors deciding it's too
expensive and therefor not allowing it to be implemented, when it should be
authors in the position to know whether it's too expensive given their
specific use case.

I'm sensing the SPDY/HTTP identical-semantics standpoint may be a
philosophical thing rather than technical?

No offense taken btw. Things have to prove themselves. The danger is the
standards process is too slow to react well, and some even more hacky
solution turning into a de-facto standard. Personally, I think the issue of
adapting resources to client capabilities is here to stay. Devices of
significantly varied size and performance are here to stay, and adapting
images to suit is only one example of smart resource adaption - it doesn't
seem like it would become irrelevant until all devices are memory and
processor monsters over high speed connections. Which is going to take
decades, if it ever happens.

I'm glad the discussion is going on though, and there are as always points
to be considered that are not obvious at first.

It just seems like SPDY as a technology is in a great position to do this.
It's the choice of restricting SPDY to HTTP's viable capabilities which is
the cause of a potential veto of this.

:)

On 7 February 2012 13:34, Henri Sivonen hsivo...@iki.fi wrote:

 On Mon, Feb 6, 2012 at 5:52 PM, Matthew Wilcox m...@matthewwilcox.com
 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 enabled. That would be a layering violation.

 That is, SPDY is supposed to work as a drop-in replacement for the old
 way of putting HTTP semantics over IP. You aren't supposed to send
 different headers depending on whether SPDY is there or not.

 And the old HTTP is going to be around for a *long* time, so even if a
 bunch of important sites start supporting SPDY, if browsers send the
 same headers in all cases to avoid the layering violation, the long
 tail of plain old HTTP sites would be harmed by request size bloat.

 So I think SPDY will fix it is not a persuasive argument for
 allowing HTTP request bloat to cater to the bandwagon of the day.
 (Sorry if that seems offensive. You've worked on responsive images, so
 they evidently seem important to you, but in the long-term big
 picture, it's nowhere near proven that they aren't a fad of interest
 to a relative small number of Web developers.)

 If there is evidence that responsive images aren't just a fad
 bandwagon and there's a long-term need to support them in the
 platform, I think supporting something like
 picture
 source src=something.jpg media=...
 source src=other.jpg media=...
 img src=fallback.jpg
 /picture
 would make more sense, since the added to transfer this markup would
 affect sites that use this stuff instead of affecting each request to
 all sites that don't use this stuff. This would be more
 intermediary-friendly, too, by not involving the Vary header.

 The points Boris made about the device pixel size of the image
 changing after the page load still apply, though.

 But still, engineering for sites varying the number of pixels they
 send for photos seems a bit premature when sites haven't yet adopted
 SVG for illustrations, diagrams, logos, icons, etc.

 --
 Henri Sivonen
 hsivo...@iki.fi
 http://hsivonen.iki.fi/

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

2012-02-07 Thread Jason Grigsby

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 needs 
 about the client device/environment, and have that sent as a header. And only 
 sent if the server has asked. I don't mean we want screen size alone, that 
 is but one example of something the server might care about. Bandwidth is 
 another, as is viewport size, and I am sure there are a lot more. I want to 
 see a *communication method* defined here, not a one-issue semi-solution to 
 an overly specific example of what is in reality a much broader problem (the 
 server not having reliable information about the client).

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

2012-02-07 Thread Charles McCathieNevile

On Tue, 07 Feb 2012 15:13:03 +0100, Matthew Wilcox  
m...@matthewwilcox.com 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 adapting images to suit is only one example of smart resource
adaption - it doesn't seem like it would become irrelevant until all
devices are memory and processor monsters over high speed connections.


Actually I suspect the end condition is until memory and processing and  
bandwidth are all free which is slightly different.



Which is going to take decades, if it ever happens.


I will be surprised if I see it.

Anyway, I would really encourage you to look at  
http://en.wikipedia.org/wiki/Device_Description_Repository andperhaps  
something like http://www.openddr.org/ or the commercial solutions that  
deal with this area.


cheers

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

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 is a device database going to tell us the current connection
speed, or the user's zoom level, or device orientation, or anything else
dynamic that may be relevant to know on the server?

The database route is merely an extension of UA sniffing, which was about
detecting devices and assuming capabilities and settings. The problem with
that was inaccuracy, and ongoing laboured maintenance. I want us to detect
the actual capabilities directly - exactly how CSS works. Detect what's
there. Skip the middle-man. How does it make sense to resort to siloing
this information in a database, when we're the body that makes the
standards that would allow direct knowledge?

I'm less interested in current work-arounds (and that's what those are,
workarounds and best guesses destined to fail at some point) and more
interested in getting accurate, reliable, future-proof data exposed.

On 7 February 2012 16:46, Charles McCathieNevile cha...@opera.com wrote:

On Tue, 07 Feb 2012 15:13:03 +0100, Matthew Wilcox m...@matthewwilcox.com
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 adapting images to suit is only one example of smart resource
adaption - it doesn't seem like it would become irrelevant until all
devices are memory and processor monsters over high speed connections.

Actually I suspect the end condition is until memory and processing and
bandwidth are all free which is slightly different.

Which is going to take decades, if it ever happens.

I will be surprised if I see it.

Anyway, I would really encourage you to look at
http://en.wikipedia.org/wiki/**Device_Description_Repositoryhttp://en.wikipedia.org/wiki/Device_Description_Repositoryandperhaps
something like
http://www.openddr.org/ or the commercial solutions that deal with this
area.

cheers

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

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 information will 
hurt their users' privacy, 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 that the proposal is bad for 
the web in various ways.


Now obviously it's also good for the web in various ways, if people use 
the information correctly and such.  My faith in this is somewhat 
tarnished by the fact that every concrete proposal for using it that 
I've seen seems to be broken by design, which means that chances of 
anyone using it correctly are vanishingly small.  We should strive to 
provide information that will enable the server to better serve the user 
without it being rocket science to do so without breaking other users. 
The problem is that we haven't found a way to do that yet.



when it should be
authors in the position to know whether it's too expensive given their
specific use case.


This is privileging authors over users.  I understand the author 
perspective on this, but in general I care about users more than we do 
about authors  I don't think I'm the only one.



No offense taken btw. Things have to prove themselves. The danger is the
standards process is too slow to react well, and some even more hacky
solution turning into a de-facto standard.


Yes, this is a problem.


Devices of significantly varied size and performance are here to stay


Yes, but size and performance are not necessarily a function of the 
actual device.  They can be a function of the device, the network, the 
currently attached peripherals, etc.  Importantly, they are not 
time-invariant.  The question is what we can do about that...


(Simple example: the performance of my laptop will vary by easily a 
factor of close to 1.5 just depending on whether it's plugged in and 
what sort of surface it's resting on.  I expect this trend to continue 
unless we get some sort of revolutionary improvements in battery and 
cooling technology.)


-Boris

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 purely
scratching his own itch, I find it very difficult to justify the
position that he ought to have wanted something different to what he
actually wanted and made.


The fewer users a system has the more weird the requirements can get.  I 
accept that.  I do wonder how much we should care about that on the web, 
though.



In general the idea that sites/applications should be essentially the
same, but perhaps slightly rearranged, regardless of the device they run
on just doesn't seem to be something that the market agrees with.


I'm willing to accept that too.  How much of this is a matter of 
effectively cepy/paste, how much is a matter of this being the path of 
least resistance in the face of technical challenges and political 
opposition (e.g. removing most ads from the desktop version of a site 
might not be viewed favorably), and how much is actually dictated by the 
device differences is unclear to me.



It seems to me that we can either pretend that this isn't true, and watch
as platform-specific apps become increasingly entrenched, or work out
ways to make the UX on sites that target multiple types of hardware as
good as possible.


Clearly the latter is preferable.  It's hard to do that without very 
specific use cases; we've been getting some in this thread, but there's 
a high level of we just want it to look different, and need a way to 
guess what it should look like going on too.



Of course. The critical point was that there was different information
in the two cases.


This is the part I'd like to understand.  Why?  Did this have to do with 
the actual devices, or with the way the particular person happened to 
use the two devices in his day-to-day activities?  I realize you may not 
know.


That said, if the information was really _different_ then I'm not sure I 
agree with the same URI requirement.



So it seems to me that we have a problem that real people are hacking
their way around by using techniques that are known to be suboptimal or
downright harmful. Therefore we should take the desire for a solution
seriously


Yes.

-Boris

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 bzbar...@mit.edu wrote:

 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 information will
 hurt their users' privacy


Can you clarify how this hurts privacy? I'm not sure how reporting back
things like connection speed or screen size constitutes a genuine privacy
issue?


 , 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 that the proposal is bad for the web in various ways.


I'm not sure what your grounds are for thinking this. Would it not be
sensible for the server to have to serve some default if the headers aren't
there anyway, the assumption must be that the device can't send these
headers. In what circumstances might this cause breakages? And how could it
possibly lock out any devices? This is a progressive-enhancement type tech,
not a if you don't have the ability to notify the server you can't get any
info type tech. Surely?


 Now obviously it's also good for the web in various ways, if people use
 the information correctly and such.  My faith in this is somewhat
 tarnished by the fact that every concrete proposal for using it that I've
 seen seems to be broken by design, which means that chances of anyone using
 it correctly are vanishingly small.


Can you tell us how they're broken so we can fix it?


  We should strive to provide information that will enable the server to
 better serve the user without it being rocket science to do so without
 breaking other users.


Absolutely agree, but I don't see how a server requesting and then getting
a header is rocket sceince. Especially if the current solution is to
connect to some massive device database to query potential points of
reference and then act accordingly.


  when it should be
 authors in the position to know whether it's too expensive given their
 specific use case.


 This is privileging authors over users. I understand the author
 perspective on this, but in general I care about users more than we do
 about authors  I don't think I'm the only one.


I can see your point, but there isn't any impact for users unless the
author has opted in and requested headers. Right? The defaults are
server gets no headers. Put it another way - how can an author tailor
things for a user if the user isn't able to report anything to the server?
Not allowing this process is a disservice to the user *and* the author.
It's basically saying no, you can't drive the car because you may end up
on a busy road which will be even slower than walking.


  No offense taken btw. Things have to prove themselves. The danger is the
 standards process is too slow to react well, and some even more hacky
 solution turning into a de-facto standard.


 Yes, this is a problem.


  Devices of significantly varied size and performance are here to stay


 Yes, but size and performance are not necessarily a function of the
 actual device.  They can be a function of the device, the network, the
 currently attached peripherals, etc.  Importantly, they are not
 time-invariant.  The question is what we can do about that...


Agreed - which is *exactly* why I think headers are the only viable
solution. The other solutions operate by detecting the device and making
assumptions about those variables based on the device specifications. Only
the device you're talking with right then can possibly have that
information.


 (Simple example: the performance of my laptop will vary by easily a factor
 of close to 1.5 just depending on whether it's plugged in and what sort of
 surface it's resting on.  I expect this trend to continue unless we get
 some sort of revolutionary improvements in battery and cooling technology.)


Exactly! Hence the need for the browser to report *as a header* with each
request what the current values are for those variables.


 -Boris

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

2012-02-07 Thread David Goss

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 the browser to send anything that can't be
detected client-side and sent to the server anyway.

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 like connection speed or screen size constitutes a genuine
privacy issue?


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 
and similar resources for details.



, 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 that the proposal is bad for the web
in various ways.


I'm not sure what your grounds are for thinking this. Would it not be
sensible for the server to have to serve some default if the headers
aren't there anyway


Maybe it would be _sensible_, but would people do it?  I suggest trying 
to browse the web with an empty UA string and seeing what fraction of 
servers serve some default for that as opposed to the fraction that 
completely break and return error pages for everything or return 
severely malformed pages...  Last I tried this, double-digit percentages 
of the sites I visited broke.



In what circumstances might this cause breakages?


Whenever the server developer makes dumb assumptions.  Which they do all 
the time.  _All_ the time.



And how could it possibly lock out any devices?


See my earlier example of a desktop-class touchscreen system that's 
shipping right now.  Every single concrete proposal I've seen so far in 
this thread would lock it out of actually using its touch capabilities 
on sites that would support such capabilities fine on other devices.



This is a progressive-enhancement type tech, not a if you don't have the 
ability
to notify the server you can't get any info type tech. Surely?


Surely not, in my experience with other things servers look for.


Now obviously it's also good for the web in various ways, if people
use the information correctly and such.  My faith in this is
somewhat tarnished by the fact that every concrete proposal for
using it that I've seen seems to be broken by design, which means
that chances of anyone using it correctly are vanishingly small.

Can you tell us how they're broken so we can fix it?


Did you read my earlier mails with examples of devices that are shipping 
right now that violate the various assumptions people trying to create 
these device class bins are making?



Absolutely agree, but I don't see how a server requesting and then
getting a header is rocket sceince


The rocket science lies in deciding what to do with the information.


Especially if the current solution
is to connect to some massive device database to query potential points
of reference and then act accordingly.


Which is just as broken, yes.  We've run into problems with the breakage 
of this database a good bit at Mozilla.



I can see your point, but there isn't any impact for users unless the
author has opted in and requested headers. Right? The defaults are
server gets no headers. Put it another way - how can an author tailor
things for a user if the user isn't able to report anything to the
server?


I didn't say the user shouldn't report anything.  I said that the 
particular things people have asked to be reported so far (screen size, 
device class) are broken by design.



Yes, but size and performance are not necessarily a function of
the actual device.  They can be a function of the device, the
network, the currently attached peripherals, etc.  Importantly, they
are not time-invariant.  The question is what we can do about that...

Agreed - which is *exactly* why I think headers are the only viable
solution.


My point is that we should perhaps be thinking about how to make things 
work when these device characteristics change while a page is loaded. 
Headers do NOT allow you to handle that, for obvious reasons.



The other solutions operate by detecting the device and making
assumptions about those variables based on the device specifications.


Assuming you can detect the device at all, which I think servers should 
not be able to do.



Exactly! Hence the need for the browser to report *as a header* with
each request what the current values are for those variables.


See above.  I don't see how just putting it in the headers helps.  It 
just encourages websites to assume that the information won't be 
changing after the request is done.


-Boris

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? I don't think
anyone's asking for the browser to send anything that can't be
detected client-side and sent to the server anyway.


The idea is to prevent pervasive user tracking via fingerprinting.  It's 
actually easy to prevent client-side detection of some of these things; 
just turn off script execution for the relevant origins.


-Boris

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

2012-02-07 Thread Mike Taylor

On Tue, 07 Feb 2012 11:32:23 -0600, Matthew Wilcox  
m...@matthewwilcox.com 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 that the proposal is bad for the web in various ways.


I'm not sure what your grounds are for thinking this. Would it not be
sensible for the server to have to serve some default if the headers  
aren't

there anyway, the assumption must be that the device can't send these
headers. In what circumstances might this cause breakages? And how could  
it
possibly lock out any devices? This is a progressive-enhancement type  
tech,
not a if you don't have the ability to notify the server you can't get  
any

info type tech. Surely?


Progressive-enhancement type tech gets abused as well. Take the video  
element, with its lovely source elements for codecs and fallback content  
for non-supporting UAs. No hacks necessary. Then throw laziness and  
javascript at it and you've got a mess.


An example, visit http://www.maerskfleet.com/ with an empty UA string (or  
use Opera). In a browser that should be able to support video, you'll  
get a JS error and the page is blank. Even after including Modernizr and  
using HTML5 which is designed to gracefully degrade for older UAs,  
developers do the same old UA sniffing trick:  
https://gist.github.com/1761168


I would love to believe that all developers would use this proposal for  
good, as it were. Experience leads me to believe it will be just another  
technique sniffed and served to the regular suspects.


--
Mike Taylor
Opera Software

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 see my:

screen size

connection speed

…

On 7 February 2012 22:45, Mike Taylor mi...@opera.com wrote:

 On Tue, 07 Feb 2012 11:32:23 -0600, Matthew Wilcox m...@matthewwilcox.com
 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 that the proposal is bad for the web in various ways.

  I'm not sure what your grounds are for thinking this. Would it not be
 sensible for the server to have to serve some default if the headers
 aren't
 there anyway, the assumption must be that the device can't send these
 headers. In what circumstances might this cause breakages? And how could
 it
 possibly lock out any devices? This is a progressive-enhancement type
 tech,
 not a if you don't have the ability to notify the server you can't get
 any
 info type tech. Surely?


 Progressive-enhancement type tech gets abused as well. Take the video
 element, with its lovely source elements for codecs and fallback content
 for non-supporting UAs. No hacks necessary. Then throw laziness and
 javascript at it and you've got a mess.

 An example, visit http://www.maerskfleet.com/ with an empty UA string (or
 use Opera). In a browser that should be able to support video, you'll get
 a JS error and the page is blank. Even after including Modernizr and using
 HTML5 which is designed to gracefully degrade for older UAs, developers do
 the same old UA sniffing trick: 
 https://gist.github.com/**1761168https://gist.github.com/1761168

 I would love to believe that all developers would use this proposal for
 good, as it were. Experience leads me to believe it will be just another
 technique sniffed and served to the regular suspects.

 --
 Mike Taylor
 Opera Software

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 bzbar...@mit.edu 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 information
will hurt their users' privacy

 Can you clarify how this hurts privacy? I'm not sure how reporting back
 things like connection speed or screen size constitutes a genuine
 privacy issue?


 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-privacyhttps://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacyand
  similar resources for details.


Agreed. But this already happens. Your point is the user must be able to
opt in and out, as they might be turning off JS (which, frankly, how many
non-webnerd people do?). So you're saying the problem isn't the tech but
the user control? Can we not give that to them?




 , 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 that the proposal is bad for the web
in various ways.


 I'm not sure what your grounds are for thinking this. Would it not be
 sensible for the server to have to serve some default if the headers
 aren't there anyway


 Maybe it would be _sensible_, but would people do it?  I suggest trying to
 browse the web with an empty UA string and seeing what fraction of servers
 serve some default for that as opposed to the fraction that completely
 break and return error pages for everything or return severely malformed
 pages...  Last I tried this, double-digit percentages of the sites I
 visited broke.


Point taken. Though it irks me no end that various technologies get canned
because of how inept people can mis-use them. I'd rather see those inept
people shoot themselves in the foot and pay the price. Personal philosophy
there.


  In what circumstances might this cause breakages?


 Whenever the server developer makes dumb assumptions.  Which they do all
 the time.  _All_ the time.


  And how could it possibly lock out any devices?


 See my earlier example of a desktop-class touchscreen system that's
 shipping right now.  Every single concrete proposal I've seen so far in
 this thread would lock it out of actually using its touch capabilities on
 sites that would support such capabilities fine on other devices.


I don't think I have enough knowledge of the case in point to argue either
way, but I'm confused how this would be the case at the moment.


  This is a progressive-enhancement type tech, not a if you don't have the
 ability
 to notify the server you can't get any info type tech. Surely?


 Surely not, in my experience with other things servers look for.


Fair enough :s


 Now obviously it's also good for the web in various ways, if people
use the information correctly and such.  My faith in this is
somewhat tarnished by the fact that every concrete proposal for
using it that I've seen seems to be broken by design, which means
that chances of anyone using it correctly are vanishingly small.

 Can you tell us how they're broken so we can fix it?


 Did you read my earlier mails with examples of devices that are shipping
 right now that violate the various assumptions people trying to create
 these device class bins are making?


I don't believe we should ever use classes of device. We've been down
that route, it's a fail in and of itself. We should be using actual data,
not assumed data based on some other data.


  Absolutely agree, but I don't see how a server requesting and then
 getting a header is rocket sceince


 The rocket science lies in deciding what to do with the information.


Ugh, I wrote 'rocket science'. Sorry.


  Especially if the current solution
 is to connect to some massive device database to query potential points
 of reference and then act accordingly.


 Which is just as broken, yes.  We've run into problems with the breakage
 of this database a good bit at Mozilla.


Cool so we agree databases are a bad solution and we should aim for better
:)


  I can see your point, but there isn't any impact for users unless the
 author has opted in and requested headers. Right? The defaults are
 server gets no headers. Put it another way - how can an author tailor
 things for a user if the user isn't able to report anything to the
 server?


 I didn't say the user shouldn't report anything.  I said that the
 particular things people have asked to be reported so far (screen size,
 device class) are broken by design.


Absolutely agree on device class. I don't understand why screen-size is
broken. Report back the maximum

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

2012-02-07 Thread Nils Dagsson Moskopp

Matthew Wilcox m...@matthewwilcox.com 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 designed for
800x600, 16 colors, IE 5.5 or later.” – only with the added “feature”
of “sucks to be you, get a bigger screen, this content will not
display”. UA sniffing, now even worse! Oh, I would certainly be mad.

 connection speed

This is an interesting case – but today well handled by minimal sites.
OkCupid, Twitter, Wikipedia all have well-known minimal alternatives
that can be used when on a bandwith-constrained connection. Often, they
are arguably better (not full of ads etc.).

Since that type of request is not narrowly constrained to specific
circumstances (e.g. location-based services), there is a possibility
for this to become very annoying.

Externalizing the inability to provide content that works across
multiple devices is a very easy cop-out for developers. I for one
advocate control at the UA level (like with CSS media queries) so there
won't be yet another UA string nightmare.

Also, I am writing this on a laptop via a throttled mobile connection.
-- 
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net

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

https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy
and similar resources for details.


Agreed. But this already happens.


And browsers are working on mitigating the ways it already happens. 
Which means they're reluctant to add new fingerprinting surface.



Your point is the user must be able to
opt in and out, as they might be turning off JS (which, frankly, how
many non-webnerd people do?)


Just wait until UAs start shipping with JS disabled for certain domains 
by default, just like they're already shipping with other capabilities 
turned on or off with certain domains by default.



So you're saying the problem isn't the
tech but the user control? Can we not give that to them?


I'm saying that the _default_ behavior should ideally be as 
user-friendly as possible.  That includes user privacy concerns.  There 
can be additional knobs to enable more privacy features, of course, but 
a lot of what goes on in the privacy space on the web right now 
basically depends on user ignorance about the information websites are 
getting out of them.  When I actually describe the underlying technology 
to non-technical users, they're almost uniformly horrified...



Point taken. Though it irks me no end that various technologies get
canned because of how inept people can mis-use them. I'd rather see
those inept people shoot themselves in the foot and pay the price.


The problem is that the price ends up being paid by someone else. 
Classic example of externalities...  If we could make people fully 
internalize the consequences of their own incompetence, a lot of things 
would ure be easier!



Did you read my earlier mails with examples of devices that are
shipping right now that violate the various assumptions people
trying to create these device class bins are making?


I don't believe we should ever use classes of device. We've been down
that route, it's a fail in and of itself. We should be using actual
data, not assumed data based on some other data.


OK, good.  We agree on that.  :)


Absolutely agree on device class. I don't understand why screen-size
is broken.


Because half the people asking for it explicitly say they plan to use it 
as a proxy for other device characteristics.  It's not broken per se, of 
course, just the way people plan to use it.



My point is that we should perhaps be thinking about how to make
things work when these device characteristics change while a page is
loaded. Headers do NOT allow you to handle that, for obvious reasons.

Ah, loaded as in mid-stream?


That's a problem too, but a small one as you note.  I was thinking as 
in between when onload fires and when onunload fires.  For some web 
pages, this time is typically measured in weeks for me (my web-based RSS 
reader, for example).



See above.  I don't see how just putting it in the headers helps.
  It just encourages websites to assume that the information won't
be changing after the request is done.

How does it encourage website that? That would involve using sessions to
track the user and know which request had what data the last time. And
manually writing some session tracking to do that. I see this as a per
request thing. New data every time.


My RSS reader loads its user interface precisely once over the course of 
several weeks.  If it based this interface on device characteristics at 
time of load (which it actually does, by the way, insofar as it sniffs 
the UA string and then guesses as you point out), then it would be 
broken if I ever change those device characteristics (which I do, and it 
is).


It'd be nice if we could create something that would not lead the people 
writing the RSS reader to end up with exactly the setup they have now...


-Boris

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 Zbarskybzbar...@mit.edu  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 how could it possibly lock out any devices?
See my earlier example of a desktop-class touchscreen system that's
shipping right now.  Every single concrete proposal I've seen so far in
this thread would lock it out of actually using its touch capabilities on
sites that would support such capabilities fine on other devices.


I don't think I have enough knowledge of the case in point to argue either
way, but I'm confused how this would be the case at the moment.



We already see some frustrating lockout with websites that detect mobile 
user agents. They forward the agent to their special mobile website, 
where they will often popup an alert (Please download our APP!!!) 
every single time you visit the page. Their mobile site is frequently 
crippled, limited to only a few options, and the mobile browser is often 
capable of viewing the full desktop site at a reasonable screen width. 
Now, as sites mature, they have figured out to include a Desktop 
Version toggle, which is a big help. It's still frustrating that there 
are a few steps in between.


These sites make an assumption, that the screen size has something to do 
with device capability. The screen size has to do with how much 
information the viewer has decided to consume at one time.


I'm frequently using browser zoom (though I use OS zoom as well), and I 
don't need to be forwarded to the mobile site while I'm browsing on my 
desktop just because I'm not wearing my glasses. That said, I do try to 
work with my applications so that the mobile interface is an interface 
that I would like to use on my desktop when I'm zoomed in. That middle 
ground works well for me.




 Now obviously it's also good for the web in various ways, if people

use the information correctly and such.  My faith in this is
somewhat tarnished by the fact that every concrete proposal for
using it that I've seen seems to be broken by design, which means
that chances of anyone using it correctly are vanishingly small.

Can you tell us how they're broken so we can fix it?


Did you read my earlier mails with examples of devices that are shipping
right now that violate the various assumptions people trying to create
these device class bins are making?


I don't believe we should ever use classes of device. We've been down
that route, it's a fail in and of itself. We should be using actual data,
not assumed data based on some other data.


We have abstract means of accessibility. WCAG2 explores that.

We have classes of how data is accessed. It should be accessible from a 
keyboard only device.
With touch screens, the world has been exploring more, the concept of 
accessible via pointer only (though virtual keyboards help).


Keep in mind that keyboard and pointer are also two abstractions, not 
physical objects.


There's a third class of accessibility, and that's programmatic access. 
Ensuring that the DOM has sufficient information that third-party
software can use. This is frequently used for eyes-free interfaces, but 
it's handy for many other targets.


There's no assumption of a screen being in place, nor an assumption of 
any particular physical interface.



  Especially if the current solution

is to connect to some massive device database to query potential points
of reference and then act accordingly.


Which is just as broken, yes.  We've run into problems with the breakage
of this database a good bit at Mozilla.


Cool so we agree databases are a bad solution and we should aim for better
:)


Databases are a practical solution for special situations, such as Boris 
brought up, targeting old and somewhat broken browser implementations.


This part of the thread reminds me of the other thing we did with 
server-side packaging -- a bunch of polyfill code. If the user string 
matches X, then we need to include a bunch of compatibility libraries.


It's fairly accepted that feature testing works better. At least in 
feature testing, when the compatibility is not available, there's a 
chance to show some kind of alternate item. People can get lazy on this 
as well, writing things like You are not supported, go away in 
fallback content. But that's just poor practice. There's every reason to 
think a manual, documentation and other media could take its place.




Absolutely agree on device class. I don't understand why screen-size is
broken. Report back the maximum screen size used by the device at the
current moment. This allows us to plug iPads into TVs and have it all still
work.


Screen size is not and should not be a physical reflection of the 
viewing device.


The user may be using an eyes-free interface; they may be using browser

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-and-privacy
   https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy
   and similar resources for details.


Agreed. But this already happens.

And browsers are working on mitigating the ways it already happens.
Which means they're reluctant to add new fingerprinting surface.

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?

Your point is the user must be able to
opt in and out, as they might be turning off JS (which, frankly, how
many non-webnerd people do?)

Just wait until UAs start shipping with JS disabled for certain
domains by default, just like they're already shipping with other
capabilities turned on or off with certain domains by default.

I browse with NoScript and regularly come across people that haven't
coded site's responsibly (it drives me nuts). While I applaud this
notion because it'll bring more attention to the issue - i highly
doubt it'll have any impact on the larger spectrum of sites. JS is now
relied on and if certain UA's deliver a broken web-page to users, the
users are just going to blame the software, not the website. Why?
Because the site works in every *other* browser, including their old
ones...

So you're saying the problem isn't the
tech but the user control? Can we not give that to them?

I'm saying that the _default_ behavior should ideally be as
user-friendly as possible.  That includes user privacy concerns.

Absolutely agree. I'm all for this being disabled by default and
opted-in as servers request. Or opted in via a user setting in the UA.

 There can be additional knobs to enable more privacy features, of
course, but a lot of what goes on in the privacy space on the web
right now basically depends on user ignorance about the information
websites are getting out of them.  When I actually describe the
underlying technology to non-technical users, they're almost uniformly
horrified…

They should be. But at the same time a hell of a lot of people have
read that FaceBook watches their every move, and yet happily continue
to use it. Users don't weigh the issue in the same way we do.

Point taken. Though it irks me no end that various technologies get
canned because of how inept people can mis-use them. I'd rather see
those inept people shoot themselves in the foot and pay the price.

The problem is that the price ends up being paid by someone else.
Classic example of externalities...  If we could make people fully
internalize the consequences of their own incompetence, a lot of
things would ure be easier!

Agreed! It's still my inclination to default to more permissive things
though. If people build poor sites, users stop going, the site fails,
and either the author learns (I hope) or switches to a job with less
requirement on skill level. It's like in business - if you're not
providing a decent product, you don't survive. The government doesn't
just disallow people from making rubbish with the resources they have.

   Did you read my earlier mails with examples of devices that are
   shipping right now that violate the various assumptions people
   trying to create these device class bins are making?

I don't believe we should ever use classes of device. We've been down
that route, it's a fail in and of itself. We should be using actual
data, not assumed data based on some other data.

OK, good.  We agree on that.  :)

Absolutely agree on device class. I don't understand why screen-size
is broken.

Because half the people asking for it explicitly say they plan to use
it as a proxy for other device characteristics.  It's not broken per
se, of course, just the way people plan to use it.

In that case I completely agree. But the answer is educate them to
test the right thing. The *only* reason they say that they'll use it
that way right now is because that's what they *have* to do to guess
the information. Classic case being CSS media queries, where screen
size is a proxy for bandwidth and device processing power. It's a
mentality they're in because there is no other solution. Let's provide
one.

   My point is that we should perhaps be thinking about how to make
   things work when these device characteristics change while a page is
   loaded. Headers do NOT allow you to handle that, for obvious reasons.

Ah, loaded as in mid-stream?

That's a problem too, but a small one as you note.  I was thinking as
in between when onload fires and when onunload fires.  For some web
pages, this time is typically measured in weeks for me (my web-based
RSS reader, for example).

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

On 7 February 2012 20:05, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Matthew Wilcox m...@matthewwilcox.com 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 designed for
800x600, 16 colors, IE 5.5 or later.” – only with the added “feature”
of “sucks to be you, get a bigger screen, this content will not
display”. UA sniffing, now even worse! Oh, I would certainly be mad.

I tire of this viewpoint.
Of course it can be used that way. There isn't a technology in
existance that can't be mis-used. Does that mean it's a bad idea to
try to solve problems with new technology?

connection speed

This is an interesting case – but today well handled by minimal sites.
OkCupid, Twitter, Wikipedia all have well-known minimal alternatives
that can be used when on a bandwith-constrained connection. Often, they
are arguably better (not full of ads etc.).

Handled how? By minimal sites is not an answer, that's a design
approach consisting of bring everything down to the lowest common
denominator if you use it for one site, or an extension of just
throw up a plain-text version if you supply it as a separate URL.

The point of responsive designs is to allow one URL to work well on
multiple un-known devices whose characteristics vary enormously. The
screen can have a ten fold difference in width and a greater
difference in processing power and network connectivity. One of the
main issue in this arena is how to adapt images, because you don't
want to send big images to small devices. So, how do you see this
particular problem as already solved? Please - myself and a few dozen
other people who've been at this for the last year would like to know
- how do we serve a small image to small devices and a big one to
large devices? Reliably? Without the flaws of all the existing
attempted solutions, which are well documented elsewhere?

http://adaptive-images.com
http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/
http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/
etc

PS: UA sniffing and dedicated 'mobile' site's are expressly not the answer.

Since that type of request is not narrowly constrained to specific
circumstances (e.g. location-based services), there is a possibility
for this to become very annoying.

Externalizing the inability to provide content that works across
multiple devices is a very easy cop-out for developers. I for one
advocate control at the UA level (like with CSS media queries) so there
won't be yet another UA string nightmare.

I would hate another UA string nightmare too. Hence why I want
headers. Explicit, direct, non-assumed reporting of actual, current
properties. Without guessing.

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

--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net

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

2012-02-07 Thread divya manian

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 I
know before hand, I can make sure the user gets information in time.
* notification of change of any of these: so I can provide scaled up
experiences when these alter.

Feature testing would be sufficient for me to test support for various
standards, and ideally that should be something like this
http://dev.w3.org/csswg/css3-conditional/ for all open web
technologies. And based on my knowledge of the above I can provide a
decent experience for the user.

Screen resolution is something users have to work with. This is how it
has been on desktop and I suppose how this should work on mobile
rather than trying to detect it server side.

But yeah it seems like none of what I want can ever be provided
without a significant change in how ISPs, mobile data providers, etc
work. :

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 are too big.
b) Too many javascript files.
c) Too much html content.

The proposed fix:
a) Send a display size header, have the server do magick.

That doesn't seem to be the right approach.

Let me know if I've got that right / wrong.

I'm fine with sending a bandwidth-request header.
Something to say: hey you, I'm on a metered connection, don't waste my time.
Or just, hey, this connection is slow, give me a hand here.

That one directly addresses the issue.

On the server-side, I can decide if I want to serve downsampled images, 
lesser content

or otherwise repackage my javascript.

Nothing to do with viewport sizes.

-Charles

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 capable it should send a header back. Which allows the server to
then do whatever it needs with the information. Screen size is one
example. Bandwidth is another.

It's the *communication of capabilities* that interests me at this
point, The allowing of an interrogation of possibliities and adaptive
responses.

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.

On 7 February 2012 20:24, Charles Pritchard ch...@jumis.com wrote:
 On 2/7/2012 11:52 AM, Matthew Wilcox wrote:

 On 7 February 2012 17:59, Boris Zbarskybzbar...@mit.edu  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 how could it possibly lock out any devices?
 See my earlier example of a desktop-class touchscreen system that's
 shipping right now.  Every single concrete proposal I've seen so far in
 this thread would lock it out of actually using its touch capabilities on
 sites that would support such capabilities fine on other devices.


 I don't think I have enough knowledge of the case in point to argue either
 way, but I'm confused how this would be the case at the moment.



 We already see some frustrating lockout with websites that detect mobile
 user agents. They forward the agent to their special mobile website, where
 they will often popup an alert (Please download our APP!!!) every single
 time you visit the page. Their mobile site is frequently crippled, limited
 to only a few options, and the mobile browser is often capable of viewing
 the full desktop site at a reasonable screen width. Now, as sites mature,
 they have figured out to include a Desktop Version toggle, which is a big
 help. It's still frustrating that there are a few steps in between.

 These sites make an assumption, that the screen size has something to do
 with device capability. The screen size has to do with how much information
 the viewer has decided to consume at one time.

 I'm frequently using browser zoom (though I use OS zoom as well), and I
 don't need to be forwarded to the mobile site while I'm browsing on my
 desktop just because I'm not wearing my glasses. That said, I do try to work
 with my applications so that the mobile interface is an interface that I
 would like to use on my desktop when I'm zoomed in. That middle ground works
 well for me.



     Now obviously it's also good for the web in various ways, if people

    use the information correctly and such.  My faith in this is
    somewhat tarnished by the fact that every concrete proposal for
    using it that I've seen seems to be broken by design, which means
    that chances of anyone using it correctly are vanishingly small.

 Can you tell us how they're broken so we can fix it?

 Did you read my earlier mails with examples of devices that are shipping
 right now that violate the various assumptions people trying to create
 these device class bins are making?


 I don't believe we should ever use classes of device. We've been down
 that route, it's a fail in and of itself. We should be using actual data,
 not assumed data based on some other data.


 We have abstract means of accessibility. WCAG2 explores that.

 We have classes of how data is accessed. It should be accessible from a
 keyboard only device.
 With touch screens, the world has been exploring more, the concept of
 accessible via pointer only (though virtual keyboards help).

 Keep in mind that keyboard and pointer are also two abstractions, not
 physical objects.

 There's a third class of accessibility, and that's programmatic access.
 Ensuring that the DOM has sufficient information that third-party
 software can use. This is frequently used for eyes-free interfaces, but it's
 handy for many other targets.

 There's no assumption of a screen being in place, nor an assumption of any
 particular physical interface.


  Especially if the current solution

 is to connect to some massive device database to query potential points
 of reference and then act accordingly.

 Which is just as broken, yes.  We've run into problems with the breakage
 of this database a good bit at Mozilla.


 Cool so we agree databases are a bad solution and we should aim for better
 :)


 Databases are a practical solution for special situations, such as Boris
 brought up, targeting old and somewhat broken browser implementations.

 This part of the thread reminds me of the other thing we did with

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 for a possibliity
that the browser may end up six times larger than it is now.

It's not purely about information adaption, there is visual design
consideration that is as paramount as any other argument. If a website
looks janky, the client (as in the web development agency's client)
isn't going to pay for it.



On 7 February 2012 21:19, Charles Pritchard ch...@jumis.com 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 thread -- all of these use cases are about bandwidth.

 a) Images are too big.
 b) Too many javascript files.
 c) Too much html content.

 The proposed fix:
 a) Send a display size header, have the server do magick.

 That doesn't seem to be the right approach.

 Let me know if I've got that right / wrong.

 I'm fine with sending a bandwidth-request header.
 Something to say: hey you, I'm on a metered connection, don't waste my time.
 Or just, hey, this connection is slow, give me a hand here.

 That one directly addresses the issue.

 On the server-side, I can decide if I want to serve downsampled images,
 lesser content
 or otherwise repackage my javascript.

 Nothing to do with viewport sizes.

 -Charles

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

2012-02-07 Thread Tim Kadlec


 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 as well. Client-side feature detection is
simply not capable of solving everything.

Something like this would also be very future friendly. We don't know what
properties are going to be important a few years down the line. If this
model is implemented carefully, it would be easy to add new properties to
the mix.

- Tim

On Tue, Feb 7, 2012 at 3:21 PM, Matthew Wilcox m...@matthewwilcox.comwrote:

 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 capable it should send a header back. Which allows the server to
 then do whatever it needs with the information. Screen size is one
 example. Bandwidth is another.

 It's the *communication of capabilities* that interests me at this
 point, The allowing of an interrogation of possibliities and adaptive
 responses.

 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.

 On 7 February 2012 20:24, Charles Pritchard ch...@jumis.com wrote:
  On 2/7/2012 11:52 AM, Matthew Wilcox wrote:
 
  On 7 February 2012 17:59, Boris Zbarskybzbar...@mit.edu  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 how could it possibly lock out any devices?
  See my earlier example of a desktop-class touchscreen system that's
  shipping right now.  Every single concrete proposal I've seen so far in
  this thread would lock it out of actually using its touch capabilities
 on
  sites that would support such capabilities fine on other devices.
 
 
  I don't think I have enough knowledge of the case in point to argue
 either
  way, but I'm confused how this would be the case at the moment.
 
 
 
  We already see some frustrating lockout with websites that detect mobile
  user agents. They forward the agent to their special mobile website,
 where
  they will often popup an alert (Please download our APP!!!) every
 single
  time you visit the page. Their mobile site is frequently crippled,
 limited
  to only a few options, and the mobile browser is often capable of viewing
  the full desktop site at a reasonable screen width. Now, as sites mature,
  they have figured out to include a Desktop Version toggle, which is a
 big
  help. It's still frustrating that there are a few steps in between.
 
  These sites make an assumption, that the screen size has something to do
  with device capability. The screen size has to do with how much
 information
  the viewer has decided to consume at one time.
 
  I'm frequently using browser zoom (though I use OS zoom as well), and I
  don't need to be forwarded to the mobile site while I'm browsing on my
  desktop just because I'm not wearing my glasses. That said, I do try to
 work
  with my applications so that the mobile interface is an interface that
 I
  would like to use on my desktop when I'm zoomed in. That middle ground
 works
  well for me.
 
 
 
  Now obviously it's also good for the web in various ways, if people
 
 use the information correctly and such.  My faith in this is
 somewhat tarnished by the fact that every concrete proposal for
 using it that I've seen seems to be broken by design, which means
 that chances of anyone using it correctly are vanishingly small.
 
  Can you tell us how they're broken so we can fix it?
 
  Did you read my earlier mails with examples of devices that are
 shipping
  right now that violate the various assumptions people trying to create
  these device class bins are making?
 
 
  I don't believe we should ever use classes of device. We've been down
  that route, it's a fail in and of itself. We should be using actual
 data,
  not assumed data based on some other data.
 
 
  We have abstract means of accessibility. WCAG2 explores that.
 
  We have classes of how data is accessed. It should be accessible from a
  keyboard only device.
  With touch screens, the world has been exploring more, the concept of
  accessible via pointer only (though virtual keyboards help).
 
  Keep in mind that keyboard and pointer are also two abstractions, not
  physical objects.
 
  There's a third class of accessibility, and that's programmatic access.
  Ensuring that the DOM has sufficient information that

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.


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.


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.


It also applies to desktop. There are many instances of sites that have 
a downsampled image, which you can then click to get a higher resolution 
version.


It'd be a nasty thing to have to change my system resolution settings 
because someone thought it would be funny to serve me up small versions 
of images based on my browser zoom or screen resolution.


I'm all for exposing data. I had a very public tantrum about 
devicePixelRatio; Microsoft exposes it directly,
WebKit exposes it inadvertently, Mozilla exposes it via CSS selectors 
(needing about 15 lines of css).



While I am for exposing data, I'm just not seeing this idea of exposing 
all css media attributes.
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.
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.



-Charles

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.  That's pretty intrusive UI...  and I'm not a UI designer.


Just wait until UAs start shipping with JS disabled for certain domains by 
default, just like they're already shipping with other capabilities turned on 
or off with certain domains by default.


I browse with NoScript and regularly come across people that haven't coded 
site's responsibly (it drives me nuts). While I applaud this notion because 
it'll bring more attention to the issue - i highly doubt it'll have any impact 
on the larger spectrum of sites. JS is now relied on and if certain UA's 
deliver a broken web-page to users, the users are just going to blame the 
software, not the website. Why? Because the site works in every *other* 
browser, including their old ones...


I did say certain domains.  Think script disabled for Facebook Like 
buttons by default.  ;)



They should be. But at the same time a hell of a lot of people have read that 
FaceBook watches their every move, and yet happily continue to use it. Users 
don't weigh the issue in the same way we do.


A lot of them don't true.


Agreed! It's still my inclination to default to more permissive things though. 
If people build poor sites, users stop going, the site fails, and either the 
author learns (I hope) or switches to a job with less requirement on skill 
level. It's like in business - if you're not providing a decent product, you 
don't survive. The government doesn't just disallow people from making rubbish 
with the resources they have.


A problem comes when too big to fail sites are coded somewhat 
incompetently.  Things like Google's web properties, Yahoo, Microsoft, 
eBay.  Heck, CNN (which is coded _very_ incompetently, imo).  For sites 
like that, the user is more likely to switch browsers or even devices 
than to use a different site...  Sometimes there is no different site: 
if MSDN breaks in your browser, what alternate documentation repository 
will you use, exactly?  If you use gmail and it breaks in your browser, 
then what?


Plenty of people have been producing websites of  varying quality 
... for a decade or more and surviving just fine.



In that case I completely agree. But the answer is educate them to test the 
right thing.


This is a _huge_ undertaking.  We (Mozilla) don't have the manpower for 
it; we've done evangelism and education in the past, and it's _very_ 
labor-intensive.  Opera has literally dozens of people working full-time 
on this sort of thing and they say they don't really have the manpower 
for it either.


The real answer needs to be to build things that are easier to use right 
than to use wrong, because developers will almost always choose the path 
of least resistance.  And I can't blame them.



Ooo, interesting. OK, doesn't SPDY allow pushing content and open connections? 
Can't we hijack that? And, given that any and all new info is triggered by a 
request of some sort, why wouldn't the browser send updated headers with those 
requests? (Again, may be a daft question, I am not familiar with how this stuff 
works on any real level of detail)


I'm not familiar enough with SPDY to comment intelligently.


Interesting example. OK, how could this be fixed? Could hooks not be provided 
for JS so that the site author could watch for these changes and re-request as 
needed?


That might be the right way to go, yeah...  Now we're getting somewhere.  ;)

-Boris

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

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 pixelation at zooms
higher than one CSS pixel.


I don't think that's expected if your initial zoom level maps a single 
CSS px to multiple device pixels.  If my device runs at 300dpi by 
default, I should be able to zoom in 3x or so before any pixelation 
happens, I'd hope.


-Boris

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

2012-02-07 Thread Kornel Lesiński

On Tue, 07 Feb 2012 21:17:22 -, divya manian divya.man...@gmail.com  
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.
* battery time: network requests are a drain on battery life, if I
know before hand, I can make sure the user gets information in time.


I understand you'd like to provide most appropriate images, but why do  
*you* have to exactly decide which is used when? Everybody is going to  
make basically same decisions: if network is slow, use smaller image. If  
network is fast and device is high-DPI, use larger image, etc.


So instead of requiring every server to reinvent essentially the same  
logic, why not have it in the browser? Browsers can query all the details  
of the system without any privacy risks or network overheads.


You could just say I've got these image sizes available, choose which one  
suits you best, and browser would pick one that makes most sense. You  
(and every other web developer) wouldn't have to write and maintain code  
for computation of bandwidth/latency/battery/screen size/density/zoom/cpu  
speed/memory tradeoffs. With so many variables I'm afraid that average  
developer wouldn't make better choices than mobile browsers themselves can.



* notification of change of any of these: so I can provide scaled up
experiences when these alter.


With HTTP that would require browser to re-send requests for the page and  
assets just in case server would make a different decision, and if  
difference wasn't big enough to change server's decision, then energy to  
wake up cell radio and bandwidth to send requests would be wasted (e.g.  
cost of keeping server informed about often-changing zoom level could  
easily outweigh savings from reduced images).


OTOH if client was given information on what variants of resources are  
available, then it could cheaply re-check conditions when cell radio is  
off and only connect when necessary and only request files that have  
changed substantially.


--
regards, Kornel Lesiński

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

2012-02-06 Thread Charles McCathieNevile


On Mon, 06 Feb 2012 14:50:03 +0100, Matthew Wilcox
m...@matthewwilcox.com 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 connection than it is over HTTP.

As for how useful it is - it's very very useful. Traditionally I don't
think the requirement to adapt content assets to device capability has  
been

that important, because other methods were available (including the
god-awful mess of the UA string). That's going to be less and less useful
as the variety of devices continues to balloon and the UA string becomes
less and less sane.

We need the server to know about the device. We need headers.


I'm pretty sensitive to Henri's argument that it's easy to add headers we
think will be useful, when they really won't. They are still a pretty
expensive part of the transaction, especially for mobiles.

If you want them anyway, you might like to look at the Device Description
Repository work W3C did, building on the lessons learned from doing CC/PP,
UAProf, WURFL, because the mobile web [had/was about to] reached the
point where this capability was really important.

More to the point I thin it is clear that developers want to know how to  
adapt their content to the user's device (rather than trying to adapt the  
user to buy the device they coded for which I think many people here would  
agree is a really bad thing to encourage).


There is also the approach of knowing what capabilities you have from
within the page itself. Again there is a long history of this, including
media queries, the generally loathed hasFeature in DOM and the more common
if (navigator.something) approach that is widely used instead, and so on.

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

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 written about as well as myself.

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? That's the thing people keep seeming to
miss. Also, as indicated, with SPDY this is much much less of a problem
than for HTTP.

More to the point I thin it is clear that developers want to know how to
adapt their content to the user's device

Absolutely, which is what this is about. There are two use cases - one is
client side and one is server side. They seem to answer the same equation
but they do not. We need both, and we can't do *reliable* sever adaption
without *reliable* client feature-set reporting. Which we can't get any way
we try right now, and there are many approaches tried - JS, cookies, and UA
sniffing. None are bullet-proof, and all are merely ways of attempting to
*Guess* what a browser header could explicitly tell us. Which is why
headers are wanted.

To be honest I think this is more a browser thing than  anything. I don't
see any problem with browsers behaving exactly as they do now, but
listening out for a server response header that in turn requests the
browser to append certain headers with all requests to the domain. I.e.,

1) client asks for spdy://website.com
2) server responds with content and adds a request bandwidth  device
screen size header
3) client then appends these headers to all future requests on the domain.
4) server can push any amended content from 2) over SPDY without another
request (because SPDY can).

This way there are no additional overheads unless the server has requested
them specifically.


-Matt

On 6 February 2012 15:38, Charles McCathieNevile cha...@opera.com wrote:

 On Mon, 06 Feb 2012 14:50:03 +0100, Matthew Wilcox
 m...@matthewwilcox.com 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 connection than it is over HTTP.

 As for how useful it is - it's very very useful. Traditionally I don't
 think the requirement to adapt content assets to device capability has
 been
 that important, because other methods were available (including the
 god-awful mess of the UA string). That's going to be less and less useful
 as the variety of devices continues to balloon and the UA string becomes
 less and less sane.

 We need the server to know about the device. We need headers.


 I'm pretty sensitive to Henri's argument that it's easy to add headers we
 think will be useful, when they really won't. They are still a pretty
 expensive part of the transaction, especially for mobiles.

 If you want them anyway, you might like to look at the Device Description
 Repository work W3C did, building on the lessons learned from doing CC/PP,
 UAProf, WURFL, because the mobile web [had/was about to] reached the
 point where this capability was really important.

 More to the point I thin it is clear that developers want to know how to
 adapt their content to the user's device (rather than trying to adapt the
 user to buy the device they coded for which I think many people here would
 agree is a really bad thing to encourage).

 There is also the approach of knowing what capabilities you have from
 within the page itself. Again there is a long history of this, including
 media queries, the generally loathed hasFeature in DOM and the more common
 if (navigator.something) approach that is widely used instead, and so on.

 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

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 it is


-Boris

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 to given devices.

The problem with using viewport instead of device size is client-side
caching. It completely breaks things. As follows:

1) The user requests the site with a viewport at less than the device
screen size.
2) The user browses around for a bit on a few pages.
3) The user maximises their browser.
4) All of the images now in the browser cache are too small.

How does the client know to re-request all those pre-cached images, without
making an arduous manual JS-reliant cache manifest? Or without turning off
caching entirely?

The solution is to send an image that is as large as the device will ever
need, not for the current viewport.

Yes, this isn't ideal, but it solves the problem and it solves it very well
for small devices whilst maintaining client-side caching. There's very
little difference in file weight between an image 320px wide and one 480px
wide, so the overhead of supporting landscape even if you're currently only
at portrait isn't anywhere near as great as un-negotiated content. Nor does
it require new HTTP requests on orientation change, which would be a
terrible experience whereby the page that WAS readable suddenly ends up
re-flowing and re-loading assets just because you've increased the window
size.



On 6 February 2012 16:00, Boris Zbarsky bzbar...@mit.edu 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 page.
  We should not be encouraging people to think that it is

 -Boris

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

2012-02-06 Thread James Graham


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 
page. We should not be encouraging people to think that it is


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 viewport dimensions, it is 
not that probable and, only one of the two is likely to be resized.


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 subset of the backend work (database queries + etc.) and 
transfer a subset of the full data. At the moment this is possible, but 
you pay for it with an extra RTT (at least as far as I can tell). I am 
sympathetic to the view that it would be desirable to be able to 
minimise the cost of generating a reduced-functionality page without 
burning the savings on extra round trips.

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

2012-02-06 Thread Nils Dagsson Moskopp

Matthew Wilcox m...@matthewwilcox.com 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
http://dieweltistgarnichtso.net

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 pixel is not an invariant (e.g. it changes on 
zoom in some browsers).


2)  Devices (including laptops) can be docked and otherwise have 
external screens connected to them.


Point 1 above means that the user zooming your page will change the 
screen size as perceived by the page.



*Viewport* size is what we shouldn't be using


Viewport size has the additional constraint that viewports can also be 
resized by users.  But you shouldn't be using any of these.  Depending 
on what you're using it for, of course...  What _are_ you trying to 
use it for?



The problem with using viewport instead of device size is client-side
caching. It completely breaks things. As follows:

1) The user requests the site with a viewport at less than the device
screen size.
2) The user browses around for a bit on a few pages.
3) The user maximises their browser.
4) All of the images now in the browser cache are too small.

How does the client know to re-request all those pre-cached images,
without making an arduous manual JS-reliant cache manifest? Or without
turning off caching entirely?


If we posit that we're putting the viewport size information in an HTTP 
header, a server would simply send the appropriate Vary header in its 
response.  Then the client would know that its cached content is no 
longer valid if the request header it's about to send doesn't match what 
it sent when it received the cached content.  So this is not a problem 
per se.


The problem, again, comes with viewport and screen size changes while a 
page is loaded, not across page navigations.



The solution is to send an image that is as large as the device will
ever need


Whatever that means.  How would you even determine this?


Yes, this isn't ideal, but it solves the problem and it solves it very
well for small devices whilst maintaining client-side caching. There's
very little difference in file weight between an image 320px wide and
one 480px wide, so the overhead of supporting landscape even if you're
currently only at portrait isn't anywhere near as great as un-negotiated
content.


Except you get screwed (or more precisely show a crappy grainy image) if 
the user actually zooms in on their device, no?


-Boris

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 viewport dimensions, it is
not that probable and, only one of the two is likely to be resized.


It's very probable that a mobile or tablet screen will be zoomed in 
various ways.  People do this all the time.



A typical thing that people want to do is to deliver and display *less*
content in small (measured in arcseconds) screen scenarios.


This assumes that the entire page is onscreen at once, which is a pretty 
bad assumption for said scenarios.


I feel like I must be missing something pretty fundamental here.  Either 
said people are assuming users never use zoom-and-pan type controls on 
their devices or there's something more complicated going on.  What am I 
missing?



I am sympathetic to the view that it would be desirable to be able to minimise 
the cost
of generating a reduced-functionality page without burning the savings
on extra round trips.


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


-Boris

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

2012-02-06 Thread Glenn Maynard

On Mon, Feb 6, 2012 at 9:52 AM, Matthew Wilcox m...@matthewwilcox.comwrote:

 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 pay the
cost for someone else's savings.  Find an approach that doesn't introduce a
cost to every HTTP request made by every browser.

That's not the only problem here--screen size isn't enough, you need to
know the device's effective DPI, as well as the issues Boris points out,
and there are probably tons of other details--but it's the biggest.

-- 
Glenn Maynard

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

2012-02-06 Thread Ryosuke Niwa

On Feb 6, 2012 9:04 AM, Boris Zbarsky bzbar...@mit.edu 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 same site on
 desktop and mobile set up to have the same viewport dimensions, it is
 not that probable and, only one of the two is likely to be resized.


 It's very probable that a mobile or tablet screen will be zoomed in
various ways.  People do this all the time.


 A typical thing that people want to do is to deliver and display *less*
 content in small (measured in arcseconds) screen scenarios.


 This assumes that the entire page is onscreen at once, which is a pretty
bad assumption for said scenarios.

 I feel like I must be missing something pretty fundamental here.  Either
said people are assuming users never use zoom-and-pan type controls on
their devices or there's something more complicated going on.  What am I
missing?

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.

 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.

- Ryosuke

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

2012-02-06 Thread Nils Dagsson Moskopp

James Graham jgra...@opera.com 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 subset of the backend work (database queries +
 etc.) and transfer a subset of the full data. At the moment this is
 possible, but you pay for it with an extra RTT (at least as far as I
 can tell).

 I am sympathetic to the view that it would be desirable to
 be able to minimise the cost of generating a reduced-functionality
 page without burning the savings on extra round trips.

An argument into the opposite direction can be that making it easier to
create reduced-functionality pages fragments the web. Say, why should
mobile pages have different semantics, not just different layout and
usability?

-- 
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net

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

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

2012-02-06 Thread Charles McCathieNevile


On Mon, 06 Feb 2012 18:33:56 +0100, Ryosuke Niwa rn...@webkit.org wrote:


On Feb 6, 2012 9:04 AM, Boris Zbarsky bzbar...@mit.edu 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

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

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

2012-02-06 Thread Irakli Nadareishvili

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

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


On Mon, 06 Feb 2012 17:44:30 -, Boris Zbarsky bzbar...@mit.edu 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

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

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 bzbar...@mit.edu 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

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

2012-02-06 Thread Ashley Sheridan

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

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

2012-02-06 Thread Ashley Sheridan

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 bzbar...@mit.edu 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

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


On Mon, 06 Feb 2012 18:58:00 -, Boris Zbarsky bzbar...@mit.edu 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

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

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

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

2012-02-06 Thread Irakli Nadareishvili

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 image, css and 
javascript optimizations that need to happen on server-side can happen based on 
that information. Everything else (including things related to turning 
orientation or changing window size) are already covered by media queries in 
CSS3.

This is so much so that, in our discussion on the Firefox forum, it was 
suggested that maybe browsers just report device class: 
https://support.mozilla.org/en-US/questions/917322

This could be a great solution for all purposes, with one caveat: logic for 
which devices should belong to which category may change and whether browser 
vendors can adapt quicker or it's better if they provide raw data and let 
server developers adapt their server-side code, is debatable.

Hope this clarifies the intent of the request/proposal.

Thank you,

Irakli

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


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

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-level fashion 
to determine a class of the device: smartphone, tablet, desktop.


If that's the information you need to know (why, exactly?), why not just 
send _that_ information instead of various proxies like device screen size?


Incidentally, what class is this device: 
http://eee.asus.com/en/eeepad/transformer/specification/ ?


It has a 10 touchscreen, 1280x800 device resolution, and an optional 
keyboard.  Is this a tablet or a desktop?


Compare to the 11 version of http://www.apple.com/macbookair/specs.html 
(which has a pretty similarly sized non-touch, for now, screen and 
similar resolution; the aspect ratio is 16:9 for this device and 16:10 
for the Asus device above).  Presumably this device is uniformly 
classified as a desktop by everyone attempting such classifications?



There is no need for exact viewport state.


OK.  Then what state do you need, exactly, and why?


This is so much so that, in our discussion on the Firefox forum, it was 
suggested that maybe browsers just report device class: 
https://support.mozilla.org/en-US/questions/917322


This would be a lot more useful than trying to guess device class 
based on proxies like screen size.  It would, in particular, allow the 
UA to claim that the Asus device above is a desktop if that leads to a 
better user experience.  Or to claim that the Macbook Air is a tablet, 
especially when it grows a touchscreen.



This could be a great solution for all purposes, with one caveat: logic for 
which devices should belong to which category may change and whether browser 
vendors can adapt quicker or it's better if they provide raw data and let 
server developers adapt their server-side code, is debatable.


I may be biased, but I think the browser has a much better idea of 
device class than you can infer from a screen size.



Hope this clarifies the intent of the request/proposal.


Well, it clarifies that I understood it correctly

-Boris

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 bzbar...@mit.edu 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

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

2012-02-06 Thread Irakli Nadareishvili

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 time) we need to send 
lower-resolution or resized versions of high-resolution images that would be 
sent to desktop clients. The best way to do it is if markup referred to an 
image resource with single URL and server, depending on header information, 
sent different crop or resolution of the image to different classes of devices.

The two underline assumptions here are: it's much easier to detect device type 
than quality of network connection. It's also more correct because small-screen 
devices do not need high-def images even if they can download them fast.

2. Adaptive CSS/Javascript.

Most websites use CSS/JS aggregation. Different devices need special CSS/JS 
code. For instance, touch-screen devices need all kinds of libraries like 
jqueryMobile. Likewise, Desktop experience may need large javascript libraries 
that are not needed on smart-phones. If server could easily detect device 
type/capabilities it would have the ability to tailor aggregated js/css files 
to a class of a device, thus providing greatly improved experience.

I am sure there are other use-cases that could benefit from improved device 
type/capability detection. After all, that's exactly why people have put 
enormous effort in projects like WURFL. Alas, WURFL is not accurate enough or 
easy enough to use. Hence the motivation for the proposal to ask browsers help 
with the effort.

Thank you

Irakli

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

2012-02-06 Thread Charles Pritchard

On Feb 6, 2012, at 11:49 AM, Boris Zbarsky bzbar...@mit.edu wrote:

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

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

2012-02-06 Thread Ryosuke Niwa

On Mon, Feb 6, 2012 at 11:08 AM, Ashley Sheridan
a...@ashleysheridan.co.ukwrote:

 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

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

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

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 bzbar...@mit.edu
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.

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

2012-02-06 Thread James Graham


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.

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

2012-02-06 Thread Charles Pritchard

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 image nodes to prevent them 
from blocking my onload. Works fine.


-Charles



On Feb 6, 2012, at 12:16 PM, Matthew Wilcox m...@matthewwilcox.com wrote:

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

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

2012-02-06 Thread Charles Pritchard





On Feb 6, 2012, at 12:20 PM, James Graham jgra...@opera.com 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 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.


It'd be nice to have those requirements on the desktop as well! Doesn't this 
fall into the first bucket?

I'm sympathetic, and I do understand many developers have a goal of using 
pure-CSS. That said, for the past couple years I've stuck with the concept that 
onresize and onload are sufficient. Though some hacks are needed to get dpi 
ratio; on the desktop, Microsoft's window.screen extensions are the only ones 
to just expose the data in a nice manner.

I think this issue is about a deficiency in HTML markup semantics. I've not had 
an issue on TV, Handheld and desktop, when I'm scripting.

One slightly related example: big PDF documents. PDF can be loaded in chunks, 
streamed. I think that Ace (was Bespin) handles chunking of large documents.

We all remember when mobile phones used gateways or otherwise split documents 
into several pages. It seems relevant to understanding the scope or the problem.


-Charles

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 
sent to desktop clients. The best way to do it is if markup referred to an 
image resource with single URL and server, depending on header information, 
sent different crop or resolution of the image to different classes of devices.


OK, so just to make sure I understand:

1)  You want to use device class as a proxy for connection speed.
2)  You want to use device class as a proxy for size the user will be 
able to see the image at.  Users who zoom, or save your page to a PDF 
for later viewing or printing, screw them, right?



The two underline assumptions here are: it's much easier to detect device type 
than quality of network connection.


If you sufficiently restrict your definition of device type, perhaps.


It's also more correct because small-screen devices do not need high-def images 
even if they can download them fast.


Why not?  Every single such device allows users to zoom.  Many allow the 
user to send the image on to other media (external monitors, PDFs, etc) 
where they may well want high-def images.


I think that you're assuming particular usage patterns for these devices 
which may even be true today but that we don't necessarily want to lock 
into the architecture of the web.



Most websites use CSS/JS aggregation. Different devices need special CSS/JS 
code. For instance, touch-screen devices need all kinds of libraries like 
jqueryMobile. Likewise, Desktop experience may need large javascript libraries 
that are not needed on smart-phones. If server could easily detect device 
type/capabilities it would have the ability to tailor aggregated js/css files 
to a class of a device, thus providing greatly improved experience.


I agree this is a use case worth addressing.

Please tell me which device class your server would like to put 
http://www.lenovo.com/products/us/desktop/ideacentre/a-series/a700?cid=us|disp|badg|pcmag|display_dr|21620dfaid=1 
and why (summary for those not wanting to read the specs: it's a desktop 
system with a 23 touchscreen running at 1920x1080, with the system 
itself built into the base of the screen; similar to modern iMacs, but 
with a touchscreen).  Which JS libraries would you send or not send to 
this device based on its screen size and the fact that it's obviously a 
desktop?


It seems to me, honestly, that given the current state of the market the 
main effect of guessing about device classes and sending them different 
content, as opposed to directly detecting the device capabilities you 
really care about one way or another, will just lead to you sending the 
wrong content to devices as the lines between device classes blur more 
and more.


I do think there are classifications that are worth making between 
devices so as to adapt your content to them, but the primary one I care 
about (is this device running on a battery right now?) is not one I've 
even heard anyone mention...  and has nothing to do with device class, 
except insofar as tablets and phones are almost always doing that while 
desktops (but not laptops) are almost never doing that.



I am sure there are other use-cases that could benefit from improved device 
type/capability detection. After all, that's exactly why people have put 
enormous effort in projects like WURFL.


Quite honestly, as far as I can tell a major reason people have put a 
lot of effort into things like WURFL because so many phones shipped with 
completely broken browsers for so long...  So you needed a big database 
just to figure out how the browser was going to screw up your content


This is clearly not a concern for new proposals, right?

Again, I agree that exposing device capabilities would be useful.  I 
think that if people are going to infer things like device class from 
screen size and things like level of support for touch interfaces from 
device class, then exposing the capabilities would actually be worse 
for users because sites would get things wrong so often.


-Boris

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


How so, exactly?


We adjust for physical pixels quite happily by specifying a width on the image.


The width you specify is in CSS pixels.  If the device is running at 
200dpi, and you specify a 100px width for your image, it'll make the 
image 200 device pixels wide.



They're then down sampled into physical pixels even though CSS is using CSS 
pixels.


You assume downsampled, but it can just as easily be upsampled.

But again, my point was that the width of the screen in CSS pixels is 
not an invariant.  If you set your image to be 100px wide, then on the 
very same device it can be all sorts of fractions of the width of the 
screen, depending on UA settings.


-Boris

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 such that this information is at the top in both 
versions and the less-critical information is effectively below the fold 
on mobile?  I realize that this may be more work and that there may be 
other constraints here, but it seems like that would be ideal in this 
situation.



3) No looking up / transfering information that would later be thrown away


Again, this seems to apply to desktop as well.


4) Fast = No extra round trip to report device properties


Agreed that this is desirable.

This really does seem like an instance of my bucket #1 (Why isn't the 
desktop version just like this vastly better mobile one?).


-Boris

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

2012-02-06 Thread Kornel Lesiński

On Mon, 06 Feb 2012 20:00:45 -, Irakli Nadareishvili  
ira...@gmail.com 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 connected to high-speed networks. Laptops can be  
tethered via mobile networks.


There are many permutations of screen size, DPI, zoom, network speed,  
bandwidth cost and memory availability that influence decision what image  
resolution is best, and it's not as simple as mobile vs non-mobile.



There aren't even clear device classes. Basic device characteristics  
like physical screen size and presence of a hardware keyboard can change  
dynamically!


Smartphones can be connected to TVs and projectors. Tablets can be  
connected to keyboards. Laptops can be flipped into tablet mode. Desktops  
can have touchscreens — and these aren't obscure things. It's iPad with  
AirPlay and dock. It's most tablet PCs. You can expect many laptops to  
have touchscreens soon.


Mobile or smartphone can mean anything from Opera Mini on GPRS  
connection to a quad-core 4G smartphones more powerful than desktops were  
few years ago.



I appreciate optimisations you're trying to make, but simply reporting  
basic capabilities in an HTTP header isn't going to work well in other  
than few most common cases.


I hope we could come up with a better solution that can all the  
optimisations and improved experience you want to achieve, but doesn't  
have pitfalls of assuming that slow networks and touch screens go  
hand-in-hand, or that devices with keyboards also have mouse and  100dpi  
screen, etc.




2. Adaptive CSS/Javascript.


CSS has media queries already. New queries can (and I think should) be  
added to query more capabilities like presence of a touch screen (Mozilla  
experiments with -moz-touch-enabled media query already).


Media queries are dynamic and can be observed by JavaScript, so when you  
switch from tablet's own touch screen to an external display, pages could  
theoretically switch UI too.


If server could easily detect device type/capabilities it would have the  
ability to tailor aggregated js/css files to a class of a device, thus  
providing greatly improved experience.


Sure, but it doesn't mean that the server has to do that and that it's the  
only way to do that. For example:


script src=touch-ui.js media=input-type: touch
script src=mouse-ui.js media=input-type: mouse

(although I'm not suggesting using that form literally, as it has some  
drawbacks of its own)


Next version of JavaScript is going to have modules, which makes loading  
of JavaScript cleaner than script. Perhaps modules could be loaded  
conditionally based on media-query-like declarations?


--
regards, Kornel Lesiński

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

2012-02-06 Thread Ashley Sheridan

On Mon, 2012-02-06 at 22:16 +, Kornel Lesiński wrote:

 On Mon, 06 Feb 2012 20:00:45 -, Irakli Nadareishvili  
 ira...@gmail.com 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 connected to high-speed networks. Laptops can be  
 tethered via mobile networks.
 
 There are many permutations of screen size, DPI, zoom, network speed,  
 bandwidth cost and memory availability that influence decision what image  
 resolution is best, and it's not as simple as mobile vs non-mobile.
 
 
 There aren't even clear device classes. Basic device characteristics  
 like physical screen size and presence of a hardware keyboard can change  
 dynamically!
 
 Smartphones can be connected to TVs and projectors. Tablets can be  
 connected to keyboards. Laptops can be flipped into tablet mode. Desktops  
 can have touchscreens — and these aren't obscure things. It's iPad with  
 AirPlay and dock. It's most tablet PCs. You can expect many laptops to  
 have touchscreens soon.
 
 Mobile or smartphone can mean anything from Opera Mini on GPRS  
 connection to a quad-core 4G smartphones more powerful than desktops were  
 few years ago.
 
 
 I appreciate optimisations you're trying to make, but simply reporting  
 basic capabilities in an HTTP header isn't going to work well in other  
 than few most common cases.
 
 I hope we could come up with a better solution that can all the  
 optimisations and improved experience you want to achieve, but doesn't  
 have pitfalls of assuming that slow networks and touch screens go  
 hand-in-hand, or that devices with keyboards also have mouse and  100dpi  
 screen, etc.
 
 
  2. Adaptive CSS/Javascript.
 
 CSS has media queries already. New queries can (and I think should) be  
 added to query more capabilities like presence of a touch screen (Mozilla  
 experiments with -moz-touch-enabled media query already).
 
 Media queries are dynamic and can be observed by JavaScript, so when you  
 switch from tablet's own touch screen to an external display, pages could  
 theoretically switch UI too.
 
  If server could easily detect device type/capabilities it would have the  
  ability to tailor aggregated js/css files to a class of a device, thus  
  providing greatly improved experience.
 
 Sure, but it doesn't mean that the server has to do that and that it's the  
 only way to do that. For example:
 
 script src=touch-ui.js media=input-type: touch
 script src=mouse-ui.js media=input-type: mouse
 
 (although I'm not suggesting using that form literally, as it has some  
 drawbacks of its own)
 
 Next version of JavaScript is going to have modules, which makes loading  
 of JavaScript cleaner than script. Perhaps modules could be loaded  
 conditionally based on media-query-like declarations?
 


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 wireless connection. Just because
someone is using a mobile device, it doesn't naturally mean they are on
the move.
-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk

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 wireless connection. Just because
someone is using a mobile device, it doesn't naturally mean they are on
the move.


And even if you are on the move, EVDO rev B is in the 5-15 Mbit/s range, 
and HSPA+ services that deliver 28 Mbit/s are on the market right now, 
with theoretical peak bandwidth for the standard closer to either 84 
Mbit/s or 168Mbit/s depending on the hardware configuration.


A real problem with network performance on many cell networks is not the 
bandwidth, which is at least comparable to basic DSL, but latency.  Of 
course for latency issues image size is a smaller problem, and desktops 
on sattelite connections have latency issues of their own


-Boris

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

2012-02-06 Thread Ryosuke Niwa

2012/2/6 Kornel Lesiński kor...@geekhood.net

 On Mon, 06 Feb 2012 20:00:45 -, Irakli Nadareishvili ira...@gmail.com
 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 connected to high-speed networks. Laptops can be
 tethered via mobile networks.


Right.  When I had a smart phone, it was on WiFi 90%+ of the time because
I'm either at work or at home although I browsed on the phone when I was on
move disproportionally more than I was at work or home.

I appreciate optimisations you're trying to make, but simply reporting
 basic capabilities in an HTTP header isn't going to work well in other than
 few most common cases.

 I hope we could come up with a better solution that can all the
 optimisations and improved experience you want to achieve, but doesn't have
 pitfalls of assuming that slow networks and touch screens go hand-in-hand,
 or that devices with keyboards also have mouse and  100dpi screen, etc.


I'm totally with you. While I do sympathize with the view that we need some
ways to let servers figure out which resource to be sent and how it should
be sent, I don't think web developers should be making such decisions
solely based on the types of devices they're serving.

On Mon, Feb 6, 2012 at 2:30 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 And even if you are on the move, EVDO rev B is in the 5-15 Mbit/s range,
 and HSPA+ services that deliver 28 Mbit/s are on the market right now, with
 theoretical peak bandwidth for the standard closer to either 84 Mbit/s or
 168Mbit/s depending on the hardware configuration.

 A real problem with network performance on many cell networks is not the
 bandwidth, which is at least comparable to basic DSL, but latency.  Of
 course for latency issues image size is a smaller problem, and desktops on
 sattelite connections have latency issues of their own


On the other hand, mobile networks tend to have a huge variance on the
packet loss rate (sometimes 100% if the user is moving into an elevator)
and websites need to behave differently, e.g. cache more images on Map app.

On that note, it might be more useful to add a header indicating that
they're on slow network, mobile network, and such although it might be
better for servers to auto-detect latency and bandwidth for that kind of
use cases.

- Ryosuke

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