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

[irakli-3]

Responsive Web Design [http://bit.ly/f6TPB7] is an extremely important
approach/technique/movement for making web mobile-friendly. Given that web
mobile traffic is exploding and there were more smart-phones sold in 2011
than PCs [http://vrge.co/wqOiED] the importance of the movement can not be
emphasized enough.

We have some significant obstacles on the path of fully optimized
Responsive Web Design, however. Responsive Images (smaller images for
smaller screens to optimize download times) and optimized CSS/JS (mobile
devices don't need the same JS/CSS as desktop browsers do) are the obvious
ones.

The most optimal way to handle responsive images and optimize CSS/JS would
be on the server-side. However, server-side does not have enough
information about device capabilities, resulting in emergence of all kinds
of cruft-y solutions (e.g. using <div>'s for <img> tags etc.) that should
not exist.

However, browsers do know a lot about devices they are running on and could
pass that information to servers as part of the initial request, making it
possible for servers to get way smarter than what we have now.

Something as simple as if browsers passed along device's width/height
information as part of the initial request headers would go a very very
long way, making it possible to make a lot of intelligent decisions on the
server-side (eventually allowing "media-queries-like" systems on the
server-side).

Since some proxy servers cut-off or disable custom headers, probably the
safest way to add this is to add width/height information in the user-agent
header.

[Charles Pritchard-2]

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

For those creating web apps, aiming for universal design and/or WCAG
compliance, I strongly recommend having a window.onresize hook in
addition to the window.onload hook. Together, they give you a fast and
responsive means for asynchronous loading of your page, and support of
browser zoom as well as mobile device resolutions.

I use anywhere between two to four ranges width. For Canvas based
applications, I have to track DPI as well.

In a basic application, may use two ranges: <= 720px (or 800px) vs
larger, for width.
In a more complex application and UI, I may track both width and height.


I've seen someone get extreme, using spreadsheets to track many sizes
while trying to maintain a pure CSS environment.
While that can work for many cases, I don't think it's tenable or
advisable during development of most web applications.

When development has settled down a bit, it's an OK time to try to pull
out more of the JS logic and put it into CSS classes.

WCAG requests that sites support a 2x zoom ratio. I strongly recommend
authors test their site both at 2x zoom and at 50%. Browsers are
supporting up to 500% it appears. While I encourage pushing boundaries,
I doubt many authors will find 300 - 500% zoom levels to be achievable.
But, it's still worth seeing what things look like.

-Charles

[Bjartur Thorlacius]

Feel free to propose e.g. Accept-Media to httpbis[1]. Bandwidth
negotiation would be most useful.

Do make note of the dynamic nature of many viewports* and the fact that
user agents may wish to render resources to multiple medias. The latter
is rare enough to tolerate an extra roundtrip. Resizing viewports,
however, should ideally not require a roundtrip.

For fast resizing, UAs must obtain layouts for all possible sizes before
viewport resize. On fullscreen systems, these sizes might as few as one
or two. Thing is, user agents could lay self-contained elements out
recursively without author stylesheets.

User agents are all around much better suited to laying out
self-contained elements than authors are. User agents can dynamically
and intelligently apply new styles customized for their viewport. All
authors have to do is semantically use <nav>, <aside> and <link> (so UAs
can place them consistently) and group their content.

*Viewport: A window to which an user agent renders a document [2]

1: http://www.ietf.org/html.charters/httpbis-charter.html
2: http://www.w3.org/TR/CSS21/visuren.html#viewport

[Kornel Lesi�ski]

On Sat, 04 Feb 2012 19:28:17 -0000, irakli <irakli@...> wrote:

> The most optimal way to handle responsive images and optimize CSS/JS  
> would be on the server-side. However, server-side does not have enough
> information about device capabilities, resulting in emergence of all  
> kinds of cruft-y solutions (e.g. using <div>'s for <img> tags etc.) that  
> should
> not exist.

There are many factors that influence selection of images, and some of  
them (like zoom, available memory, screen/print media) can change after  
images are downloaded. Some factors don't depend on hardware capabilities,  
e.g. user may be roaming or exceeded bandwith allowance and thus strongly  
prefer small images even on high-end hardware.

Instead of sending a lot of information to the server, I think it would be  
better if websites declared what kinds of images are available and let  
browsers choose.

I think it's more likely that the few browser vendors will get client-side  
image selection right, than majority of websites will add good server-side  
logic that takes into account all factors. Look how hard it is for sites  
to get authenticated file downloads right — most of them use grotesque  
scripts that completely break all caching, resuming, MIME types and often  
mangle filenames. I'd be surprised if image selection scripts were any  
better. Even with a good script, it may be hard to get negotiated images  
properly served/cached via CDNs and proxies. Last time I checked presence  
of Vary header made responses non-cacheable in all major browsers, and  
that can be worse then serving wrong size.

If servers won't take into account all factors properly, then browsers  
will start lying in information they send to the server to force desired  
behavior, and capabilities header will degenerate like the User-Agent did.  
I can imagine all browsers reporting 320px to get 160dpi images, 960px to  
get 300dpi, and 1920px to get 100dpi, regardless of actual screen size.  
That starts happening with <meta viewport> and screen.width already.


OTOH giving browsers ability to select image by DPI/file size at any time  
opens up interesting possibilities, e.g. browser could load low-DPI  
versions of images necessary for initial layout of the page to show the  
complete page sooner (especially that mobile browsers show page zoomed out  
initially), and then replace images with high-DPI versions if  
bandwith/memory/user preference allows that or when user zooms in selected  
portion of the page.

On a page with lots of large images (a gallery or photoblog) browser may  
be forced to load low-DPI versions of images, even if it had enough memory  
to display each image _individually_ in high DPI, so the decision cannot  
even be made purely on per-request basis.

Given all the complexity involved, and potential for innovation in the  
browsers, I'd rather see a declarative solution in the markup (and not  
necessarily via a CSS media query, as this still keeps responsibility with  
developers, not browsers).

--
regards, Kornel Lesiński

[Boris Zbarsky]

On 2/4/12 2:28 PM, irakli wrote:
> Something as simple as if browsers passed along device's width/height
> information

This information can change between page load and page unload (and in
fact, it can change between the HTTP request being sent and the HTTP
response being received).

All passing it would do is give the server a false sense that the
information is time-invariant static.

-Boris

[Boris Zbarsky]

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

Actually, printing an already-loaded page typically can't tolerate a
roundtrip.  If nothing else, users have a tendency to try printing (or
equivalently saving as PDF) after going offline.

-Boris

[Henri Sivonen]

On Sat, Feb 4, 2012 at 9:28 PM, irakli <irakli@...> wrote:
> Responsive Web Design [http://bit.ly/f6TPB7] is an extremely important
> approach/technique/movement for making web mobile-friendly.

It may look like it's the most important thing today, but most of the
Web isn't and won't be doing it. What goes in every HTTP request
affects the number of bytes transferred for all sites, though.

Ten years ago, advertising XHTML support in every HTTP request seemed
like the most important thing. And we got a bloated Accept header. (I
was guilty of advocating that. I have learned since.) And how often
did sites care? Very, very rarely. And once IE9 finally added XHTML
support, it also added SVG-in-text/html support, which pretty much
removes the need for application/xhtml+xml. It would have made more
sense to get the major servers fixed so that Accept: */* would have
become unnecessary and then to get rid of the Accept header.

It's been less than a week sense we got rid of the Accept-Charset dead
weight (http://hsivonen.iki.fi/accept-charset/) and you are already
proposing adding more. Everyone wants to have a piece of the UA string
or the HTTP request for their idea. None of those ideas are so great
in retrospect.

We should Just Say No to any and all proposals to add more stuff to
HTTP requests.

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

[Matthew Wilcox-5]

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.



On 6 February 2012 10:27, Henri Sivonen <hsivonen@...> wrote:

> On Sat, Feb 4, 2012 at 9:28 PM, irakli <irakli@...> wrote:
> > Responsive Web Design [http://bit.ly/f6TPB7] is an extremely important
> > approach/technique/movement for making web mobile-friendly.
>
> It may look like it's the most important thing today, but most of the
> Web isn't and won't be doing it. What goes in every HTTP request
> affects the number of bytes transferred for all sites, though.
>
> Ten years ago, advertising XHTML support in every HTTP request seemed
> like the most important thing. And we got a bloated Accept header. (I
> was guilty of advocating that. I have learned since.) And how often
> did sites care? Very, very rarely. And once IE9 finally added XHTML
> support, it also added SVG-in-text/html support, which pretty much
> removes the need for application/xhtml+xml. It would have made more
> sense to get the major servers fixed so that Accept: */* would have
> become unnecessary and then to get rid of the Accept header.
>
> It's been less than a week sense we got rid of the Accept-Charset dead
> weight (http://hsivonen.iki.fi/accept-charset/) and you are already
> proposing adding more. Everyone wants to have a piece of the UA string
> or the HTTP request for their idea. None of those ideas are so great
> in retrospect.
>
> We should Just Say No to any and all proposals to add more stuff to
> HTTP requests.
>
> --
> Henri Sivonen
> hsivonen@...
> http://hsivonen.iki.fi/
>

[Matthew Wilcox-5]

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.

On 6 February 2012 10:27, Henri Sivonen <hsivonen@...> wrote:

> On Sat, Feb 4, 2012 at 9:28 PM, irakli <irakli@...> wrote:
> > Responsive Web Design [http://bit.ly/f6TPB7] is an extremely important
> > approach/technique/movement for making web mobile-friendly.
>
> It may look like it's the most important thing today, but most of the
> Web isn't and won't be doing it. What goes in every HTTP request
> affects the number of bytes transferred for all sites, though.
>
> Ten years ago, advertising XHTML support in every HTTP request seemed
> like the most important thing. And we got a bloated Accept header. (I
> was guilty of advocating that. I have learned since.) And how often
> did sites care? Very, very rarely. And once IE9 finally added XHTML
> support, it also added SVG-in-text/html support, which pretty much
> removes the need for application/xhtml+xml. It would have made more
> sense to get the major servers fixed so that Accept: */* would have
> become unnecessary and then to get rid of the Accept header.
>
> It's been less than a week sense we got rid of the Accept-Charset dead
> weight (http://hsivonen.iki.fi/accept-charset/) and you are already
> proposing adding more. Everyone wants to have a piece of the UA string
> or the HTTP request for their idea. None of those ideas are so great
> in retrospect.
>
> We should Just Say No to any and all proposals to add more stuff to
> HTTP requests.
>
> --
> Henri Sivonen
> hsivonen@...
> http://hsivonen.iki.fi/
>

[Charles McCathieNevile-2]

On Mon, 06 Feb 2012 14:50:03 +0100, Matthew Wilcox
<mail@...> 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

[Matthew Wilcox-5]

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 <chaals@...> wrote:

> On Mon, 06 Feb 2012 14:50:03 +0100, Matthew Wilcox
> <mail@...> 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
>

[Boris Zbarsky]

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

[Matthew Wilcox-5]

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

[James Graham-7]

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.

[Nils Dagsson Moskopp-2]

Matthew Wilcox <mail@...> schrieb am Mon, 6 Feb 2012
16:27:29 +0000:

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

[Boris Zbarsky]

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

[Boris Zbarsky]

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

[Glenn Maynard]

On Mon, Feb 6, 2012 at 9:52 AM, Matthew Wilcox <mail@...>wrote:

> I agree that headers are expensive. But are they expensive compared to a
> few hundred kilobytes of saved bandwidth because we were able
> to successfully negotiate content?


Yes.  The problem is the word "we".  Everyone in the world has to 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

[Ryosuke Niwa-2]

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

[Nils Dagsson Moskopp-2]

James Graham <jgraham@...> 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>