Unfortunately it's not specified anywhere how to compute the layout viewport size or minimum-scale-box and Safari and Chrome behave differently in edge cases where the meta tag doesn't specify a minimum-scale (or it's smaller than the UA limit or would exceed document bounds)
Chrome's behavior:
Measure the document bounds after a layout. Clamp the minimum scale factor to a value such that the visual viewport can never exceed the document bounds width. (i.e. the meta tag can make the min-scale-factor larger but not smaller than this value)
Size the layout viewport to the minimum-scale-box
From my testing, Safari's typical behavior:
Clamp the minimum scale factor to a value such that the visual viewport cannot exceed the ICB size
Size the layout viewport to the ICB
In Chrome, the layout viewport's size depends on content which has been problematic. I'd like to fix this and improve interop with Safari by switching to the above Safari behavior (crbug/1454207).
However, Safari appears to have some quirks in this area I don't understand; it too sometimes displays similar content-dependent behavior. I've captured some of my testing in this doc. @smfr - could you help explain what's Safari is doing?
I'm hoping we could align implementations and spec a more predictable and rational behavior (hopefully by default, if web compatible).
bokand
commented
9 months ago
This only applies to mobile UAs.
There are four important boxes to understand here:
<meta>tag)position: fixedelements, scrolling box fordocumentElement(AFAIK Firefox and Chrome are aligned on behavior, see https://github.com/bokand/bokand.github.io/issues/3)
Unfortunately it's not specified anywhere how to compute the layout viewport size or minimum-scale-box and Safari and Chrome behave differently in edge cases where the meta tag doesn't specify a minimum-scale (or it's smaller than the UA limit or would exceed document bounds)
Chrome's behavior:
From my testing, Safari's typical behavior:
In Chrome, the layout viewport's size depends on content which has been problematic. I'd like to fix this and improve interop with Safari by switching to the above Safari behavior (crbug/1454207).
However, Safari appears to have some quirks in this area I don't understand; it too sometimes displays similar content-dependent behavior. I've captured some of my testing in this doc. @smfr - could you help explain what's Safari is doing?
I'm hoping we could align implementations and spec a more predictable and rational behavior (hopefully by default, if web compatible).