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

[Martin Janecke]

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?

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

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

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

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


Just my two cents
Martin