[whatwg] whatwg Digest, Vol 80, Issue 47 | previously: Processing the zoom level - MS extensions to window.screen

On 11/25/10 11:26 AM, Martin Janecke wrote:
> Am 25.11.2010 um 17:41 schrieb Charles Pritchard:
>
>    
>>> (2) The browsers' build-in zoom function, which web page authors have no control or information about.
>>>        
>> They have information about it, in many browsers, and they receive events related to window.innerWidth and innerHeight.
>>      
> Well, an author cannot conclude safely from these changes that the browser's zoom function has been used, can he?
>    
No, not safely: thus my attention on the issue.
>    
>> Once again, you, as many in the list, have taken a very simple use case, and generalized it into a straw man argument.
>>      
> It's not a straw man argument if the problems discussed actually follow from your proposal ? even if your wish is very different from creating these problems. I don't think people doubt your good intentions. I'm not saying you want to disturb users or misuse the browser's zoom function for something different from what it is intended for. I'm against those consequences of your proposal which you do not intend yourself.
>
> Am I wrong and these problems cannot occur? Then it's a straw man argument. Otherwise it's not.
>    
Using CSS Pixel information to control the "zoom" of a mapping 
application would not work very well: there's no method for the author 
to send a zoom event, so they could not map any of their controls to 
alter the zoom level, and the zoom level controls of the UA are 
typically limited to a few zoom levels, again making it unlikely to be 
useful.

Many problems can occur in a scripting environment.
>> 1. blurry image != good.
>> 2. Sharp image>  good.
>> 3. Sharp image != disturbed users.
>>      
> Actually, some visually impaired users are disturbed by sharp contrasts. I have a friend who is. It's something with the cornea being uneven, leading him to see multiple images of the same object which blend together better if contrasts are less sharp. Of course this isn't the general case and I agree that the majority of people will prefer sharp images to blurry ones. But I wanted to give this example anyway because it demonstrates that even with the best intentions and perfect skills, interfering with the user's client functions causes always trouble to some users. Minorities with impediments can adapt to a world that challenges them by using adequate tools. Here: their browser (settings). But this fails if web page authors react on changed settings of special tools (e.g. the user client's zoom function) by dynamically changing the displayed result to stay as what the author considers the best version.
>    
Thanks for sharing an example about sharp-contrasts. I'll be certain to 
mention it to accessibility groups in the future. It does seem like a 
use case which would be handled by the operating system (not the UA / 
website).

Yes, the best intentions can lead to unintended results. Still, authors 
are living, thinking, conscious beings. They're not machines. They are 
able to receive feedback on their applications and make adjustments for 
their user-base.

The fact that something can be abused is certainly something to 
consider, but it should not shut-down consideration of the matter. At 
this point, the matter has been shut-down on the Mozilla end, on the 
single concern that the information may be misused. To me, that's not 
the way to lead.

>> If you'd stick to my use case, instead of coming up with imaginary problems, I think we might have a discussion on merits.
>>
>> I've not asked for a single semantic of zoom to be altered. I've stated quite clearly, repeatedly, that I need to control the pixel
>> depth of bitmap data, so that zoom does not result in an unnecessarily "blurry" image.
>>      
> I understand that your goal is having zoomed images to be as sharp as a non-zoomed image would be and I think that most of the criticism is not directed against this goal but against your proposed solution to the problem. So, maybe we can see if there's an alternative approach to your goal? Sorry, I don't have a good one at hand, but I wonder whether there might be a solution along the lines of script/noscript and img-src/img-alt: Offering alternatives and letting the user's client choose what is best.
>    
CSS options are already implemented. They do not offer control to the 
scripting environment. The criticism is against unknown masses of 
incompetents, not the proposal. It's levied against the concern that 
others may not use the information properly. It's not levied against 
exposing the proposed information. There are some criticisms about how 
much information is necessary ( such as, do we need an X and Y metric )

So to say again. We have alternatives. They're deficient for the use 
case. They're also overly verbose -- in that they can not be scripted 
and so may require a lot of redundancy -- which is one of the primary 
reasons for using scripting with CSS, instead of a pure-CSS solution.

If we could move forward on this issue, we could be talking about 
font-size settings, instead of stopping cold on the very idea that CSS 
pixel metrics should be exposed to the scripting environment.
>> If a web author wants to abuse existing apis, through any reason, they're perfectly able to do that.
>>      
> Still it is better to have an API that is less likely to be abused than one that is prone to abuse and unintended misuse.
>    
I agree with that -- but in this case, we're not discussing any 
particular api, we're stopped on the very notion that the information 
should not be available to the scripting environment. There's no wiggle 
room there.

I appreciate your input. Thanks for fixing the subject line.

-Charles

Received on Thursday, 25 November 2010 13:40:12 UTC