w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.51k stars 669 forks source link

[css-overflow-5] Creating scroll-marker groups within which to select an active marker #10916

Open flackr opened 2 months ago

flackr commented 2 months ago

In order to be able to select one active scroll marker among many potential options, we need a way to establish a group of scroll markers.

In https://flackr.github.io/carousel/examples/scroll-marker/scrolltarget/ there are situations in which more than one group is desired (TOC section selector on left is one group, chapter selector icons on right is another group), as well as where some anchor links should not be part of the group (e.g. the inline links to other sections within the document should not be made active.

The current draft specification establishes a group by having an ancestor with a specified focusgroup value, however there are other options. Should we:

  1. Continue to use focusgroup as the mechanism for creating a scroll marker group. It seems to have the correct semantics, though there we may want an alternative as:
  2. Add a named mechanism. If so, we'd have to decide whether this is:

    • An HTML attribute? E.g. similar to radio group's name attribute, however name already has a defined meaning on links so we would need to choose something else, maybe group?
    • A CSS property?

    And whether this is a property on each participating link (similar to radio buttons) or on an ancestor (similar to focusgroup).

These options are not necessarily mutually exclusive. We could implicitly create marker groups from focusgroup, but also allow explicitly putting them in a named group.

josepharhar commented 1 month ago

I can see in the linked demo that there is a table of contents on the left and circles on the right. Is the idea that each of these things would have focusgroup on them? What would the author code look like?

Edit: Maybe I'm just not up to speed on this work, I thought that the use case involved generated pseudo-elements that I've seen in other carousel use cases

css-meeting-bot commented 1 month ago

The CSS Working Group just discussed [css-overflow-5] Creating scroll-marker groups within which to select an active marker, and agreed to the following:

The full IRC log of that discussion <fantasai> flackr: ::scroll-marker() have an implicit element [missed]
<fantasai> flackr: but when using anchor tags to create scroll markers, the grouping mechanism needs to be explicit
<fantasai> flackr: currently proposal is to use ? as focusgroup
<fantasai> flackr: do we want to do this? should that be dependent on focusgroup existing?
<fantasai> flackr: should we add a specific attribute name or something on ancestor of elements?
<fantasai> flackr: My suggestion was stick with focusgroup as container of elements
<fantasai> flackr: ergonmically it means any time you create a group of scroll markers they will have arrow navigation among them
<fantasai> flackr: because that's what focusgroup does
<fantasai> flackr: it'll also pull in any focusable elements
<fantasai> Rossen6: what's the proposal?
<fantasai> flackr: outside of CSS, but would push for an attribute, either on links themselves to how radio buttons have a name
<fantasai> flackr: or attribute on an ancestor
<fantasai> flackr: to capture all of the anchors as a marker group
<fantasai> flackr: I would propose explicit name as more reasonable alternative
<fantasai> Rossen6: was this already socialized beyond CSS, with a11y or HTML folks?
<fantasai> flackr: original proposal was socialized
<kbabbitt> q+
<fantasai> Rossen6: seems reasonable for now...
<lea> q-
<fantasai> fantasai: this doesn't affect making a scroll marker, just navigation among them
<fantasai> flackr: we need to choose the active marker among a group of active markers
<fantasai> flackr: need a group to select from
<Rossen6> ack kbabbitt
<fantasai> kbabbitt: suggestion to change, alternative mechanism, was there feedback? or just something you were thinking about?
<fantasai> flackr: not based on author feedback, but more spec concern that focusgroup is not yet specced
<fantasai> flackr: so relying on a feature to develop the HTML version of this that still needs to pull out into its own spec
<fantasai> kbabbitt: but ?? does use a named identifier
<fantasai> flackr: if we have concrete proposal, happy to take to HTMLWG, but 'name' is not available :)
<kbabbitt> s/??/radio button group/
<fantasai> fantasai: would help to show your demo, so everyone has full context on what you're asking
<fantasai> s/demo/demo and markup/
<Zakim> fantasai, you wanted to ask robert to show the markup so everyone is on the same page
<fantasai> flackr: [projects demo of table of contents of a doc, dots on the right]
<fantasai> flackr: Look at source, we have <ol focusgroup> on the table of contents, ancestor of all the related links
<fantasai> flackr: similarly we have focusgroup on an ancestor of all the circles
<fantasai> flackr: so that's created two scroll marker groups
<fantasai> flackr: where one is active in the left group and one is active in the right group
<fantasai> flackr: the inline links in the doc don't become active because not part of the group
<jarhar> q?
<fantasai> flackr: this is how written now. Alternative would be possibly some sort of name attribute on each link
<kizu> q+
<fantasai> flackr: or add any attribute on an ancestor
<fantasai> fantasai: styling the active one with ...?
<fantasai> flackr: :checked right now. Issue about bikeshedding that name?
<Rossen6> q?
<Rossen6> ack kizu
<fantasai> kizu: I like this proposal, focusgroup sounds like a good way to grou pit
<fantasai> kizu: only thing to have that would be nice would be to opt-out some of the ??
<fantasai> kizu: you might want some of the items excluded, only use prior items. Or even highlight multiple...?
<fantasai> kizu: I guess can just use :has(:checked)
<fantasai> kizu: [missed]
<fantasai> kizu: use case, summary collapsed with elements, if they do not currently display should be excluded from the group?
<fantasai> flackr: that's an interesting question
<fantasai> flackr: if I put display: none in here
<fantasai> flackr: then supposed to select other markers
<astearns> fantasai: I think this should be a style
<dholbert> scribe+
<dholbert> fantasai: I think that this should be a style property rather than an html property
<dholbert> fantasai: if you want your ToC to be different, then yeah, it should be in the html
<lea> +1 fantasai, and we should figure out what the right style primitives are to make this feasible/easy
<dholbert> fantasai: but if you want to change the scroll marker [???] effect, then that should be a property
<dholbert> fantasai: I don't think that doing this markup is the right place to do it
<dholbert> fantasai: so that would mean you wouldn't have the up/down arrow effect. but you'd at least get the :checked styling
<fantasai> flackr: Makes sense
<miriam> +1
<kizu> +1, if it is possible to make it just via CSS, it would be more flexible
<fantasai> flackr: appreciate suggestion of doing as style
<fantasai> PROPOSED: Enabling active scroll marker styling and grouping should be done via CSS properties
<kbabbitt> sgtm
<fantasai> lea: agree with fantasai that this should be a style, but haven't dived deep
<fantasai> lea: but it does seem like styling
<fantasai> Rossen6: others?
<fantasai> Rossen6: objections?
<fantasai> RESOLVED: Enabling active scroll marker styling and grouping should be done via CSS properties
flackr commented 3 weeks ago

