On 6 February 2012 19:24, Irakli Nadareishvili ira...@gmail.com wrote:
Boris,
if you don't mind me saying it, I am afraid you may be missing the point of
this request. In Responsive Web Design, device capabilities are used in a
high-level fashion to determine a class of the device:
On Mon, Feb 6, 2012 at 9:24 PM, Irakli Nadareishvili ira...@gmail.com wrote:
if you don't mind me saying it, I am afraid you may be missing the point of
this request. In Responsive Web Design, device capabilities are used in a
high-level fashion to determine a class of the device: smartphone,
On Wed, Feb 8, 2012 at 2:41 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Tue, Feb 7, 2012 at 11:17 PM, 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
+1 to everything Jason Grigsby just said.
If not here, where? If not with you, with who? We've been doing this
publicly for months and months...
On Tue, Feb 7, 2012 at 4:13 PM, Matthew Wilcox m...@matthewwilcox.com wrote:
Ahhh, ok. I was not aware that SPDY is intended to suffer from the flaws
inflicted by the dated mechanics of HTTP. Is it really different semantics
though? I don't see how it's harmful to enable resource adaption over
On 02/07/2012 10:19 PM, Charles Pritchard wrote:
On 2/7/2012 1:14 PM, Matthew Wilcox wrote:
Also, I am writing this on a laptop via a throttled mobile
connection.
It'd be nice if sites had the capability to adapt to that throttle
then wouldn't it...
As I read through this thread -- all
On Tue, Feb 7, 2012 at 11:17 PM, 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
People, this is really getting out of hand...
1. WHATWG is a standards body, meaning it _standardizes_ solutions.
Everyone who followed the discussion up until now can easily tell that
currently there is no unified, or even close to common approach to this
topic yet. Someone says the solution is
On Feb 8, 2012, at 8:04 AM, Ronjec Viktor wrote:
People, this is really getting out of hand...
1. WHATWG is a standards body, meaning it _standardizes_ solutions.
Everyone who followed the discussion up until now can easily tell that
currently there is no unified, or even close to common
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
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
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
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
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
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
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.
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
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
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
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
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
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?
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
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
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
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
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
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_
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
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?
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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.
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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*
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
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
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
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
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
On Mon, 06 Feb 2012 19:49:43 -, Boris Zbarsky bzbar...@mit.edu wrote:
that need not even have anything to do with HTTP. You can fetch
half the monolithic form and fetch the rest when the user has filled in
most of [the] former half.
Not without script.
Or (fragment) Accept-Ranges (so a
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
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.
On Sat, 04 Feb 2012 19:28:17 -, irakli ira...@gmail.com 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
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
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
88 matches
Mail list logo
