[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.)