On 2/7/2012 11:52 AM, Matthew Wilcox wrote:
On 7 February 2012 17:59, Boris Zbarsky<bzbar...@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
