Dynamically Zoom-able Elements

Dynamically Zoom-able Elements

Author:
DONG Wenyu, China Mobile
WANG Xiaozhen, RAN Songnan, UC Web
ZHANG Hongfei, BAIDU

Abstract
This document proposes a means to enable web page developers to designate specific element(s) which can be zoomed on screen according to users’ orders. That is, when a user performs specific actions on the element(s) like continuous pressing or double clicking, the browser can display the element(s) on a large scale on the top level, while the overall page is still displayed with original size. This means balances details in focused area as well as overall layout of the whole page, applicable for scenarios like geo-navigation, jewelry presentation, etc…

1. Introduction
   1.1 Scenarios
   There are some cases where users need to amplify the appearance of a focus areas while being able to see the overall layout of the whole page.
   

As shown in the following figures, the dynamic zooming-in capability can be used to

1. display details of a static picture, or
   
2. display the inputted text in real-time
   
   
   Fig 1-1 zoom-in while displaying a picture
   
   Fig 1-2 zoom-in while inputting
   

1.2 Existing approaches
There have been solutions to zoom-in/out the web pages.
1.2.1, Browser-based
Browsers amplify the whole page and all elements will be zoomed-in on the same scale.
This capability is supported by most browsers like Chrome, IE.
But the limitation is obvious. The zoomed-in page might be larger than the screen, so users have to scroll left-to-right and/or up-to-down to see the complete page.
1.2.2, CSS-based
Developers use CSS to select specific elements, and endow them the ability to dynamically zoom-in/out. The following statement will enable the element #zoomdemo to display 300% larger.

3, Content-trimmed
When users require to zoom-in a specific area to a larger scale, only elements that fit in the destination scope is displayed, while the rest of page will be discarded since it will be out of the page on the desired scale.
For nowadays geo-navigation application, when users zoom-in a portion of the map, the selected portion will fill the whole screen, and the rest part will be invisible at all.

1.3 Suggested solution
The suggested solution is that we shall:

1. let element-level dynamic zooming-in become a standard, native capability of browsers, and
   
2. introduce new attributes into HTML.
   This is because:
   
3. The requirements are becoming popular, esp. on small-screen devices;
   
4. Simplify the development;
   
5. Every element can be amplified as users’ selection, contrast to existing CSS-based approach by which only those elements that are designated and programmed by developers can have the capability to zoom-in. Sometimes it is hard to anticipate which area(s) should have the zooming-in capability in developing period.
   
   

-2-. Specification
New attributes need to be introduced into specific elements.

1. New attribute: localzoom. localzoom = enabled / disabled. ‘Disabled’ is by default.
   
2. Element scope. It is suggested that container elements, like < BODY>、< DIV>、< IFRAME>, should have this attribute
   Note:
   
3. Inheritance. Unless explicitly specified, inner elements inherit the value of ‘localzoom’ from outer elements.
   
4. Zooming-in scope. It is the user who decide the scope of zooming-in. browsers shall provide mechanisms by which to ease the users’ operation (inputting/selecting etc) procedure. For example, when a user presses an area continually for a period of time, the browser can display a dashed-lined rectangle/circle which is enlarging steadily to indicate the desired zooming-in scope. When the user is satisfied with the scope, he/she can release the pressing finger.
   
5. Zooming-in style. It is up to browsers’ decision, including scale, location, timing, auto wrapping, etc…
   
6. Triggering condition. It is up to browsers’ decision. For example, long time pressing continually, or double/triple clicking.
   
   

-3-. Use cases
3.1 Zooming–in for a single element
The following statement can zoom-in the < input> area on the top level, while the whole page still displayed.

< form action=……> …… < DIV localzoom=“enabled”> < input name=“AccountID” type=“text” > < /DIV> …… < /form>

3.2 Zooming–in for a set of elements
The following statement can enable all elements within with the dynamic zooming-in capability.
Note: this does not mean that all elements in the will necessarily display at an amplified scale at the same time. On the contrary, only elements selected by the user will do so. The dynamical zooming-in scope is decided by the user when he/she is performing specific actions like pressing continually and acknowledge the browser’s hint (like dashed-lined rectangles).

< form action=…… localzoom=“enabled”> …… < input name=“AccountID” type=“text” > …… < /form>

This has some overlap with IE’s content zooming feature. Have you played with that at all? We (chromium input team) have chatted with the Microsoft folks responsible for that feature a few times, but our mutual conclusion has been that this is really something that’s better left to a library than built into the browser. The customers they built that API for ultimately didn’t use it because they wanted more control over how exactly the zoom behaved.

How well could a browser implement such features without any API from the developer? Eg. could a UA start by enabling this on all input fields and images? I assume the benefit of an explicit API is to let developers disable the feature when it gets in the way, or to control the scope of what exactly gets zoomed, right? Seeing a compelling feature that works automatically some of the time would help motivate the need for an API to give developers control over the behavior.

Could what you describe be built as a polyfill/library today? What are the limitations of such an approach that would require native browser support? Again seeing a lot of sites adopt such a library could help motivate the need to build such APIs directly into the browser.

You say a goal is to “balance details in focused area as well as overall layout of the whole page”. But this seems very hard to do well automatically, right? Eg. when zooming an input field, how should the UA decide where to position the zoomed content to minimize the risk that it’ll overlap something else the user cares about? How is this inherently better than just zooming the whole page (“trimming”)? I’d love to play with some examples of entering text on a phone. It’s not obvious to me how we could get a UI that feels better in most situations than the existing behavior in Safari and Chrome (although I agree that’s not great).

Sorry if I’m getting off-topic, but this is what apple solved when they introduced pinch-to-zoom, a generic approach to zoomable content. which seems that a lot of devs disable with <meta name="viewport" content="initial-scale=1, maximum-scale=1"> which for me sound totally wrong. Because the feature is there, if a user tries to zoom-in is because they want/need to see it larger, so why don’t let then read at the size they want. Then if they don’t, they don’t. Why bother disabling this great accessibility feature.

Back to the OP, I think this is more suited for a custom element rather than on the spec. Just my 2c.

What are the limitations of such an approach that would require native browser support?

I think zooming with responsive images will be better with native browser support. A library can load a larger image by detecting zoom level but with potentially long download delay.

Example: https://jsfiddle.net/saschanaz/8Laaswgd/ (image will be cached so please remove cache before page refresh)

This example receives click event and load larger and larger file of the same picture. The problem is the browser first removes the whole image from display before reloading new one and thus causing flickering. This gets more critical when network speed is slow and image size is huge.

XHR can be used instead to prevent flickering, but I can think a better one: repaint on existing image in real time. And this requires native support (as a polyfill will require manual image decoder which will be definitely slower than browser native one).