Based on the previous discussion and resolution, I propose we add a scroll-marker-contain: auto | none property for grouping scroll-markers. An element having scroll-marker-contain: auto is a scroll marker group container establishing a group of all of the scroll marker elements for which this is the nearest ancestor scroll marker group container.

Having a property on an ancestor rather than having the markers themselves name a group allows for easy re-use. E.g. you can have multiple group containers throughout the page re-used in various components without needing to give them unique names. Name scoping would be possible, but then we would need an ancestor property to scope the name anyways.

We might be able to explain the pseudo grouping behavior by saying that the UA stylesheet includes:

::scroll-marker-group {
  scroll-marker-contain: auto !important;
}

Note that when scrolling we would still set the last-focused element of an ancestor focusgroup to the selected marker so that when used with focusgroup the active marker becomes the tab stop in a focus group with all elements having a tabindex of -1.

fantasai commented 10 hours ago

@flackr, can you outline all the effects of defining a list of links (e.g. a ToC) to be a scroll marker group using the proposed scroll-marker-contain property?

tabatkins commented 9 hours ago

You'd definitely get the scroll-marker-related behaviors - the links are capable of matching :target-current, and the set of links in the group divvy up the document and its scrollers into regions associated with each.

Ideally we'd also get the focusgroup behavior, where the entire group is a single tabstop, the arrow keys move focus within the group, and the group remembers its last selected option when you tab out of it so it can reselect the same one when you tab back to it (or, if you've scrolled since then, it selects the one currently matching how the page is scrolled).

flackr commented 7 hours ago

The main thing is that one of the markers within the scroll-marker-contain: auto group would match :target-current.

Ideally we'd also get the focusgroup behavior, where the entire group is a single tabstop, the arrow keys move focus within the group).

We could apply focus-group behavior or we could leave focusgroup as an independent thing you might want to set. On its own, applying focusgroup only makes it so that when one is focused you can move to the other links by using the arrow keys (see the links on the left-hand side of https://flackr.github.io/carousel/examples/scroll-marker/scrolltarget/ ).

and the group remembers its last selected option when you tab out of it so it can reselect the same one when you tab back to it (or, if you've scrolled since then, it selects the one currently matching how the page is scrolled

This particular behavior is only if you also set tabindex=0 (see the links on the right-hand side of https://flackr.github.io/carousel/examples/scroll-marker/scrolltarget/ ). If there are focusable elements within the focusgroup you can't tell that there is a last focused element

There is also a question of if this changes the activation behavior. Normally activating a link <a href="#target"> will perform a "navigation" updating the URL, and scroll every scroller to the root into view. I think that the simplest would be to keep the full activation behavior (when clicked or focused and activated, not when focusing it via arrow keys in the focus group which would only scroll).