Open Zhang-Junzhi opened 6 years ago
I am wondering who should look into this issue. Seems there is no editor for cssom-view for now.
@zcorpan Please help take a look at this issue. From what I understand, the values of ScrollTop and ScrollLeft seem implementation-defined. Does the spec intentionally mean it? Or is it a bug?
Thank you!
It's not intended to be implementation-defined, but it depends on CSS to somewhere define default scroll position.
@zcorpan Thank you for the reply, so it confirms this issue.
cc @cathiechen
I created a test case: https://people.igalia.com/fwang/scrollLeft-scrollTop.html
WebKit and Gecko always set the original values to scrollLeft = 0, scrollTop = 0 (which seems natural to me) while Chromium seems to behave differently.
@RByers Do you know anything about this compat issue?
When calculating the x-coordinate of leftward overflow direction scrolling box, https://drafts.csswg.org/cssom-view/#scroll-an-element says:
If box has leftward overflow direction Let x be min(0, max(x, element padding edge width - element scrolling area width)).
It somehow expects x to be nonpositive, otherwise the calculated value of x will always be 0. So the default scroll position is expected on the right side.
Regarding the upward overflow direction scrolling box, the default scroll position is expected on the bottom side.
If box has upward overflow direction Let y be min(0, max(y, element padding edge height - element scrolling area height)).
Yes, I agree that from the definition of the spec, the coordinates x, y will be converted so that
This is a generalization of the old #1354 ; it seems that WebKit's behavior was changed to match Gecko & the spec. But Blink kept the old behavior.
This is a generalization of the old #1354 ; it seems that WebKit's behavior was changed to match Gecko & the spec. But Blink kept the old behavior.
Chromium follows the same behavior in beta/canary. Since version 85, the stable version has the new behavior under a finch flag (which means it only enables that behavior with a certain probability). https://www.chromestatus.com/feature/5759578031521792
https://drafts.csswg.org/cssom-view/#scrolling-area-origin says:
Although almost all the browsers have interoperably implememnted the default scroll position in the same way(E.g. Topleft side for writing-mode: horizontal-tb; direction: ltr;. Topright side for writing-mode: vertical-rl; direction: ltr;. Bottomright side for writing-mode: vertical-rl; direction: rtl;), that doesn't mean that the default scroll positions in all browsers are necessarily the same, they are still theoretically implementation-defined. So the origin of a scrolling area which depends on the default scroll position also becomes implementation-defined.
Then about
ScrollTop
andScrollLeft
, the spec says at https://drafts.csswg.org/cssom-view/#dom-element-scrollTop:So the values of
ScrollTop
andScrollLeft
depend on the origin of a scrolling area, which then depends on the implementation of the user agent, which effectively makes the values ofScrollTop
andScrollLeft
implementation-defined.So I think the spec needs to standard-define them, we just shouldn't rely on anything implementation-defined such as the so-called default scroll position. I personally suggest the spec be explicit for every combination of
writing-mode
anddirection
about what the origin of a scrolling area is.