Zoom use case

> On May 26, 2015, at 4:19 PM, Dael Jackson <daelcss@gmail.com> wrote:
> 
> ratan: So, Simon, are saying you would like to go the other way
>         around and standardize it?
>  smfr: I need data in order to provide whether we're willing to
>        actually kill it or not.
>  plinss: Do you think this is data you can have by the F2F

I don't know if this was discussed further, or mentioned outside of the minutes, but I have thought of a use case where you might need multiple zoom levels: a document editor. Imaging something like Adobe InDesign (or to a lesser degree MS Word), built for Web using HTML and CSS.  

The document part would have different magnification levels based on user manipulation of the editor's controls (drop down menus, keyboard shortcuts, pinch zooming). This would not necessarily be just for accessibility (a11y, if you prefer), but for anyone to be able to enlarge the document for detail work, or reduce the view for an overview. 

It would affect layout, so scroll bars could be used. The editor toolbars would be zoom:1, as would rich tool tips, widgets to link tool boxes, containers with one-pixel dotted outlines to show the selected elements, pop-up controls positioned relative to the selected element, etc. 

There might be other ways to do this, but something like zoom would be the most straightforward, in my view. 

For a11y, you should still be able to zoom the whole screen, or the whole window, or choose a larger font, outside of author control too. But for the editor controls, it would be nice to be able to have the edited document zoomable via a menu that the author created, which set the zoom factor via a single CSS value, while having some descendant elements that were always zoom:1. 

It would be nice also to be able to zoom a single component of the page for editing. For that, maybe there could be another switch (position:relative? Or maybe a second compound value?) that would prevent the zoom from affecting the layout around it (aside from scroll bars if it gets bigger than the viewport), while still allowing different zoom levels for controls and editable sub-components inside it. 

By the way, default should be 'zoom:1', so that it isn't abused for side effects, the way it was for triggering hasLayout (which I myself have had to do innumerable times, by necessity, for old IEs). And it might not hurt to call it 'zoom-factor' or something, in order to make a clean break from style sheets that had old IE zoom in them. 

Received on Wednesday, 27 May 2015 15:11:16 UTC