Skip to content

[css-overflow-5] What is the active :checked marker when some markers point to elements within different scrolling containers? #11098

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
flackr opened this issue Oct 28, 2024 · 8 comments

Comments

@flackr
Copy link
Contributor

flackr commented Oct 28, 2024

With <a> elements, it is possible to link to any content anywhere on the page. This means that we can create a scroll marker group where multiple markers might be respectively active. E.g.

Nested scrollers might be used within sections of contents:

<div focusgroup>
  <ol>
    <li><a href="#s1">Section 1</a>
      <ol>
        <li><a href="#s1_1">Subsection 1</a></li>
      </ol>
    </li>
    <li><a href="#s2">Section 2</a>
      <ol>
        <li><a href="#s2_1">Subsection 1</a></li>
      </ol>
    </li>
  </ol>
</div>
<h1 id="s1">Section 1</h1>
<div class="scroller">
  <h2 id="s1_1">Subsection 1</h2>
</div>

Sibling / cousin scrollers (I'm less sure of the use case but it would need a defined behavior):

<div focusgroup>
  <ol>
    <li><a href="#i1">Item 1</a></li>
    <li><a href="#i2">Item 2</a></li>
  </ol>
</div>
<div class="scroller">
  <h1 id="i1">Item 1</h2>
</div>
<div class="scroller">
  <h1 id="i2">Item 2</h2>
</div>

In both of these cases there are many scroll markers which could be said to be :checked as their nearest ancestor scrolling element is currently scrolled to them.

@flackr
Copy link
Contributor Author

flackr commented Oct 28, 2024

I think to handle this in a general way we should find the common ancestor scrolling container (and tree of contained scrolling containers) of all of the scroll markers in the group, and then work from the top-down to first find the active scroller, then repeat within that until you arrive at a particular marker.

@flackr
Copy link
Contributor Author

flackr commented Oct 30, 2024

To make this proposal more concrete. The proposed way to select the active marker among targets in different scrolling containers is as follows:

Define/share an algorithm for determining the active target for a list of targets in a single scroller (which as discussed in #10917 will for now will be a bit flexible),
To determine the active marker, we start from the root (or the nearest ancestor scrolling container) S. Then

  1. Let targets be all of the scroll targets whose scrolling container is S, and all of the scroll containers within S which have descendent scroll targets.
  2. Find the active target T amongst targets in S.
  3. If T is not a scroll target, let S = T and repeat from step 1.
  4. Return T as the active target.

This defines reasonable behavior that ensures a target is only active if all of its ancestor scrolling containers to the common ancestor scroll container are also in a position to be considered active (i.e. onscreen and more closely aligned than other targets).

@fantasai
Copy link
Collaborator

I think for the siblings case, we might want to allow multiple active scroll markers. For the ancestors case, probably requiring all ancestor scroll containers to be visible makes sense; but I'm not 100% sure if that necessarily means that the ancestors would be considered active if they were the target themselves.

@tabatkins
Copy link
Member

Hm, for the ancestors case I've seen both behaviors; for example, in a ToC scroll indicator, I've seen both "just indicate the single most relevant entry" and "indicate the most relevant entry and all ancestors, since you're also in them"; I think the latter is sometimes done with a slightly different styling on the ancestors.

We might want to track and expose both of these concepts; select the single most relevant marker in a group and let it match :target-current, but also define a :target-current-all pseudo that'll match the current target, its ancestors (if they're also possible scroll markers in the group) and other scroll markers that could in theory be considered "relevant", except that another visible marker target is already considered more relevant.

@flackr
Copy link
Contributor Author

flackr commented Jan 13, 2025

Hm, for the ancestors case I've seen both behaviors; for example, in a ToC scroll indicator, I've seen both "just indicate the single most relevant entry" and "indicate the most relevant entry and all ancestors, since you're also in them"; I think the latter is sometimes done with a slightly different styling on the ancestors.

We might want to track and expose both of these concepts; select the single most relevant marker in a group and let it match :target-current, but also define a :target-current-all pseudo that'll match the current target, its ancestors (if they're also possible scroll markers in the group) and other scroll markers that could in theory be considered "relevant", except that another visible marker target is already considered more relevant.

Wouldn't the most common way developers would style the ancestors of the inner active marker be with :has, e.g. something like

.target:has(.target::scroll-marker:target-current)::scroll-marker {
  /* Style ancestor markers of the current scroll marker */
}

@flackr
Copy link
Contributor Author

flackr commented Jan 13, 2025

I think for the siblings case, we might want to allow multiple active scroll markers.

For this I would imagine having a separate selector like @tabatkins mentioned, e.g. :target-current-all. We must have a single "active" marker that gains focus when you tab into the ::scroll-marker-group.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-overflow-5] What is the active :checked marker when some markers point to elements within different scrolling containers?, and agreed to the following:

  • RESOLVED: Adopt everything in the Oct 30 comment
The full IRC log of that discussion <andreubotella> flackr: with scroll markers created by anchor links, we can link to scroll targets created in various elements
<andreubotella> flackr: how do we determine what's the target created by :target-current/
<andreubotella> flackr: My proposal, if the scroller is not considered to be current, none of the container scrollers are current, and if it is, you check the subscrollers
<flackr> s/none of the container scrollers/none of the markers within it
<andreubotella> florian: makes sense to me
<andreubotella> florian: I wonder if a similar logic could be used for the discussion in https://github.com//issues/10916: only things in the nested one match if the scroller is currently marking
<andreubotella> flackr: that would work
<andreubotella> flackr: fantasai's comment about the siblings case is that, with two scrollers only one of them is current, and only the target within the scroller is given :target-current
<andreubotella> flackr: that use case might be better served by multiple scroll contain groups
<andreubotella> flackr: not sure if you'd want to have more than one scroll marker within a scroll target group
<andreubotella> fantasai: if you have one scroller, and the subscrollers are in sequence, and it's clear one is active and the others aren't, that makes sense
<andreubotella> fantasai: but what if you have a 3-column view and one is the ToC and the others are scrollers?
<andreubotella> fantasai: I'm fine starting with this and see what crazy ideas kizu comes up with
<andreubotella> flackr: I'm not sure what I'd even expect in that case
<andreubotella> florian: This is a common theme with this proposal, many ways you could design it, but we need to pick a design you'd use in most common cases
<andreubotella> florian: and then get author feedback
<andreubotella> florian: I don't think there's a generic solution that handles everything
<andreubotella> PROPOSED RESOLUTION: Adopt everything in the Oct 30 comment
<andreubotella> fantasai: and wait for kizu to experiment :)
<andreubotella> RESOLVED: Adopt everything in the Oct 30 comment

@flackr
Copy link
Contributor Author

flackr commented Feb 25, 2025

Example algorithm follows the resolved approach: https://drafts.csswg.org/css-overflow-5/#example-d2ca6884

@flackr flackr closed this as completed Feb 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants