[whatwg] whatwg Digest, Vol 80, Issue 47

[Charles Pritchard]

On 11/25/2010 8:19 AM, whatwg-request at lists.whatwg.org wrote:
> Message: 3
> Date: Thu, 25 Nov 2010 14:18:49 +0100
> From: Martin Janecke<whatwg.org at kaor.in>
> To: whatwg<whatwg at lists.whatwg.org>
> Subject: Re: [whatwg] Processing the zoom level - MS extensions to
> 	window.screen
> Message-ID:<CB2E4340-4A65-41DE-BCA9-3E02084FFB77 at kaor.in>
> Content-Type: text/plain; charset=windows-1252
>
>
> Am 24.11.2010 um 23:59 schrieb Charles Pritchard:
>
>> >  There is evidence that it will enhance usability for programmers who use it properly.
>> >  
>> >  Focus.
>> >  
>> >  -Charles
> Do you mean functionality rather than usability? As I understand this, an author of a web page has neither control of nor knowledge about the status of the browser's zoom function (yet). And I don't think you can enhance usability of something that doesn't exist. What you desire seems to be a change of functionality.
It would enhance usability for the users; by exposing functionality to 
the programmers.
> I am aware of two different existing types of zoom functions:
>
> (1) Zoom functions implemented by web page authors, e.g. at OpenStreetMaps and other geo services. Even if they don't use canvas, the same is also possible with canvas. Web page authors already have complete control and knowledge about this kind of zoom function and its status.
SVG-style pan and zoom is completely irrelevant to the browser zoom 
semantics I'm bringing up. That said, they're very much available in the 
SVG specs.
> (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.
> I'm happy about both these solutions and their separation. As a web page author I can create the zooming experience that I consider best for my users. And my users can use it. But as a user I can also use my browser's zoom function which simply makes things bigger without the web page author interfering or knowing. It works the same way for every web page I apply it to. (1) and (2) serve different purposes.
Author knows, most just don't use it. Yes, they serve different purposes:
your example doesn't take into account any of the use cases I've put 
forward.

> For example, there's a big difference between zooming into a map with its author provided zoom feature ? which usually leads to*more*  details about the central part of the map ? and zooming the map with the browser's build-in function ? this makes the focused details bigger, usually reducing the total amount of information displayed on the screen (by cutting the non-central parts of the map*without*  adding new information).
>
> I am convinced that giving the web page author the power to interfere with option (2) in addition to her/him already having the power to create almost any zooming experiences she/he likes with strategy (1) would be hardly beneficial to users. Even if used with best intentions by authors, it will disturb enough users' desired experience, as it reduces user controlled functionality. It turns a function that the user expects to work for every webpage the same into something that does not. It would make option (2) become just another author controlled option (1.b).
Authors have that ability if they create a UA extension; and I like the 
separation as well.

Once again, you, as many in the list, have taken a very simple use case, 
and generalized it into a straw man argument.

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.

1. blurry image != good.
2. Sharp image > good.
3. Sharp image != disturbed users.


Please, could we stop with the generalizations. I would like to focus 
squarely on facts, and technology,  not on the fallibility of the masses.

If a web author wants to abuse existing apis, through any reason, 
they're perfectly able to do that.

Consider authors who use massive amounts of image tags instead of proper 
CSS... Or ones who use iframes and popups unnecessarily... Their poor 
decisions should not restrict the rest of us to the lowest common 
denominator. This information is already exposed on mobile phones, its 
already exposed in IE: you're imagining scenarios that don't match 
existing reality.

I've gotten the impression on this list that you all would rather have 
not had the scripting environment available at all to web authors. It's 
a false premise: given even the most complete of CSS+SVG profiles, web 
authors are free to make their content inaccessible. And their audience, 
or their customers, are free to complain that they should fix it. This 
is the free market.

I am coming here, to this list, to state very plainly, that I have an 
existing use case, that other than Mozilla, browser vendors are on 
board. The push back I'm receiving has been a pretty awful experience. 
It's been entirely reflective of personalities and phobias, and not at 
all a discussion on the merits of any given proposal. I'm sure it's 
frustrating for some of you as well, but I'm not going to give in to the 
boogie-man scenarios of incompetent webmasters harming tens of millions. 
I'm not going to give in to the repeated statements that my use case is 
invalid. And apparently, many of you will not budge either.

-Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101125/e54370cf/attachment.htm>