RE: [css-device-adapt] How should initial viewport contribute to layout?

> I'd like to make clear of the relationships among the terms:
> 
> - http://quirksmode.org/mobile/viewports2.html:  visual viewport, layout viewport
> - css-device-adapt: initial viewport, actual viewport
> - CSSOM view: viewport
> 
> Now in my understanding
> - layout viewport == actual viewport

Agreed.

> - sizeof(visual viewport) == sizeof(initial viewport) / pinch-scale.
>   i.e. visual viewport == initial viewport if not pinch-zoomed.

This one should be:
sizeof(visual viewport) == sizeof(actual viewport) / pinch-scale.

...with the caveats mentioned earlier on the thread regarding other factors that can change the visual viewport (i.e. overlay UI).

> - viewport in CSSOM view == visual viewport

Yes and no.  Viewport in CSSOM blends the concepts of all three viewports, since it ignores concepts of zooming.  This definition needs to be split out to account for scaling.

> 
> If my understanding were correct, what should we do when visual viewport size changes when the keyboard is visible?
> A
>   1) let sizeof(initial viewport) = sizeof(visual viewport) * pinch-scale;
>   2) compute the new actual viewport based on the new initial viewport (using the algorithm defined in chapter 6 of css-device-adapt);
>   (As aspect-ratio(initial viewport) == aspect-ratio(visual viewport), the two steps could be combined by using visual viewport size directly in 2).
> or
> B
>   decouple visual viewport and initial viewport on temporary window size changes.
> I'd prefer B.

After substituting in "actual viewport" for "initial viewport" as noted above, B is closer to what we do in IE.  We basically trim off the lower edge of the visual viewport (and do not modify the actual viewport) to reflect the covered area.  This is reflected in DOM properties like innerHeight, fires a window resize event, etc. but in general does not impact layout*.

> 
> Fixed-pos element attachment seems still controversial. The browsers (all but IE?) not following the spec may base on the following point: developers who put fixed-pos elements in the page might expect they'd be always visible. Perhaps "position: device-fixed" (http://quirksmode.org/blog/archives/2010/12/the_fifth_posit.html) is the solution to the controversy.

We did a lot of research on this point in IE10 as we added our touch support.  We found that the majority of scenarios had a stronger expectation of fixed elements aligning with the page content than always being on-screen.  Good examples of this are sidebar navigation/widgets/advertisements that float down the side of the page, or bottom-aligned toolbars that center-align perfectly with the content wrapper.  Maintaining that promise of aligned content offered better compatibility with existing web content than the "device-fixed" behavior.

However, definitely agreed that there are cases where the developer wants always-on-screen UI.  In IE11 we added the position value -ms-device-fixed that has this behavior (immune to both zooming and scrolling, and attaches to the visual viewport).  *This is the one case where visual viewport changes can impact layout -- if the size of the visual viewport changes due to overlay UI showing/hiding.

Thanks,
-Matt

Received on Wednesday, 12 February 2014 22:37:19 UTC