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

Charles Pritchard chuck at jumis.com
Thu Dec 9 10:39:57 PST 2010

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.
> 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.)

So it's absolutely clear, items like this are what we'll be seeing more of:

And hopefully a little more of this:

I work with a lot of legacy compatibility. I'm used to such hacks. But 
it seems like something that could be more reasonably abstracted in the 

Note the misuse of matchMedium to "assume" that they're operating on an 
iphone when in fact it's just the browser at a higher zoom level or a 
smaller window width.

Extensions to the scripting environment would reduce errors by reducing 
coding requirements.

In the meantime, I have to brute-force media selectors. Obfuscating 
media attributes is a strange policy, but we'll follow it, if that's 
what's required.


More information about the whatwg mailing list