Re: [csswg-drafts] [css-overflow-5] Scroll-markers (#10720)

The CSS Working Group just discussed `[css-overflow-5] Scroll-markers`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> flackr: you can imagine this like a ToC for a scrolalble element<br>
&lt;TabAtkins> flackr: in my example, one way to do it is create a set of anchor links to your content<br>
&lt;TabAtkins> flackr: I'm proposing you add `focusgroup` to get the input semantics you expect - can arrow between them, only one is active at a time<br>
&lt;TabAtkins> flackr: And the browser has some tracking to update which one is "active" at a time<br>
&lt;TabAtkins> flackr: if your page only contains top-level sematnic items - a list of items - you can create pseudo-elements for these<br>
&lt;TabAtkins> flackr: this is crucial for autoamtic pagination, like columns, so you can have one marker per page, not one per item<br>
&lt;flackr> https://github.com/flackr/carousel<br>
&lt;TabAtkins> flackr: here's a simple live example, three sections, declared that each creates a scrol lmarker, and they've been flowed into the scroll marker group on the left<br>
&lt;hdv> q+<br>
&lt;TabAtkins> flackr: [showing source] roughly speaking, you add a pseudo-element for each thing that needs a marker, and a scoll-marker-group pseudo is automatically created to hold them<br>
&lt;TabAtkins> hdv: what are the a11y semantics of something that becomes a scroll marker?<br>
&lt;bkardell_> q+<br>
&lt;TabAtkins> flackr: shoudl be whatever makes the most sense for these use-cases. given that we upgrade links, i assume it woudl ahve the same sematnics as an anchor link<br>
&lt;bkardell_> q-<br>
&lt;Patrick_H_Lauke> link with aria-current="true"...<br>
&lt;hdv> ack me<br>
&lt;TabAtkins> TabAtkins: and note that in this example it's *generating* fresh anchor links, they can be whatever. if reusing elements on the page, they have to be links already<br>
&lt;TabAtkins> flackr: this example reuses existing links. The ToC links are in a focusgroup, and we track sc roll progress to indicate which is active<br>
&lt;bkardell_> q+<br>
&lt;TabAtkins> flackr: I also have a separate scroll marker group on the right to track the top-level sections.<br>
&lt;TabAtkins> flackr: each group has its own "current" marker<br>
&lt;TabAtkins> flackr: inline links, not in a focus group, dont' get considered in this, they're never marked as "current"<br>
&lt;flackr> https://drafts.csswg.org/css-overflow-5/<br>
&lt;TabAtkins> flackr: This is the most mature of these specs, it's currently in the CSS Overflow 5 spec<br>
&lt;flackr> https://codepen.io/flackr/pen/MWMLPpP<br>
&lt;TabAtkins> flackr: what i've shown so far is a polyfill, but we have an impl in Chrome Canary with experimental web paltform features turned on<br>
&lt;TabAtkins> flackr: the only content on this page is a bunch of items. they're automatically grouped into pages, with  scroll markers for each page, and next/prev buttons, and it's all automatic from CSS<br>
&lt;TabAtkins> flackr: any questions about scroll markers or move on?<br>
&lt;TabAtkins> bkardell_: This is dependent on the focusgroup attribute? what's the progress on that right now?<br>
&lt;TabAtkins> flackr: to make a scroll marker group from link elements, that's dependent on focusgroup<br>
&lt;TabAtkins> flackr: we implicitly have the semantics for the pseudo-elements, but it doesn't depend on the attribute<br>
&lt;TabAtkins> bkardell_: does the implementation support focusgroup?<br>
&lt;jarhar> q?<br>
&lt;TabAtkins> flackr: the pseudo-element impl has an implementation of focusgroup semantics, by hand. we do have a `focusgroup` impl behind a flag in Chrome, but not shipping yet.<br>
&lt;jarhar> q+<br>
&lt;TabAtkins> flackr: The use of it in my earlier demo used the polyfill<br>
&lt;TabAtkins> ack bkardell_<br>
&lt;bkardell_> q-<br>
&lt;TabAtkins> jarhar: i'm not super familair with the pseudo-element API  shape<br>
&lt;TabAtkins> jarhar: kinda seems like these are more element-like than other pseudos<br>
&lt;TabAtkins> jarhar: we had to make some changes to make them receive events in ways other pseudos can't<br>
&lt;TabAtkins> jarhar: we have, in blink, a pseudoelement class that's a subclass of Element so it kinda works<br>
&lt;TabAtkins> jarhar: talking with Tim, he said their pseudos are more strictly different. might be difficult for them to implement.<br>
&lt;TabAtkins> jarhar: wonder if there are any webkit folks around to talk about<br>
&lt;TabAtkins> flackr: good question. pseudos *can* be targeted by clicks and other events. we hide that the pseudo was targeted (use the owner element instead), but i fyou click on a ::before you can listen for the click event<br>
&lt;TabAtkins> jarhar: and you can use like hover pseudoclass?<br>
&lt;TabAtkins> TabAtkins: Yes, and :focus/:active if they're focusable/etc<br>
&lt;bkardell_>  maybe we can tag ntim so they can find it when there's time and let us know :)<br>
&lt;TabAtkins> flackr: the CSS pseudo spec has a full definition of PseudoElement interface, subclassing Element, so there's a route to them being full-blown event targets<br>
&lt;TabAtkins> jarhar: okay, probably less crazy than i thought it was<br>
&lt;TabAtkins> ack jarhar<br>
</details>


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


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

Received on Wednesday, 25 September 2024 22:11:43 UTC