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

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


This approach makes sense to me 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 <mail at matthewwilcox.com>wrote:

> 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 <chuck at jumis.com> wrote:
> > On 2/7/2012 11:52 AM, Matthew Wilcox wrote:
> >>
> >> On 7 February 2012 17:59, Boris Zbarsky<bzbarsky at 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
> > zoom, they may be 8 feet from the screen or only 18 inches.
> >
> > The reason TVs don't work nicely with many websites is because their
> authors
> > failed to go through basic WCAG checklists.
> >
> > For instance, hulu.com is a very popular site meant for watching TV.
>  They
> > have not put in the basic work of supporting 200% zoom.
> > This is not an issue of money, or technology. They simply haven't
> attempted
> > the work. It's a failure of internal standards within their web team.
> >
> >
> >
> >>>  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.
> >>
> >>
> >> Ah, but they do. All the time. They see a UA string and guess. Badly.
> >> Catastrophically badly. Then they take their poor guess and extrapolate
> >> the
> >> info they *actually* wanted to know from it. The fact is it's being
> done,
> >> and it will contiinue to be done until there's a more reliable solution.
> >> If
> >> we supply headers, we do NOT detect the device. We supply the exact
> >> information the server is after. connection speed. etc.
> >
> >
> > Authors will continue to make bad mistakes. They are intentionally making
> > some of those bad mistakes out of bad practice.
> >
> > Instead of using a Database that's 95% accurate based on user agent, they
> > could see headers 95% of the time, maybe boosting the accuracy over the
> long
> > term.
> >
> > They're still going to make bad mistakes. It's a free web out there. And
> > every now and then, a big corporation, like Target, gets sued, when their
> > mistakes are egregious and they have legal responsibilities not to make
> > them.
> >
> > I know I'm pushing back pretty hard against this idea that screen size is
> > something the server is going to negotiate. As I do that, it occurs to
> me, I
> > don't have an issue with supplying headers informing the server that the
> > user is on a metered connection. Sure, an overcapacity cellphone network
> > might just slap that header on all requests. That's ok.
> >
> > So, if you want to have Bandwidth-Service: metered; something along those
> > lines, that'd be just fine with me.
> > Adding headers like Max-Screen-Size: 1024x780 as a standard practice is
> not
> > something I'm ok with. It's fine for internal use (slap it in your XHR
> > requests), but not as a general web browser thing.
> >
> >
> > -Charles
>



-- 
Take care,
Tim

---------------------------------------------
http://twitter.com/tkadlec
http://timkadlec.com

Received on Tuesday, 7 February 2012 13:30:03 UTC