[whatwg] Processing the zoom level - MS extensions to window.screen

On 11/24/2010 2:45 PM, Aryeh Gregor wrote:
> On Wed, Nov 24, 2010 at 4:38 PM, Charles Pritchard<chuck at jumis.com>  wrote:
>> I greatly appreciate the value of standards, but I am at the same time, very
>> sensitive to the effects that centrally planned restrictions have on groups.
>> The aggregate effect is one where tens of millions are harmed by the
>> decisions of a few people in authority. I'd rather see the masses harmed by
>> themselves than by authority.
> There are two "masses" here: authors and users.  You advocate giving
> total control to authors, but that comes at the expense of taking
> control away from users.  The web platform is designed to favor users'
> needs over authors' needs.  Websites are all forced to have a lot in
> common: you can zoom the same way, copy and paste the same way,
> navigate the same way, and so on.  This is part of why the web
> platform is better for users than, say, Java applets -- it does *not*
> give authors total control.
I've not advocated an all-or-nothing approach, and I continue to stand 
my groun dthere.

I'm advocating allowing authors to access two vital bits of information, 
which could
pragmatically be exposed with a minimum of programming hours on the part 
of browser vendors.

You can't zoom in the same way.  innerWidth and innerHeight are 
properties that an author can choose to use or not use.

I understand working abstractions, concepts... and making generalizations.

I've not advocated allowing an untrusted script to set the zoom level 
nor "over-ride" the
zoom controls which are completely outside of the DOM and window frame.

The web platform is better for users than Java because it's more open. 
There is no "definite" web platform,
there are collection of standards, and a growing consensus about which 
standards are vital to implementation.

> So in fact, one of the many little things that makes the web platform
> nice is how users can zoom easily.  For a small percentage of users,
> this is essential.  A typical author has few users and will get no
> complaints if they mess up zooming, but a browser has tens of millions
> to billions of users and will definitely get complaints if the browser
> adds a feature that lets even one percent of sites mess up zooming.
> It's then up to the few browsers to fix the problem, because you'll
> never get millions of authors to all do it.  How will the browsers fix
> the problem?  Probably by making the feature useless, like by making
> it do nothing or return false values.  Then you're better off having
> never added the feature in the first place.
Lets?

First, the feature is being made available by other browser vendors.
Second, "Lets?"... If the browser lets a site crash the window, pop up 
multiple tabs, or otherwise cause a DOS, that's a big issue.

But it is not the UAs responsibility to make sure that a middle school 
student uses <img alt=""> tags correctly.

Lets keep on the topic at hand: exposing a minimum amount of data for 
authors
who want to use that data.

There is no existing evidence that masses of programmers reading the 
Documentation on how
to use screen metrics will make mistakes in any substantial number. It's 
pure conjecture.

There are existing use cases, of using the data correctly, and of the 
data being exposed intentionally.

There are also existing cases of zoom being mishandled, through the 
misapplication of innerWidth and innerHeight.

So if we can get off the generalizations, and simply look at the merits 
of the concept,
we can move onto looking at the merits of existing proposals and practices.

Until then, we're stuck in arguments which have very little to do with 
the technical data at hand.

> That's the point of the concern over author misuse.  If authors misuse
> a feature enough to affect even a small percentage of users, browsers
> will compete to fix it if possible.  Consider pop-up ads -- browsers
> now all block those, taking control away from authors for the benefit
> of users.  Or consider the px unit, which in practice doesn't
> necessarily have anything to do with pixels anymore.  We don't want to
> add a feature to the platform if it will have to just be disabled when
> a significant number of authors use it.  (Whether this is the case for
> some *particular* feature, like exposing zoom info, is of course a
> separate question.)
We're considering the second item. Right now.

And man am I happy with vendors realizing that denial of service IS 
their responsibility.

If mozilla wants to add a permissions setting to say "Reset stylesheets, 
don't allow access to zoom info",
or otherwise "don't run ads, etc etc", that's fantastic. That's a great 
place to have competition.

There's no reasonable case for blocking those of us with mature and 
experienced judgment, from accessing data which
would otherwise be visible, if it weren't for all those  "new" 
programmers who might set themselves aflame.

At present, I have not seen an actual argument based on evidence here. 
We're using prior examples
and trying to draw analogies. I'm fine engaging them, but when I have, 
I've found that they are not
sincere to the case at hand.

So again, if you want to talk about websites mishandling zoom, as things 
currently sit, without exposing
the data I want --- they do mishandle zoom. I have a poor zoom 
experience on many websites.

There's no evidence that enabling programmers to access CSS pixel data 
will harm usability.

There is evidence that it will enhance usability for programmers who use 
it properly.

Focus.

-Charles

Received on Wednesday, 24 November 2010 14:59:18 UTC