It seems to me that only Chrome returns the correct value.

"Originally, CSS 2.0 defined the computed values to be the 'ready to be used' final values of properties after cascading and inheritance, but CSS 2.1 redefined computed values as pre-layout, and used values as post-layout. For CSS 2.0 properties, the getComputedStyle function returns the old meaning of computed values, now called used values."

In the example above, the "computed value" of the first div is "auto" and the "used value" of it is "0px". Given that the function getComputedStyle is supposed to return the "used value" after CSS 2.1, the post-layout used value "0px" should be returned. 

p.s. This "bug" is also reproducible with other InFlowPositioned element like "position: relative". Currently in chromium we set "0px" to any InFlowPositioned elements with both "top: auto" and "bottom: auto". If we set the "opposite" of top, which is bottom, to non-auto value, e.g. 5px, the function getComputedStyle.Top would return the "used value" negative bottom -5px.

Any comments?

I can't comment on spec (maybe rbyers@chromium.org can?). But from application side of things this is misleading and hard to use. E.g. if a `position:sticky` element has `top:auto` this explicitly means "no sticking to top". Having `0px` returned in this case makes it impossible for application script to discover this and correctly process it. At the very least this is worth calling out as a notable platform misconnect.

Yeah I can see how returning 'auto' would be preferable for the application here. Since that's what Safari and Firefox are doing, perhaps we should open an issue on the spec to discuss with CSSWG?

For the other InFlowPositioned element cases do blink, Edge and Gecko all match in returning the used 0px value?  Or is there an interop issue beyond just position: sticky?

With other styles, e.g. `position:fixed` the behavior is still different. Chrome and Firefox generally agree and resolve `top:auto`, e.g. as `top:100px`. Safari still reports `top:auto`. Safari's behavior is more convenient here as well, since with `position:fixed` `top:auto` and `top:X` have very different meaning. But the bottom-line is the same: there's no cross-browser compatibility.

Interesting, thanks.  Seems like we should really have two different APIs - one that returns the compute style and one that returns the used style.  I'll chat with some folks at the CSSWG meeting to see what they suggest.

I'd really like that API. It could be even the same getComputedStyle, but the resulting CSSStyleDeclaration interface could have another method, e.g. `getPropertyValue()` vs `getDeclaredPropertyValue()`.

flackr@ you had some take-aways from our CSSWG side discussion on this that you were going to capture here, right?  I already forget exactly what they were, sorry ;-)

But IIRC the spec is somewhat confusing.  fantasai@ and tabatkins@ told us we need to be careful to distinguish between auto as a "length" (in which case the used style will be a number) and when it's instead not an actual length and so pretending their is a length (like 0px) would be wrong.  At the very least we need some web-platform-tests around this to clarify exactly what is intended (and perhaps also a clarification in the spec).

Right, sticky is certainly different than relative as auto has different very different behavior from 0, so I believe we should be returning auto in the computed style as other browsers do. It's worth noting the computed style behavior is pretty inconsistent across browsers today:

Computed style of top: auto (test page http://output.jsbin.com/wunoxod/quiet) :

position:   static  relative  sticky   absolute  fixed
Chrome 58   auto    0px       0px      224px     296px
Firefox 53  auto    0px       auto     224px     296px
Edge 14     auto    auto      n/a      auto      auto
Safari 10   auto    auto      auto     auto      auto

For position relative, returning a length or auto has very little difference. For every other position type though, if you were to set the returned length value it would have implications to the layout position. For fixed if you used the bottom value it would now track the viewport size, for absolute it would no longer move with layout, and with sticky it starts moving with scroll.

I'm inclined to think that we should be returning auto for at least everything that's not position: relative.

I agree. Returning `bottom:296px` instead of `bottom:auto` for fixed and sticky elements is hugely misleading. I think we moved toward Firefox on these. And I believe this happened as recently as Chrome 54. So, perhaps this is still a good time to reconsider and maybe convince Firefox to do the same along the way.

The spec says that top/bottom/left/right on getComputedStyle are used values[1] for backwards compatibility with sites relying on the old definition of computed style. Despite this, Safari 10 seems to return computed values (e.g. '50%' is returned from http://output.jsbin.com/mepoxe), while only auto returns a non length on Edge. Is there an argument to be made that auto does not represent a positioned value and so the used value is auto? In any event it's pretty clear that left/right/top/bottom have special meaning for sticky, so auto for sticky is very different from 0px and we should at least return auto in this case. We can open a separate bug for discussion on the more generic point about other positions.

[1] https://drafts.csswg.org/cssom/#resolved-values

SGTM, thanks.  Please file a spec issue to clarify the situation for sticky, and an additional chromium bug to track the lack of interop for the position:fixed cases, add drop the links back here.

Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=720366
Spec issue: https://github.com/w3c/csswg-drafts/issues/1346

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c6fcc669f0a2e7d8f9cbf99704a1ca4ca3a8c77f

commit c6fcc669f0a2e7d8f9cbf99704a1ca4ca3a8c77f
Author: yigu <yigu@chromium.org>
Date: Fri May 12 02:20:39 2017

Update return value of getComputedStyle for sticky elements

Top/bottom/left/right have special meaning for sticky elements. So when
calling getComputedStyle on sticky elements whose style contains
"top: auto;", we should return "auto" rather than "0px" to eliminate
ambiguity.
Chromium followed the spec which specifies that getComputedStyle should
return used value (0px) for sticky elements with "top: auto;". That is
incorrect. A spec issue has been added:
https://github.com/w3c/csswg-drafts/issues/1346

BUG= 703816 
TEST=LayoutTests/fast/css/sticky/sticky-top-auto-get-computedstyle.html

Review-Url: https://codereview.chromium.org/2870983002
Cr-Commit-Position: refs/heads/master@{#471185}

[add] https://crrev.com/c6fcc669f0a2e7d8f9cbf99704a1ca4ca3a8c77f/third_party/WebKit/LayoutTests/fast/css/sticky/sticky-top-auto-get-computedstyle.html
[modify] https://crrev.com/c6fcc669f0a2e7d8f9cbf99704a1ca4ca3a8c77f/third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp