-
Notifications
You must be signed in to change notification settings - Fork 657
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css3-positioning] [cssom] getComputedStyle should return "auto" for position:sticky if applicable #1346
Comments
/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. |
"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".) |
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. |
We probably want to generalise this issue to cover the |
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: w3c/csswg-drafts#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}
Here is the chromium bug w.r.t. the return value of fixed positioned elements. |
Hi, what about return if the |
@tabatkins as per @gsnedders suggestion should getting the computedStyle for the following:
also return auto? |
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.) |
@tabatkins I have no preference here; I just meant the issue itself should consider behaviour for both |
Okay, well, since |
Thanks @tabatkins and @gsnedders :) |
FWIW, I believe both |
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. |
do we have any tests for this in wpt yet? |
It seems that cssom/getComputedStyle-insets-sticky.html tests this behavior. |
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.
The text was updated successfully, but these errors were encountered: