[css-position][css-sticky] Scrolling ancestor should probably include overflow:hidden even when content doesn't overflow

[stephenmcgruer]

The spec[1] states that "the offset is computed with reference to the nearest ancestor with a scrolling box, or the viewport if no ancestor has a scrolling box." where a scrolling box is created if "Elements and viewports have an associated scrolling box if has a scrolling mechanism or it overflows its content area and the used value of the overflow-x or overflow-y property is hidden." [2]

This is not the behavior implemented by any web-browser. Scrolling the viewport on http://output.jsbin.com/yaxovep in any of Chrome, Firefox, or Safari shows that the sticky element is sticking to the overflow:hidden ancestor for both scrollers, even in the left-hand case where the content area isn't overflowed.

Rather than change all three browsers to follow the spec (which would also be an awkward change imo since you would end up jumping sticky ancestors when layout changes), we should change the spec I think.

@flackr

[1] https://www.w3.org/TR/css-position-3/#sticky-pos

[2] https://drafts.csswg.org/cssom-view/#terminology

[jonjohnjohnson]

@stephenmcgruer check the discussion/comment here in #865 (comment)

Also, the case(s) linked here showing how sticky position across browsers allow nested sharing of a containing block / scrolling box #1294 (comment)

And this issue? #2567

[chrishtr]

+1 to what @stephenmcgruer said.

[jonjohnjohnson]

@stephenmcgruer you say...

a scrolling box is created if "Elements and viewports have an associated scrolling box if has a scrolling mechanism..."

In CSS-overflow

visible - There is no special handling of overflow, that is, the box’s content is rendered outside the box if positioned there. The box is not a scroll container.

So I believe that all other [used] values for overflow (until implementation of the clip value #1971) create a "scrolling mechanism" according to spec. The auto value even creates a scrolling mechanism when not overflowing its content area.

I think the current spec wording, though quite opaque, makes Chrome, Firefox, or Safari all spec compliant, in that as soon as an ancestor has overflow not set to visible in either axis, that ancestor has a "scrolling mechanism", even without overflowing its content area. Maybe the text "or it overflows its content area and the used value of the overflow-x or overflow-y property is hidden" should be removed to simplify/clarify?

Have you read the linked issues/comments from my previous response? This #865 (comment) highlights your exact concern about "jumping sticky ancestors when layout changes".

[stephenmcgruer]

@jonjohnjohnson Firstly, I appreciate all the work you've been doing to try and raise issues about the (sadly mostly neglected) sticky spec. Thank you for trying to make the web saner! :)

So I believe that all other [used] values for overflow (until implementation of the clip value #1971) create a "scrolling mechanism" according to spec. The auto value even creates a scrolling mechanism when not overflowing its content area.

If this were true, there would be no need for the following part of the sentence in CSSOM-View:

"... or it overflows its content area and the used value of the overflow-x or overflow-y property is hidden"

The fact that this is here implies (to me) that overflow: hidden is not automatically considered having a scrolling mechanism. I think it is reasonable that it should be, but I'm not so sure the spec says it does. There certainly seem to be ongoing debates about it, e.g. #1526. That issue was closed, but the related PR (#1540) never landed I think.

[jonjohnjohnson]

@stephenmcgruer

The fact that this is here implies (to me) that overflow: hidden is not automatically considered having a scrolling mechanism.

Agreed, spec language needs to be cleaned up, clearer, and honestly made to be in line with current implementations. This still seems to be a near duplicate of the reasons/discussion for #865, though so many of these issues have a lot of crossover.

Any idea on how to move these issues forward? Or to even get an idea about when these issues may be tackled?

[tabatkins]

When we get an active editor for the Position spec, or one of us non-editors decides to take a gander and do some cleanup as a break from our main specs. :/

[jonjohnjohnson]

@tabatkins I don't mean to bother, but as I look through https://www.w3.org/Guide/ I'm at a loss for any ways that we can help to find/instate new editors. If there is anything that I can do, even if it is respectfully petitioning the css-position-3 previous editors, I'd love to know. As always, thanks for taking time to respond and engage with even "off-topic" issues.

[tabatkins]

Pinging previous editors is the only real route. :/

[tabatkins]

Position was rewritten and now properly refers to the Overflow spec for its definitions, so this is moot for Position itself.

CSSOM-View has also been subsequently edited to remove that incorrect definition. It's still present in the latest /TR publication, so that'll need to be addressed, but at least the ED is correct and no longer trying to define an overflow concept.

So, looks like this issue is fixed!