Bug 107997 – Implement desktop compatibility viewport

• Component: New Bugs
• Status: RESOLVED WONTFIX

[Tien-Ren Chen]

Implement desktop compatibility viewport

[Tien-Ren Chen]

Created attachment 184851 [details]
Patch

[Benjamin Poulain]

(In reply to comment #0)
> Implement desktop compatibility viewport

What is desktop compatibility viewport?

[Alexandre Elias]

We'd like to implement pinch zoom while behaving well on existing desktop websites which weren't designed with it in mind.  In particular, fixed-position elements tend to be positioned strangely in the presence of pinch zoom.  We're planning to position those in a larger box which is always sized to the initial containing block, which we're tentatively calling "desktop compatibility viewport".

This patch is a very early WIP and not for review yet, but let us know if you have feedback on the general approach.

[Benjamin Poulain]

(In reply to comment #3)
> We'd like to implement pinch zoom while behaving well on existing desktop websites which weren't designed with it in mind.  In particular, fixed-position elements tend to be positioned strangely in the presence of pinch zoom.  We're planning to position those in a larger box which is always sized to the initial containing block, which we're tentatively calling "desktop compatibility viewport".

Both iOS and Mac supports fixed element and full page zoom.

It could be bad for web developers to have to tweak for each browser separately. It would be nice to have common concepts and behaviors instead.

Could you please detail a bit the concept you are creating? Would the element still be fixed when you zoom? If the position is in percentage, how do you layout?

[Alexandre Elias]

We would keep track of two separate viewports at all times, the normal viewport and the desktop compatibility viewport (which we also refer to as the "inner" and "outer" viewports as the normal viewport is always contained within the desktop compatibility viewport).  Given only scroll interactions, these would remain in perfect sync, but in the presence of pinch zoom, they would diverge as follows:

- Pinch zoom scales the normal viewport but the size of the desktop compatibility viewport is unaffected, always remaining at the initial unzoomed size.
- The desktop compatibility viewport is positioned relative to the normal viewport with an offset that is always negative or zero (pointing to its upper-left).  This offset is initialized at (0,0) on page load.
- If at any point, the sum of normal viewport offset and desktop compatibility viewport offset would position the desktop compatibility viewport A) partially outside the bounds of the document or B) non-fully-intersecting with the normal viewport, then the desktop compatibility viewport offset is clamped to avoid this.  The clamped value is assigned to it in a persistent manner.
- When a scaling gesture affects the size of the normal viewport, we also adjust the desktop compatibility viewport's offset so that its absolute position does not change.  However, during scrolling, no such adjustment is made (aside from the clamping).

Fixed position elements would layout in exactly the normal manner, but they would simply consider this newly defined rectangle to be the "viewport" instead of the one the user sees.

The idea behind this is that fixed-pos elements would normally get out of the way when zooming in, unless the user expresses some intent to see the fixed-pos element.  If a user pinch zooms into the center of the viewport, a top fixed position bar would quickly slide away from view and not reappear if they scroll downwards.  However, if they scroll back up to the very top of the document, then the fixed-pos element will come into view (and then stay in view even if they scroll back down).  Alternatively, if they had pinched near the top of the screen in the first place, then the fixed-pos element would stay in view.  Also, fully zooming out will always bring the two viewports back in sync and all the fixed position elements into view.

[Benjamin Poulain]

This sounds exactly like what Mozilla tried for the N900 (MicroB Browser), and that was awful. I suggest you to try that on one of those phones.

You did not answer my concerns regarding compatibility. :(

[Alexandre Elias]

I agree compatibility is an important goal.  But we don't feel that the existing implementations are ideal yet and we'd like to experiment with different options.  Let's keep discussing this over time and ideally we could eventually come to a consensus on how all ports should handle this case.

I ordered an N900, it should arrive next week and we'll take a look at how it feels.