[cssom-view] scrollIntoView spec text ("determine the scroll-into-view position") disagrees with browser behavior on which writing-mode(s) to use to determine sides

[dholbert]

https://drafts.csswg.org/cssom-view-1/#determine-the-scroll-into-view-position

6.1. Element Scrolling Members
To determine the scroll-into-view position of a target [...]
[...]
Let scrolling box edge A be the beginning edge in the block flow direction of scrolling box, and let element edge A be target bounding border box’s edge on the same physical side [...]
[...]
If block is "start", then align element edge A with scrolling box edge A.

(emphasis added by me)

The spec text there seems to say to use the writing-mode of the scrolling box to decide how to interpret the inline and block options that were passed to scrollIntoView (i.e. how to decide what physical axis/side to use for for "inline: {start/center/end}" etc).

In a situation where there are nested scroll containers, this^ will potentially produce a different axis/edge for each scroll box.

This results in behavior that feels pretty chaotic, as noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1789464#c20 , and it's not what browsers actually do. Chromium, WebKit, and Gecko (in Nightly as of ~today) instead use the writing-mode of the target element to decide what physical axis/side to use; and they use that same answer for all of the nested scroll containers that need to be scrolled.

That seems to be simpler and be more intuitive than what's in the spec. Probably we should update the spec to match that behavior, both because it seems preferable and also to match the reality of what browsers are actually doing.

[dholbert]

Here's a testcase: https://bug1789464.bmoattachments.org/attachment.cgi?id=9468983

As noted in the testcase: when you click the button to call...

  myElem.scrollIntoView({
      behavior: "smooth",
      inline: "center",
      block: "start",
    });

... all major browser engines (Chrome 135 dev, Safari 18.3, and Firefox Nightly 137.0a1 (>= 2025-02-27)) interpret "inline" and "block" in terms of the target element, rather than interpreting it in terms of the scroller boxes.

Specifically, browsers scroll both scroll-containers such that the blue box ends up at the left edge and vertically centered in each of the scroll containers. (And these choices of position come from interpreting the "inline" and "block" options in terms of the target element's writing-mode, rather than the scrollers' writing modes.)

If we instead did what the spec said, we'd end up with the blue box vertically-centered and right-aligned in the inner scroller, and then horizontally-centered and top-aligned in the outer scroller -- see a screenshot-mockup of that result in https://bugzilla.mozilla.org/show_bug.cgi?id=1789464 (which is based on a slightly different version of the testcase so the surrounding content looks a bit different but the idea is the same). In other words, we'd end up the two scrollers having disagreeing alignment targets for each physical axis, which produces a confusing result that's harder to intuitively map back to the inline/block parameters that were passed in.