Re: [csswg-drafts] Add physical axes to scrollIntoView (#12476)

The CSS Working Group just discussed `Add physical axes to scrollIntoView`, and agreed to the following:

* `RESOLVED: Add physical axes (x, y) to scrollIntoView dictionary, and prefer, per axis, logical to physical`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> emilio: came up when discussing writing modes and scrollIntoView<br>
&lt;fantasai> emilio: right now, don't have a way to specify physical axes in scrollIntoview<br>
&lt;fantasai> emilio: seemed everyone was on board to add<br>
&lt;fantasai> emilio: question is what to do if you specify both<br>
&lt;oriol> q+<br>
&lt;fantasai> emilio: my proposal would be to use the logical axis if specified, otherwise physical<br>
&lt;fantasai> emilio: allows decision to be made independently of writing mode of the target<br>
&lt;fantasai> emilio: alternatively ...<br>
&lt;fantasai> emilio: allow to mix them as long as no conflict<br>
&lt;fantasai> emilio: but that's slightly more annoying to implement and also unclear why you'd do that.<br>
&lt;fantasai> emilio: but I'm fine with either<br>
&lt;astearns> ack oriol<br>
&lt;fantasai> oriol: Not clear to me from issue, in case you have a horizontal writing mode and you provide x and block, no conflict<br>
&lt;fantasai> oriol: would we use x or inline falling back to default value<br>
&lt;fantasai> oriol: sebastian assumed we would try to use whatever specified as long as no conflict<br>
&lt;fantasai> oriol: I would also expect that, even though more annoying to implement<br>
&lt;fantasai> emilio: My thought was if any logical, use only logical; otherwise use physical<br>
&lt;fantasai> emilio: I don't know why you'd expect both to be honored<br>
&lt;fantasai> emilio: it would be pretty weird<br>
&lt;fantasai> emilio: also simpler to implement and specify the other version, so slight preference, but either way is ok<br>
&lt;astearns> ack fantasai<br>
&lt;emilio> fantasai: I think it makes sense to try to use the author's information<br>
&lt;emilio> ... so better behavior would be do logical, then physical per axis<br>
&lt;emilio> ... that's how we handle the cascade in CSS for example<br>
&lt;emilio> ... if there's a conflict having logical win seems fine<br>
&lt;SebastianZ> q+<br>
&lt;emilio> ... can't speak for implementation complexity<br>
&lt;fantasai> emilio: implementation complexity wise, only difference is whether you need to pass 4 values or 2 values + flag of whether logical or not<br>
&lt;fantasai> ... kinda trivial either way<br>
&lt;fantasai> emilio: so seems fine to me if it's better behavior<br>
&lt;fantasai> emilio: making it work like logical properties, that convinced me it's better behavior<br>
&lt;astearns> ack SebastianZ<br>
&lt;fantasai> SebastianZ: My idea was if they clash, prefer the logical, if don't, honor both<br>
&lt;fantasai> SebastianZ: if we agree on that, let's resolve on it<br>
&lt;fantasai> PROPOSED: Add physical axes (x, y) to scrollIntoView dictionary, and prefer, per axis, logical to physical<br>
&lt;fantasai> RESOLVED: Add physical axes (x, y) to scrollIntoView dictionary, and prefer, per axis, logical to physical<br>
</details>


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


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

Received on Tuesday, 19 August 2025 13:59:40 UTC