Add physical axes to scrollIntoView

[emilio]

https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions has logical members but not physical.

As per the discussion in #11796, it seems this might be useful on its own. I think the main question is how to resolve conflicts.

Probably the interface needs to become:

enum ScrollPosition { "start", "center", "end", "nearest" };
dictionary ScrollIntoViewOptions : ScrollOptions {
  ScrollPosition block;
  ScrollPosition inline;
  ScrollPosition x;
  ScrollPosition y;
  ScrollIntoViewContainer container = "all";
};

Then something along the lines of: If any logical side is specified, use them, otherwise use the physical ones (if specified), otherwise default to block: "start", inline: "nearest".

So a bit annoying to write in prose but I think fairly reasonable and easy to implement.

[Loirooriol]

Assuming an horizontal writing mode, scrollIntoView({x: "end", block: "end"} would scroll to logical because block is present, and then fall back the omitted inline to nearest instead of using x: "end"?

[SebastianZ]

Assuming an horizontal writing mode, scrollIntoView({x: "end", block: "end"} would scroll to logical because block is present, and then fall back the omitted inline to nearest instead of using x: "end"?

I assume you mean vertical writing mode, as in horizontal writing modes x matches the inline axis, so there's no clash in that case.

Though when physical and logical values clash, I'd also tend to say the logical value should be preferred, if that's the point you were making.

Sebastian

[Loirooriol]

No, I meant horizontal writing mode. I want to know whether we fall back to physical when there is no clash. It's not clear to me from Emilio's proposal above.

[css-meeting-bot]

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

The full IRC log of that discussion

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