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

Received on Tuesday, 7 February 2012 12:24:23 UTC