[css-overflow] Clarify what rect clips the root element with overflow:hidden on mobile environments with dynamic toolbar

[hiikezoe]

The spec says what overflow:hidden means is the box’s content is clipped to its padding box, and I believe the padding box of the root element is the initial containing block (which is 0-padding) (or maybe the layout viewport?).

On mobile environments with dynamic toolbar, the initial containing block doesn't include the dynamic toolbar height (it's not yet spec-ed though as far as I know of), all major browsers (Chrome, Safari and Firefox) do so. So, I think overflow:hidden should clip the root element to the ICB (which is not including the toolbar height). But both on Chrome and Safari, the root element clips to the area including the dynamic toolbar, thus regions initially overflowed by the dynamic toolbar can be reachable by swipe up motions.
(note that I intentionally ignore cases where the minimum-scale is applied)

https://bug1663634.bmoattachments.org/attachment.cgi?id=9182769 is an example to show the issue.

CCing @bokand

(Though the behavior both on Chrome and Safari is pretty weird for me, I think Firefox has to align with it. )

[frivoal]

I am not sure I fully understand what the problem is, but to the extent I do, it feels more like an implementation issue than a specification problem. Can you clarify?

[hiikezoe]

https://hiikezoe.github.io/overflow-clip-on-root.html
Here is an example. There are two divs, one is a blue position:fixed element attached to "bottom: 0px", the other is a red position:absolute element attached to "top: document.documentElement.clientHeightpx". And the root element has "overflow: clip" property. In this example, the red div is initially outside of the viewport (both of the visual/layout viewports). But on mobile Chrome the red div can be reachable by swipe down gestures (You will probably have to do swipe down gestures several times, I don't know how Chrome handles those gestures). I haven't tried the example on iPhone(s) since I have no such devices at all, but I suppose mobile Safari has the same behavior.

[bokand]

Is the questionable behavior that as the URL bar hides and the red div starts to come into view, it's technically outside the clip rect of the root element but we still see it?

If so, (speaking for Blink) the root element clipping is delegated to the "viewport" and is special in that it's adjusted by the URL bar. We expand the clipping rect but don't expand the ICB (so that we don't change the clientHeight or reflow the page). Without the special case of expanding the clipping rect I think any page on which you can scroll would clip out the bottom of the page as the URL bar became hidden.

This has historically been an area not covered by specs but I wouldn't be opposed to clarifying the exact and expected behavior.

[hiikezoe]

Is the questionable behavior that as the URL bar hides and the red div starts to come into view, it's technically outside the clip rect of the root element but we still see it?

Yes, exactly.

This has historically been an area not covered by specs but I wouldn't be opposed to clarifying the exact and expected behavior.

I am in the same boat. :)

[fantasai]

Agenda+ Do we want to spec this behavior?

[css-meeting-bot]

The CSS Working Group just discussed clipping the root element on mobile, and agreed to the following:

• RESOLVED: Accept the Note above.

The full IRC log of that discussion

<fantasai> topic: clipping the root element on mobile
<fantasai> github: https://github.com//issues/5646
<TabAtkins> ScribeNick: TabAtkins
<fantasai> https://hiikezoe.github.io/overflow-clip-on-root.html
<TabAtkins> fantasai: there's a testcase which makes this clearer...
<TabAtkins> fantasai: on mobile when we ahve dynamic toolbars there's a small and large viewport
<TabAtkins> fantasai: the ICB, the size of the document when it's height:100%, si the small viewport size
<TabAtkins> fantasai: But when the content retracts you see more than that
<TabAtkins> fantasai: This isn't interesting for long scrollable docs
<TabAtkins> fantasai: But if it's overflow:hidden and you're expecting a clipped rectangle equal to the ICB (so stuff outside the rect isn't visible), but it is indeed visible in these cases
<TabAtkins> fantasai: If you load it in a mobile browser, there's a red bar below the ICB. can't see it in desktop browsers, but it's visible in all mobiles when the UI retracts
<Rossen_> q?
<TabAtkins> fantasai: So since we have compat, do we need to spec this?
<TabAtkins> fantasai: Or do we have concerns?
<TabAtkins> florian: I think it's weird, but it's interoperable
<TabAtkins> fantasai: And I also can't think of a better idea
<TabAtkins> fantasai: I suppose you coudl clip the content but extend the canvas area...?
<TabAtkins> Rossen_: Thoughts?
<TabAtkins> TabAtkins: Since we don't ahve a better idea, and it's interop already, suggest we go for it
<TabAtkins> Rossen_: proposed resolution?
<TabAtkins> proposed resolution: the ICB is the small viewport, but the viewport clip rectangle is the large viewport
<TabAtkins> Rossen_: So if I have position:fixed with bottom:0, and I zoom out, will it stick to the viewport or not?
<TabAtkins> flackr: in impls it does
<TabAtkins> flackr: But it sounds like that would disagree with the spec
<TabAtkins> emilio: Can we resolve on aligning to the interoperable bits?
<TabAtkins> emilio: And figure out exactly what those bits are?
<TabAtkins> florian: That's what we tried to do; seems we failed to consider zooming
<TabAtkins> Rossen_: Yeah that's where ICB and visual vs layout viewports make the most difference
<TabAtkins> Rossen_: given decent interop, i suggest diving into details and documenting the status quo better, rather than resolving now
<TabAtkins> florian: so if we just talk about the clipping of overflow:hidden using the large viewport - is that incompatible with reality?
<TabAtkins> Rossen_: It woudl be inconsistent with what I said about position:sticky to the bottom
<TabAtkins> Rossen_: spec'll stick it to the ICB bottom, if I zoom it *currently* sticks to the screen bottom
<TabAtkins> fantasai: Florian's just talking about the clip rectangle, not the poisition of anything
<TabAtkins> fantasai: Issue here is that if you ahve overflow:hidden on the root, it might still not clip everything on the screen
<TabAtkins> florian: I think what I'm hearing is we might ahve the right answer, but more research is needed
<TabAtkins> Rossen_: I think something must be missing, happy to be wrong
<TabAtkins> florian: We should take the time to get our terminology exactly right
<TabAtkins> smfr: I'd appreciate more time to look at this to understand iOS
<TabAtkins> fantasai: We also don't have a spec that describes visual vs layout viewport, and small vs large viewport, and what's tied to what
<TabAtkins> fantasai: like is bottom:0 and top:100% the same? dunno
<TabAtkins> Rossen_: And when you add zoom and transforms, might end up with clipping, or sticking to the wrong thing, both are unexpected
<TabAtkins> fantasai: What we can say for this specific issue is that overflow:hidden on the root might not necessarily clip to the ICB rect
<TabAtkins> TabAtkins: That sounds like a Note, not normative text.
<TabAtkins> Rossen_: so what's th enote?
<TabAtkins> fantasai: proposed note: overflow:hidden on the root might not clip everything outside the ICB if the ICB is smaller than the viewport, which can happen on mobile
<TabAtkins> Rossen_: objections?
<TabAtkins> RESOLVED: Accept the Note above.