- From: Daniel Holbert via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Feb 2025 17:12:28 +0000
- To: public-css-archive@w3.org
dholbert has just created a new issue for https://github.com/w3c/csswg-drafts: == [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 == https://drafts.csswg.org/cssom-view/#determine-the-scroll-into-view-position > 6.1. [Element](https://dom.spec.whatwg.org/#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**" (emphasis added) The spec text there seems to say to use the writing-mode *of the scroll 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 may be pretty chaotic as notedi n 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. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11796 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 27 February 2025 17:12:29 UTC