[cssom-view] The values of ScrollTop and ScrollLeft have been made implementation-defined, the spec needs to standard-define them.

[Zhang-Junzhi]

https://drafts.csswg.org/cssom-view/#scrolling-area-origin says:

The origin of a scrolling area is the origin of the initial containing block if the scrolling area is a viewport, and otherwise the top left padding edge of the element when the element has its default scroll position.

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 and ScrollLeft, the spec says at https://drafts.csswg.org/cssom-view/#dom-element-scrollTop:

Return the y-coordinate of the scrolling area at the alignment point with the top of the padding edge of the element.

Return the x-coordinate of the scrolling area at the alignment point with the left of the padding edge of the element.

So the values of ScrollTop and ScrollLeft depend on the origin of a scrolling area, which then depends on the implementation of the user agent, which effectively makes the values of ScrollTop and ScrollLeft 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 and direction about what the origin of a scrolling area is.

[Zhang-Junzhi]

I am wondering who should look into this issue. Seems there is no editor for cssom-view for now.

[Zhang-Junzhi]

@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!

[zcorpan]

It's not intended to be implementation-defined, but it depends on CSS to somewhere define default scroll position.

[Zhang-Junzhi]

@zcorpan Thank you for the reply, so it confirms this issue.

[fred-wang]

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?

[cathiechen]

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

[fred-wang]

Yes, I agree that from the definition of the spec, the coordinates x, y will be converted so that

• x is nonnegative in rightward direction
• x is nonpositive in leftward
• y nonnegative in downwards direction
• y nonpositive in upwards direction

[fred-wang]

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.

[fred-wang]

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