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

[Matthew Wilcox]

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