[css-scroll-snap-2] Why does scroll-start-target have separate block and inline values?

[flackr]

css-scroll-snap-2 scroll-start-target lets you define any element to be the starting position in either or both the block and inline axes. Does it ever make sense that you would want to scroll to one element in the block axis and a different one in the inline axis? Doing this could result in both of the targets not being visible, e.g.

<style>
#a, #b {
  position: absolute;
}
#a {
  scroll-start: none auto;
  left: 300vw;
}
#b {
  scroll-start: auto none;
  top: 300vh;
}
<div id="a"></div>
<div id="b"></div>

The browser would scroll to (300vw, 300vh) resulting in neither element being in view.

Proposal: Assuming there are no use cases for this behavior, make scroll-start-target a single value property which scrolls to the target in both or neither axes.

[argyleink]

a use case is an overflowing table, where the author wants to presnap/have already scrolled to a row and a column: https://codepen.io/scottjehl/pen/abJrPOP

this allows authors to scroll-start to a row target and to a column target.

[flackr]

If the table had explicit <col> elements maybe we could scroll to the intersection of all scroll-start-targets - also giving an answer for how we handle multiple targets?

Also, I noticed that the spec says:

If the second value is omitted, it defaults to none.

This means that if a developer naively sets scroll-start-target: auto on some element it won't scroll into view in the inline axis, right? This seems surprising.

[argyleink]

developer naively sets scroll-start-target: auto on some element it won't scroll into view in the inline axis, right? This seems surprising

scroll-start-target-inline: auto would, but I do like the suggestion 👍🏻 seems more surprising to have it not work in that shorthand case, then to have it work.

scroll to the intersection of all scroll-start-targets

I hadnt considered a spec entry for intersection, like asking the browser to try and find the best scroll position given a target for each axis? i'm leaning towards a preference of being declarative about a scroll axis and requiring authors to specify which item they want scroll to start at. but i do clearly see how they can compete, where one item as the scroll target naturally puts the other out of view. Let me build some demo's, it may help us shake out the right behavior.

handling multiple targets

i'll make a demo or two about this also, so we have something tangible to talk about.