Re: [csswg-drafts] [css-overflow-5] Active marker in 2d scroller? (#11198)

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`

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


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


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

Received on Wednesday, 22 January 2025 16:39:29 UTC