[css-overflow-5] Creating scroll-marker groups within which to select an active marker #10916
Comments
|
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 |
|
The CSS Working Group just discussed
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 |
|
Based on the previous discussion and resolution, I propose we add a 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 |
|
@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 |
|
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 |
|
The main thing is that one of the markers within the
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/ ).
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 |
|
The CSS Working Group just discussed
The full IRC log of that discussion<andreubotella> topic: https://github.com//issues/10916<andreubotella> Github: https://github.com//issues/10916 <andreubotella> flackr: We want to be able to make scroll markers out of existing anchor lines, and this proposal is to add a property scroll-marker-contain to set on an ancestor that contains all of the links in a group of scroll markers <andreubotella> flackr: What that means is, one of those links will have :target-current match <andreubotella> flackr: From the get-go we agreed that this would be the case for (?) elements, so would this be the case for all elements? <andreubotella> flackr: this would be the thing authors would need to set on their table of contents <andreubotella> florian: You put it on the table of context, and how do we determine which one's current? <andreubotella> flackr: Based on the position of the anchor scrollers <andreubotella> flackr: this is the same algorithm we use for the pseudo-element: the first one that (...) <andreubotella> florian: is there a risk that, because it's an element rather than a pseudo-element, it might have contents that are moved out of the way? <andreubotella> flackr: I suppose there's a possibility that you could have a :target-current style that causes the target to no longer be current <andreubotella> flackr: it would cycle at the same interval as :hover, it's not a tight cycle <andreubotella> flackr: because we're using the position as determined before doing style and layout <fantasai> "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." <andreubotella> florian: I guess you would have to scroll again to reevaluate that and break the loop <emilio> q+ <andreubotella> . /s/this/the element having scroll-marker-contain: auto/ <andreubotella> fantasai: We need the grouping because we need to compare the different targets in the group <andreubotella> flackr: yeah, we need to compare the different targets to the scroll position to see which is the target <andreubotella> fantasai: what are your thoughts about using the keyword auto? <andreubotella> flackr: it's a keyword which implies "do something semi-smart" <andreubotella> fantasai: is it an on-off value? <andreubotella> flackr: yes <andreubotella> emilio: By resolving on this, are we also resolving on how the targeting would happen? <andreubotella> emilio: I don't know how this would work with the common ToC use cases <andreubotella> flackr: we have had discussions about that, but we need a mechanism to determine which target location is current <kizu> q+ <andreubotella> emilio: But for this property, the target locations would be everything (...) <florian> q+ <astearns> ack emilio <andreubotella> emilio: If the thing that contains the target is a link to a header, does it do the right thing? <andreubotella> flackr: yes <andreubotella> kizu: do we need anything special for two nested scroll container? <andreubotella> kizu: two containers, one of which has a scroll list <andreubotella> flackr: they would be treated as separate lists <andreubotella> flackr: for common cases, i suspect you would not make the one a separate list, and you'd use (...) to style the inner list if something in the outer is current <andreubotella> s/outer list if something in the inner is current/ (i think) <andreubotella> kizu: if we have a ToC with nested items, we could do two nested containers, and the inner one would only listen to the elements inside <astearns> ack kizu <andreubotella> flackr: having the property be able to be nested the way it is, you could have the property in a (...) contain group <andreubotella> flackr: even the ones that are not in view would have a contain item <andreubotella> flackr: but I suspect you'd only want to use one list <andreubotella> flackr: but there are use cases for multiple list with a single active item <astearns> ack florian <andreubotella> florian: what about multiple links to the same target? do they all become current at the same time? <andreubotella> florian: in a typical ToC example, you typically wouldn't, but maybe depending on how you construct it, both the number and the title are separate links <andreubotella> flackr: i think i set the first one is :target-current <andreubotella> flackr: if we can agree at a high level this sounds good, and then we can figure out details, that would be great <andreubotella> PROPOSED RESOLUTION: Spec scroll-marker-contain <andreubotella> florian: having spec text will enable these discussions better <andreubotella> RESOLVED: Spec scroll-marker-contain <andreubotella> astearns: This is specifying just auto? <andreubotella> flackr: `auto` and `none`. we can decide if that's the right name <fantasai> Yeah, I think we need to think about that `auto` keyword <andreubotella> Github: https://github.com//issues/11098 <dbaron> github: https://github.com//issues/10916 |
It's prototype to investigate scroll-marker-contain property that should collect anchor elements as scroll markers for scroll tracking to determine the `active` one to set :target-current pseudo class on it. w3c/csswg-drafts#10916 Bug: 398065922 Change-Id: I1a15aab4f4342910f9343bab48378e79986c50f1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6287407 Commit-Queue: Daniil Sakhapov <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Cr-Commit-Position: refs/heads/main@{#1423073}
To support scroll-marker-contain property (w3c/csswg-drafts#10916) that should collect anchor elements as scroll markers for scroll tracking to determine the `active` one to set :target-current pseudo class on it, the plan is to support that data(vector of scroll markers and selected scroll marker) and handling logic as element rare data. To do it, this CL first splits that logic and data from ScrollMarkerGroupPseudoElement to ScrollMarkerGroupData, so that ScrollMarkerGroupData can be reused for ::scroll-markers and anchor html elements. There are no behaviour changes, since ScrollMarkerGroupPseudoElement will just dispatch API calls to internal ScrollMarkerGroupData. And in future CLs ScrollMarkerGroupData will be added to ElementRareData. Bug: 398065922 Change-Id: I3773944f5fe3d98dcceb04693661b7ffc730381e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6298347 Commit-Queue: Daniil Sakhapov <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1424344}
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
focusgroupvalue, however there are other options. Should we:Continue to use
focusgroupas the mechanism for creating a scroll marker group. It seems to have the correct semantics, though there we may want an alternative as:Add a named mechanism. If so, we'd have to decide whether this is:
nameattribute, however name already has a defined meaning on links so we would need to choose something else, maybe group?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.
The text was updated successfully, but these errors were encountered: