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