== Viewport Interaction Topics == This page is a place to collect topics relevant to viewport interactions and device adaptations, and how they work with WebKit. Since the issues are broad, it's more useful at this point to collect a list here rather than use a scattered list of bug reports. * Animations should pause while interacting with the viewport * Zooming to a particular element should not pan beyond the contents of the page. * Events should not be sent to the page until it's renderable * A page should not be visible before its first layout * A page should not be replaced if the user is still interacting with it (ie. having a finger on the page) * If a new page is being loaded behind, user events must not be sent to it. * The browser should not change orientation if the user is still interacting with the page (ie. having a finger on the page) * Active DOM objects (Timers, async events, etc) are suspended while interacting with the content (to avoid content changing on anything but user input) * Content should not be rendered or updated if the page is not visible (ie. in background). * Animations such as animated GIFs should not start animating until they are exposed in the viewport. * Orientation change: When changing orientation, position should be kept and the scale should adapt to the width-change. ie. if aspect ratio is 1.5 the scale would be divided or multiplied by this value. As the @viewport and viewport meta can restrict this scale change, or fix it to say 1.0, the original content might not fix the whole view. Common solutions is to show checkerboard on the non covered area from portrait->landscape, and center content the other way around. When keyboard is up (editing mode) orientation changes often keep a specific scale (also bounded by @viewport etc.) Common value is 200% aka 2.0. * Keyboard: When keyboard is up, scale to 200% (bounded) and center the editiable area in the view, given the caret position. The content can still be panned and pinched, but each orientation change recenters the position and scale. * When keyboard is up it should be possible to pan content further. ie it should be possible to see the lower part of the page. Closing the keyboard should move the content back so browser background is ever seen. * When panning with some velocity level, the panning should lock the axis so that it scrolls straight * Resize (incl. orientation change) should keep css position, also if the page changes scale due to fit-to-width. * Fixed position * Remove fixed position elements as soon as a new load starts * Do not show fixed position elements before the main content changes (iPhone has an issue with this)