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

In IE we layout fixed elements (and everything else) based on the actual viewport.  The initial viewport is mostly just used in evaluating media queries for @viewport rules.  It's desirable to use a single viewport for laying out all content in order to ensure fixed content maintains correct alignment and sizing relative to non-fixed content.  This is especially important to avoid breaking layouts in scenarios where the user is able to zoom.

For most temporary overlay UI we adjust the visual viewport only (including the touch keyboard in Win8+), or else don't adjust any viewport (e.g. the autohiding address bar).  This is to avoid content relayout where possible, especially if the overlaid state is very temporary.

All this said, I'm not sure if these questions fall into the device adaptation spec since they pertain more to definition of visual viewport vs. actual viewport, rather than the definition of initial viewport vs. actual viewport.  I do think they'd be good questions to resolve in some spec though.

Thanks,
-Matt


>From: wangxianzhu@google.com [mailto:wangxianzhu@google.com] On Behalf Of Xianzhu Wang
>Sent: Tuesday, February 11, 2014 11:42 AM
>To: www-style@w3.org
>Subject: [css-device-adapt] How should initial viewport contribute to layout?
>
>Hi,
>
>Actually I have 2 related questions:
>1. Should fixed-position blocks layout according to the 'initial viewport', 'actual viewport' or something between them?
>2. For a page with unconstrained viewport height, how should the height of the 'actual viewport' be adjusted when there is temporary height change of the 'initial viewport', e.g. when the on-screen-keyboard shows?
>
>The answers to the above questions seem to have already been covered by existing specs, but after we examine the current behavior of different mobile browsers we found they have tweaked the existing specs to achieve more user-friendship and/or better performance:
>
>1. All browsers seems not to layout top-level fixed-position blocks according to the initial-containing-block (i.e. 'actual viewport' in css-device-adapt), but somehow according to the visible viewport (i.e. 'initial >viewport' in css-device-adapt). Mobile Safari's behavior is more complex that seems to use a bigger virtual viewport to contain the fixed-position elements if the visible viewport is too small.
>
>2. For a page with unconstrained viewport height, the browsers behave differently about whether to adjust the actual viewport height when visibility of the top- and/or bottom- controls and the on-screen keyboard changes.
>
>https://docs.google.com/a/chromium.org/document/d/1ukfEZGJQq-7VD_Tv9m_cYD4BoR6YZots5_KddtvYZJs/edit# summarizes the current behaviors of the browsers.
>
>I think it'd be better if the spec address the issues that caused the browsers to tweak the spec, to avoid inconsistency and confusion.
>
>Thanks,
>Xianzhu
>

Received on Wednesday, 12 February 2014 01:07:46 UTC