[css-overflow] how should ignoring overflow on the *-start sides of the scrollport be done?

[dbaron]

There's a longstanding interoperability issue relating to overflow that I really thought we'd discussed before, but I can't find any record of it.

Scrollbars provide a user interface that allows scrolling to overflow extending past the inline-end and block-end sides of the box. However, overflow that extends past the inline-start and block-start sides of a box with overflow:scroll or overflow:auto is ignored.

Currently the spec says:

Due to Web-compatibility constraints (caused by authors exploiting legacy bugs to surreptitiously hide content from visual readers but not search engines and/or speech output), UAs must clip the scrollable overflow region of scroll containers on the block-start and inline-start sides of the box (thereby behaving as if they had no scrollable overflow on that side).

This was introduced in 01821f08744d, by fantasai, in January 2016.

This behavior description matches what Gecko and Edge do.

However, Chromium and WebKit have always done something different, which I believe is that if a box is entirely off of either the block-start or inline-start side of a box, that it makes no contribution to the box's overflow.

The difference matters when there's a box that is entirely before the inline-start (block-start) side of a box, but extends past its block-end (inline-end) side. In that case, Gecko and Edge show a scrollbar, but Chromium and WebKit do not.

I'd like us to explicitly agree that we should do one or the other of these behaviors, and have the spec reflect it.

See also Mozilla bug 1419142.

[ChumpChief]

In Edge we've observed a number of fairly severe interop bugs due to the (block-start / inline-end) combination you describe on mobile sites.

Since scrollable bounds impact the scaling imposed by meta viewport in some cases, getting a different answer results in a symptom of inappropriate scaling rather than unnecessary scrollbars. In the event that the page has a meta viewport that scales page content to fit the viewport horizontally, a too-large horizontal scrollable bounds results in the symptom of extremely downscaled content on the left side, with a large chunk of blank space on the right.

Because of that, I'm of the inclination that for mobile web compatibility the Chromium/Webkit definition of scrollable bounds needs to be used. Alternatively, the meta viewport behavior could be changed to no longer account for scrollable bounds in scaling calculations, but this would introduce a different set of mobile web compatibility regressions.

From a user perspective, I don't see a scenario where allowing scrolling into a region with no reachable content exists is a good experience. So I think that also points to the Chromium/Webkit behavior being preferable.

[css-meeting-bot]

The Working Group just discussed how should ignoring overflow on the *-start sides of the scrollport be done?, and agreed to the following resolutions:

• RESOLVED: Specify the webkit/blink behavior for issue #2006

The full IRC log of that discussion

<dael> Topic: how should ignoring overflow on the *-start sides of the scrollport be done?
<dael> github: https://github.com//issues/2006
<dael> astearns: It sounded like idea is change the behavior so that things on start edges that are no in scrollpart do not contribute to scrollable area.
<dael> dbaron: Maybe I should step back. There's a long itnerop bug where edge/gecko do one and chrome/wk do another. I'm assuming english text in this.
<dael> dbaron: How things to the top or left of a scrollable area get ignored.
<dael> dbaron: Scrollable areas don't let you scroll to top or left. Itnteresting is top and right or left and below. In chrome/WK those don't contrinute to scrollable area. Edge & Gecko the do.
<dael> dbaron: More webcompat is chrome & wk behavior probably. Question is if we should spec that behavior or do something else.
<dbaron> Yeah, I thought I remembered discussing it before, but I couldn't find minutes...
<dael> Rossen: Thanks for bringing this up dbaron. This isn't a new topic. I remember, I think, smfr at the time saying that they do try and clip as many things as possible out of scrollable areas that will not be visible. They optimize for less empty space.
<dael> Rossen: Impl-wise there's quite a bit of inconsistancy between WK and Blink so when we spec this I would expect this to be kinda precise because if you start using things like position:relative you'll find that sometimes they will and sometimes they won't clip so even in their impl there's inconcstancy.
<dael> Rossen: I'm all for more interop and better UX, but I want to spec something that will be more concrete in terms of which bounds get clipped and how. Otherwise I support this.
<dael> Rossen: Do we have someone from WK or Blink?
<dael> ??: I just joined and don't know topic
<dael> astearns: [summerizes]
<dael> astearns: Sounds like rough consensus on spec WK/Blink behavior as long as we come up with a consistant way of desc.
<astearns> s/??/hober/
<dael> Rossen: Yeah, that's my only feedback that when we spec we should be explicit on what bounds we consider when compute scrollable bounds. So things like are we considering visible bounds, things offser by relpos, transforsm, so forth and so forth
<dael> astearns: Obj to spec blink/webkit behavior for this issue?
<dael> RESOLVED: Specify the webkit/blink behavior for issue #2006
<dael> astearns: dbaron will you make the overflow spec edits?
<dael> dbaron: It's a little ways out in terms of figuring out behavior first.
<dael> astearns: It would be nice to have blink/wk contribution to help spec the behavior.
<dael> hober: I can take an action to drum up a desc.
<dael> ACTION hober get a description of the behavior for issue #2006
<trackbot> Created ACTION-866 - Get a description of the behavior for issue #2006 [on Theresa O'Connor - due 2017-12-27].

[fantasai]

@dbaron Would you mind verifying that the edits correctly capture the resolution?