[css-overflow-5] Active marker in 2d scroller?

[flackr]

When you have a group of scroll targets in a scroller that can scroll in multiple directions, how do you determine which one is active?

Options:

1. Declare a primary direction to use in some manner. This could be a property on the scrolling container indicating, or on the marker group / pseudo marker group creation. My preference here would be to use something like the primary-overflow-direction from Setting the primary scrolling direction for a scroll container #10060.
2. Automatically infer a primary direction to use. We could do this until a mechanism for declaring a direction exists / continue to support it with an automatic value. The automatic direction would likely be either the direction with more scrollable overflow.
3. Use both axes of scroll in the determination of the active marker. We could possibly do this by using the distance from the current target scroll position to the marker's aligned positions.

With options 1 and 2, we could use the single direction as the primary direction but still use the secondary direction when the targeted location in the primary direction is the same. E.g. the first step could be determining the active set of markers on the primary direction, then repeat with the secondary direction.

[flackr]

I think I'd propose we go with option 2, choosing the direction with more scrollable overflow, as the primary axis and in the case of a tie choosing the block axis. I could be convinced that for predictability we should go with option 1, however I am somewhat concerned with doing this if we don't have the mechanism for changing the primary axis as many of the use cases we're imagining would be in the non-default horizontal axis.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-5] Active marker in 2d scroller?, and agreed to the following:

• RESOLVED: For a 2D scroller, we will define an algorithm that uses a primary direction that defaults to the block axis

The full IRC log of that discussion

<andreubotella> flackr: deterrmining what is the current target is typically done in a single access in most scrollers
<andreubotella> flackr: however, you can have a scroller that scrolls both horizontally and vertically
<andreubotella> flackr: we need to define something that works well for the plain horizontal and vertical cases, as well as combined cases
<andreubotella> flackr: proposal to have a primary direction, where we choose that axis first and choose the current position in that axis
<andreubotella> flackr: and for every target which is current in that axis, you check the secondary direction
<andreubotella> flackr: currently primary axis follows writing-mode, but we have discussed horizontal scrolling
<andreubotella> astearns: using the primary direction first is simpler, but are there case where the proximity in the minor axis is much closer and it'd make sense to use that?
<andreubotella> flackr: my temptation is to avoid having too much complexity until we determine there's a need
<andreubotella> flackr: my preference is to do this major, then major axis solution, and only consider other things if there are use cases
<andreubotella> PROPOSED RESOLUTION: Define this algorithm in terms of the primary direction, which would be the block axis
<andreubotella> flackr: this is in the spec as a recommended algorithm
<andreubotella> flackr: maybe we should have a separate issue for making it normative
<andreubotella> flackr: maybe the best thing would be to put the requirements normative, but the algorihtm non-normative
<andreubotella> fantasai: this seems resonable for document that primarily scroll in one direction
<andreubotella> fantasai: but what if you have a small viewport in a larger one?
<andreubotella> flackr: as long as the tiles are aligned in the primary axis, it'd work as expected
<andreubotella> flackr: this gets less good if your tiles are not aligned in a grid (e.g. staggered)
<andreubotella> flackr: that would select based on the primary axis, which might not be best always
<andreubotella> fantasai: we should take into account what's on the screen
<andreubotella> fantasai: based on primary direction, it'd be good as long as you can't target thigns you can't see
<andreubotella> flackr: targetting things you can see is important for headers of a section, which might be scrolled out of view while in the section
<andreubotella> flackr: if you're making soemthing 2d, maybe you dont' want scroll markers
<andreubotella> flackr: most use cases would be 1d
<kizu> q+
<andreubotella> florian: what if there's a 1d path laid out through 2d in some way?
<astearns> ack kizu
<andreubotella> kizu: maybe we could have a switch for behavior, selecting one marker vs several
<andreubotella> kizu: in 2d it could be useful if you have multiple selected elements in a grid
<andreubotella> kizu: but we can experiment later
<andreubotella> flackr: we have had mentions of a different selector to match multiple, which could be useful in that case (e.g. :target-visible)
<andreubotella> PROPOSED RESOLUTION: For a 2D scroller, we will define an algorithm that uses a primary direction that defaults to the block axis
<andreubotella> RESOLVED: For a 2D scroller, we will define an algorithm that uses a primary direction that defaults to the block axis