Re: [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 (#11796)

The CSS Working Group just discussed `[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`, and agreed to the following:

* `RESOLVED: use the writing mode of the target element`

<details><summary>The full IRC log of that discussion</summary>
&lt;JoshT> emilio: This is about what the axis for scrollIntoView is<br>
&lt;JoshT> ... should align on what browsers do, which I think makes sense<br>
&lt;JoshT> ... otherwise it's not clear which axis you are targeting from a single....<br>
&lt;JoshT> ... the axis of a scroll container doesn't make sense<br>
&lt;smfr> seems fine<br>
&lt;JoshT> astearns: you are suggesting we change the spec to match what is done by browser engines?<br>
&lt;JoshT> emilio: yes, chrome, safari and firefox<br>
&lt;JoshT> ... IIRC, interpretting the bllock and inline axis relative to the writing modde<br>
&lt;JoshT> dholbert: scroll me to a position i'm on on the inline axis<br>
&lt;JoshT> ... you might have multiple scrollers vertically in one and a different direction in another<br>
&lt;JoshT> ... these could end up doing different things in different ancestors<br>
&lt;JoshT> ... so map it to the physical axis using the writing mode of the element<br>
&lt;JoshT> ... and all scrollers work regardless of writing mode<br>
&lt;JoshT> astearns: is this mostly an edge case?<br>
&lt;JoshT> ... or are there use cases for elements whos writing mode is orthogonal to the scroller?<br>
&lt;JoshT> dholbert: if you have children with a mix of writing modes and you call the fn, you might expect them to do different things regardless of the child<br>
&lt;JoshT> ... but if no one does that, no content depends on that<br>
&lt;JoshT> fantasai: I think it's reasonable for content to have a mix of writing modes. like Japanese magazines. sidebar might be horizontal but headline vertical<br>
&lt;JoshT> ... mix of writing modes in more complex layouts in japanese, but authors not taking advantage of that yet on the web<br>
&lt;JoshT> ... common in magazines<br>
&lt;JoshT> emilio: I think the point is no one can depend on the spec ehavuour because it's not implemented anywhere<br>
&lt;JoshT> fantasai: then that means it's reasonable to change the behaviour<br>
&lt;emilio> q+<br>
&lt;JoshT> ... it's weird because the right thing to do to is to base of the writing mode of the container<br>
&lt;JoshT> dholbert: as soon as you have scrollers with a mix of writing modes, it gets bizarre<br>
&lt;JoshT> ... then it'll be horizontally aligned in one and vertically aligned in another<br>
&lt;JoshT> ... it's chaos. the proposal is to centre on the axis being scrolled into the view<br>
&lt;JoshT> ... disregarding the writing mode of the parents<br>
&lt;JoshT> fantasai: could we take the writing mode of the nearest scroll container and use it for all of them<br>
&lt;JoshT> dholbert: could also work.<br>
&lt;JoshT> ... but if you're interpretting centre on different axis, as long as we decide on a single writing mode to use, that addresses it<br>
&lt;astearns> ack emilio<br>
&lt;JoshT> emilio: on the other hand, that's weird with overflow: hidden<br>
&lt;JoshT> ... I think, can you specify these in physical directions as well with scrollIntoView?<br>
&lt;JoshT> ... if you know the axis to align to, that deals with the mixed writing mode<br>
&lt;JoshT> ... I think what browsers do is the least bad option, TBH<br>
&lt;oriol> https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions doesn't have physical<br>
&lt;JoshT> dholbert: I don't see physical axis in the API<br>
&lt;JoshT> emilio: maybe we should add physical properties<br>
&lt;JoshT> ... can be a separate issue<br>
&lt;fantasai> +1 to adding physical axes<br>
&lt;JoshT> ... I will open an issue for that<br>
&lt;JoshT> astearns: option 1: change spec to use nearest scrolling container. not implemented.<br>
&lt;JoshT> ... option 2: or use the writing mode of the target element. maybe change things in the future once we have a better understanding of content that needs better handling<br>
&lt;JoshT> fantasai: seems a reasonable way forward. should add the physical keywords.<br>
&lt;JoshT> ... both reasonable but option 2 for now<br>
&lt;JoshT> astearns: proposed resolution is scrollIntoView will interpret block and inline axis in terms of the target element<br>
&lt;JoshT> ... with note in spec to use the nearest scroller at some point if we work out a use case to do that<br>
&lt;iank_> could be a separate issue with new keywords if that usecase is valid.<br>
&lt;JoshT> dholbert: I'm mixed on the note. I think emilio's point about ???? makes it intractable<br>
&lt;JoshT> fantasai: we have overflow: clip now<br>
&lt;fantasai> s/????/overflow:hidden/<br>
&lt;JoshT> astearns: we could add a keyword to opt into the new behaviour<br>
&lt;JoshT> ... any objections?<br>
&lt;JoshT> RESOLVED: use the writing mode of the target element<br>
&lt;JoshT> astearns: I don't think we have enough info of the use cases to change it<br>
&lt;JoshT> ... emilio will open an issue on the physical properties<br>
&lt;JoshT> emilio: maybe worth a separate issue on the proposal for a different behaviour. i agree<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11796#issuecomment-2963528849 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 11 June 2025 16:50:36 UTC