<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

  <head>

    <meta content="text/html; charset=ISO-8859-1"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#ffffff" text="#000000">

    On 11/25/2010 8:19 AM, <a class="moz-txt-link-abbreviated" href="mailto:whatwg-request@lists.whatwg.org">whatwg-request@lists.whatwg.org</a> wrote:

    <blockquote

cite="mid:mailman.6045.1290701992.9821.whatwg-whatwg.org@lists.whatwg.org"

      type="cite">

      <pre wrap="">Message: 3

Date: Thu, 25 Nov 2010 14:18:49 +0100

From: Martin Janecke <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:whatwg.org@kaor.in"><whatwg.org@kaor.in></a>

To: whatwg <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:whatwg@lists.whatwg.org"><whatwg@lists.whatwg.org></a>

Subject: Re: [whatwg] Processing the zoom level - MS extensions to

        window.screen

Message-ID: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:CB2E4340-4A65-41DE-BCA9-3E02084FFB77@kaor.in"><CB2E4340-4A65-41DE-BCA9-3E02084FFB77@kaor.in></a>

Content-Type: text/plain; charset=windows-1252

Am 24.11.2010 um 23:59 schrieb Charles Pritchard:

</pre>

      <blockquote type="cite" style="color: rgb(0, 0, 0);">

<pre wrap=""><span class="moz-txt-citetags">> There is evidence that it will enhance usability for programmers who use it properly.

<span class="moz-txt-citetags">> </span>

<span class="moz-txt-citetags">> Focus.

<span class="moz-txt-citetags">> </span>

<span class="moz-txt-citetags">> </span>-Charles

</pre>

      </blockquote>

<pre wrap="">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.

</pre>

    </blockquote>

    It would enhance usability for the users; by exposing functionality

    to the programmers.<br>

    <blockquote

cite="mid:mailman.6045.1290701992.9821.whatwg-whatwg.org@lists.whatwg.org"

      type="cite">

      <pre wrap="">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.

</pre>

    </blockquote>

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

    <blockquote

cite="mid:mailman.6045.1290701992.9821.whatwg-whatwg.org@lists.whatwg.org"

      type="cite">

<pre wrap="">(2) The browsers' build-in zoom function, which web page authors have no control or information about.

</pre>

    </blockquote>

    They have information about it, in many browsers, and they receive

    events related to window.innerWidth and innerHeight.<br>

    <blockquote

cite="mid:mailman.6045.1290701992.9821.whatwg-whatwg.org@lists.whatwg.org"

      type="cite">

      <pre wrap="">

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.

</pre>

    </blockquote>

    Author knows, most just don't use it. Yes, they serve different

    purposes:<br>

    your example doesn't take into account any of the use cases I've put

    forward.<br>

    <br>

    <blockquote

cite="mid:mailman.6045.1290701992.9821.whatwg-whatwg.org@lists.whatwg.org"

      type="cite">

<pre wrap="">For example, there's a big difference between zooming into a map with its author provided zoom feature ? which usually leads to <b class="moz-txt-star"><span class="moz-txt-tag">*more<span class="moz-txt-tag">* 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 <b class="moz-txt-star"><span class="moz-txt-tag">*without<span class="moz-txt-tag">* 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).

</pre>

    </blockquote>

    Authors have that ability if they create a UA extension; and I like

    the separation as well.<br>

    <br>

    Once again, you, as many in the list, have taken a very simple use

    case, and generalized it into a straw man argument.<br>

    <br>

    If you'd stick to my use case, instead of coming up with imaginary

    problems, I think we might have a discussion on merits.<br>

    <br>

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

    depth of bitmap data, so that zoom does not result in an

    unnecessarily "blurry" image. <br>

    <br>

    1. blurry image != good.<br>

    2. Sharp image > good.<br>

    3. Sharp image != disturbed users.<br>

    <br>

    <br>

    Please, could we stop with the generalizations. I would like to

    focus squarely on facts, and technology,  not on the fallibility of

    the masses.<br>

    <br>

    If a web author wants to abuse existing apis, through any reason,

    they're perfectly able to do that.<br>

    <br>

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

    <br>

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

    <br>

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

    <br>

    -Charles<br>

  </body>

</html>