Clarification on Safari's behaviour for fixed position elements

[tpodder]

The page https://theres-waldo.github.io/mozilla-testcases/bug1473699.html was tested in Safari on an iPhone simulator and the behaviour observed was that the fixed position elements were being attached to the visual viewport when we zoom out to the minimum scale. However, the explainer document states that the behaviour of fixed position elements on Safari is such that the fixed position elements are attached to the layout viewport when we zoom out to minimum-scale. Do you know if Safari has perhaps had a recent change in behaviour that hasn't been reflected in the explainer document yet?

[bokand]

Hi there,

I'm not sure I understand your description. To clarify, position: fixed elements will attach to either the layout or visual viewport - that's a decision that's irrespective of the current zoom level. If the position fixed elements remain physically fixed on screen as you zoom in and out then they're attached to the visual viewport. If they're move off-screen as you zoom in, they're attached to the layout viewport.

It sounds to me (correct me if I'm wrong) like what you're describing is that the fixed boxes are at the correct locations when you're fully zoomed out? And zooming in makes them move offscreen. In that case, they're fixed to the layout viewport as expected. In Chrome - not sure about Safari - the layout viewport is sized such that it is the size of the visual viewport at minimum scale. So I believe the description in the explained is still correct. I tried this on Safari desktop and it works as I expect. I couldn't try on a mobile device since I don't have access to one at the moment and BrowserStack doesn't let me do pinch zoom :(. Unfortunately, mobile adds all kinds of complications based on minimum-scales and page content.

See http://bokand.github.io/viewport/index.html for an intuitive picture of how this works. (I haven't updated it since Safari changed their model so the "Browser Implementation" for Safari is incorrect here - it should behave much like Chrome).

FYI - I'm OOO for the next 3 weeks so I likely won't be able to reply until I return. Happy to chat more and help when I return.

[theres-waldo]

It sounds to me (correct me if I'm wrong) like what you're describing is that the fixed boxes are at the correct locations when you're fully zoomed out? And zooming in makes them move offscreen.

Actually, we were trying to reproduce the scenario where in the fully zoomed-out state, the fixed boxes move away from the edge of the screen (and towards the middle of the screen) because they are fixed to the ICB, which is now smaller than the visual viewport. That is, we're trying to reproduce the scenario where the rendering looks like this, with Safari, but we're not able to with the mentioned testcase.

We were wondering if that's because our testcase is failing to exercise the necessary set of conditions, or because Safari has changed their behaviour.

[theres-waldo]

(To provide some background: we are trying to figure out how to handle, in Firefox, the case where the ICB is narrower than the visual viewport, and we're trying to understand the behaviour of other browsers. We believe we understand Chrome's model - size the fixed viewport to the minimum scale size, not to the ICB size - but are confused about Safari's model.)

[bokand]

Ah, sorry - I misunderstood, that makes sense now.

So IIRC - that situation wasn't actually possible in Safari:

A consequence of this is that if the user can zoom out to see more than the ICB (Window Phone, but not Safari)

I think Safari should prevent you from zooming out further than the ICB

[tpodder]

We tested the behaviour of Safari on an iPhone X -11.3 simulator for this test page. On this page, we believe the ICB width is the width at which the text on the page wraps. However, we found it was possible to zoom out beyond this width. It could be possible that the behaviour of Safari has been updated. Could you please clarify this?

[theres-waldo]

cc @mstange

As this is ultimately a question about Safari's behaviour, is there a Safari developer we could ask about this?

[theres-waldo]

@smfr Perhaps you could route this question about Safari's behaviour to someone who would know the answer?

[smfr]

Safari lets you zoom out past ICB size because historically it allowed this, and then sites expected that content outside of the ICB would be visible. I don't think we can change this now.

Furthermore, I think it would be odd if position:fixed things detected from the screen edges when zooming out past ICB size, so when implementing visual viewports that's what I did (there's no spec for this).

[theres-waldo]

Thanks! So, just to help me understand the conceptual model here: does Safari attach position:fixed elements to "whichever of the visual viewport or the ICB is larger at the current zoom level"?

[smfr]

So logically having a visual viewport larger than the layout viewport doesn't really make sense, but it happens in this zoomed-out case and there's some amount of special-casing in the code for it. But, yes, the "whichever is larger" holds.

[theres-waldo]

Ok, thanks, I believe we understand Safari's model now. It seems attractive from a UX point of view; we'll investigate how feasible it is to implement in Firefox.

I'm going to leave this issue open to track updating the explainer document to reflect Safari's current behaviour.

[bokand]

Thanks all, updated the explainer with Safari's behavior in 1ac79ae:

Safari

Safari's model is similar to Edge+Chrome with a small twist. When zooming out, as the visual viewport becomes larger than the ICB, the fixed viewport matches the visual viewport. i.e. The fixed viewport size is calculated as:

fixed_viewport_size = max(icb_size, visual_viewport_size)

The practical effect of this is that position: fixed elements detach from the screen as the user zoomes in on a page, but as they zoom out past the ICB, the elements stay fixed to the user's screen.

Does that seem accurate?

[theres-waldo]

It does, thanks!