Csswg-drafts: [css3-positioning] [cssom] getComputedStyle should return "auto" for position:sticky if applicable

[yi-gu]

Spec section:
https://www.w3.org/TR/css-position-3/#sticky-pos
https://drafts.csswg.org/cssom/#resolved-values

According to the spec, top/bottom/left/right on getComputedStyle are used values for backwards compatibility with sites relying on the old definition of computed style. However, position offsets have special meaning for position sticky. getComputedStyle should return "auto" for the following element:
<div style='position:sticky; top: auto;'></div>
instead of returning "0px" which is hugely misleading.

Currently, both Firefox 53, Safari 10 return "auto" in this case. Chrome 58 returns "0px" based on the spec but is about to change to "auto" soon.

[RByers]

/cc @tabatkins @fantasai @flackr this is a specific instance of the issue we discussed in Tokyo. We're changing to match the other implementations since it's more interoperable and more useful for developers. Tab seemed to suggest that maybe this behavior was already covered by the spec, but it's not at all clear to us so at the very least the spec should be clarified.

We have a web-platform-test for this which we will upstream when the spec is fixed or clarified.

[tabatkins]

"auto" is definitely what we want. Position doesn't define the used values properly, but a stickypos element should definitely retain "auto" in used values for t/r/b/l, as that's meaningfully different from a length. (Vs an abspos, where they indicate "do some math for me to figure out the lengths to use", or relpos, where they just mean "0px".)

[RByers]

Thanks Tab. Also take a look at @flackr's results for other types of positions across browsers. It seems there's not really any interoperability here today and we should at least be more clear on what the spec says and ensure we have tests that are failing in some browsers.
/cc @gsnedders

[gsnedders]

We probably want to generalise this issue to cover the position: fixed case to, given that equally makes no sense and is probably little effort to do on top of this, looking at the Chromium bug.

[yi-gu]

Here is the chromium bug w.r.t. the return value of fixed positioned elements.

[equinusocio]

Hi, what about return if the position: sticky; element is sticked or not? Maybe a pseudo-class :stuck?

[nainar]

@tabatkins as per @gsnedders suggestion should getting the computedStyle for the following:

<div style='position:fixed; top: auto;'></div>

also return auto?

[tabatkins]

I'm not sure of @gsnedders’ reasoning for keeping "auto" around for fixpos. Fixpos is the same as abspos in this regard - "auto" is equivalent to some particular length. (In other words, you could replace the "auto" with an appropriate length and get identical behavior. This is not the case for stickypos.)

[gsnedders]

@tabatkins I have no preference here; I just meant the issue itself should consider behaviour for both position: sticky and fixed without any preference for what the return values should be.

[tabatkins]

Okay, well, since fixed is identical to absolute in behavior here, those two should remain consistent in their treatment. (And thus, continue to return a length as their used value no matter what.)

[nainar]

Thanks @tabatkins and @gsnedders :)

[dvoytenko]

FWIW, I believe both position:fixed and position:absolute should resolve getComputedStyle to auto for top/bottom/etc when this is what the rules say. It's misleading otherwise. Though, it sounds like there's a new API in works to make it less ambiguous?

[tabatkins]

Okay, looks like our rewrite of the spec no longer has any mention of "auto" values turning into anything else for stickypos, so they thus remain "auto" all the way thru to used values. Since the other positioning schemes do change "auto" values, it might make sense to add a note highlighting the stickypos is different, but in normative terms it looks like we're covered now.

[gsnedders]

do we have any tests for this in wpt yet?