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;bramus> flackr: we previously discussed the issue of a broad set of ways to make it easy for devs to author carousels with css<br>
&lt;bramus> … this is one of the features of that<br>
&lt;bramus> … goals is to have a simple way for devs to create nav markers. typically dots in carousels<br>
&lt;bramus> … but also useful for TOCs<br>
&lt;bramus> … or tabbing mechanism when you have a scrollable tab container<br>
&lt;bramus> … have written up a spec in css-overflow-5 as prevously resolved.<br>
&lt;bramus> … idea is that scroll markers behave as anchor links<br>
&lt;bramus> … but they have one main additional component is that you can trck whichone is the active one<br>
&lt;bramus> … so for a group there is an extra style that applies to the “current one”<br>
&lt;bramus> … you can also create the groups as pseudos automatically for pagination scenarios based on fragmentation<br>
&lt;bramus> … issue is here to get attention on this and to bring everhyone up to speed<br>
&lt;bramus> … how this could work with regular elements ??? by having groups of links<br>
&lt;bramus> … is focusgroup the right thing or should wwe have a group name (for a later discussion)<br>
&lt;kizu> q+<br>
&lt;bramus> … already have 1 proposal in the spec and want concensus on the direction<br>
&lt;astearns> ack kizu<br>
&lt;bramus> kizu: left a comment, like the idea<br>
&lt;bramus> … there is a lot of things with related issues<br>
&lt;bramus> … one aspect that i tink could be quick win<br>
&lt;bramus> … to split off highlighting of currently applied marker<br>
&lt;TabAtkins> +1 from me, I'm v happy with this. Still some work to do but I think the current approach and syntax is good<br>
&lt;bramus> … for all TOCs this would be useful<br>
&lt;bramus> … had a lot of need for this recently<br>
&lt;bramus> … TOC, tab list, etc<br>
&lt;bramus> … need JS for that now with IO<br>
&lt;bramus> … can also use SDA but thats a hack<br>
&lt;bramus> … this one thing could be useful to split off<br>
&lt;bramus> flackr: hadnt got chance to respond on issue yet<br>
&lt;bramus> … in order to do auto selection it requires to have a grouping mechanism<br>
&lt;bramus> … because active item needs to know which group it is in<br>
&lt;bramus> … so that TOC doenst interfere with set of inline links<br>
&lt;bramus> … I dont think that auto creation adds a whole bunch of complexity<br>
&lt;bramus> … if we just focused on active state, then we might forget to allow auto creation<br>
&lt;bramus> … you als mentioned you would like template instantiation<br>
&lt;bramus> … feels like a good thing for filling in content for pseudo elements generally<br>
&lt;bramus> … sth that could be augmented later for markers (and ::before, ::after, etc)<br>
&lt;bramus> … its not mutually exclusive to have pseudos for this now<br>
&lt;bramus> … having whole thing in spec also doesnt mean  vendor has to implement the whole thing<br>
&lt;florian> q+<br>
&lt;bramus> … do see value in having it all specced out now<br>
&lt;florian> q+ astearns<br>
&lt;florian> q- later<br>
&lt;astearns> ack florian<br>
&lt;bramus> florian: way back in the day opera had tried (for frag use case) to have these markers be auto generated or to have an API for devs to suppress that<br>
&lt;bramus> … AFAI remember there was no psuedo element<br>
&lt;bramus> … not saying we shoudl be doing antyhing like this<br>
&lt;florian> https://www.wiumlie.no/2011/reader/<br>
&lt;bramus> … want to raise awareness about that effort<br>
&lt;bramus> … could give some ideas<br>
&lt;fantasai> -> https://drafts.csswg.org/css-overflow-5/<br>
&lt;bramus> flackr: wasnt aware of that specific case but have feedback that authors dont want to write JS to create stuff like this<br>
&lt;bramus> … do see value in purely declarative setup for this<br>
&lt;bramus> florian: absolutely<br>
&lt;bramus> … link I shared is either fully automatic or JS<br>
&lt;bramus> … JS override might be nice<br>
&lt;bramus> … for context: broader thing back then was to be able to opt in to pagination as an alternative to scrolling<br>
&lt;bramus> … they wanted that feature in that context<br>
&lt;astearns> ack astearns<br>
&lt;bramus> … again, purely sharing for awareness reasons and backhistory<br>
&lt;bramus> astearns: where are you with other bits of the process?<br>
&lt;bramus> … implementing things? sending intents? is this getting TAG review?<br>
&lt;bramus> flackr: of course it will go through TAG and what not<br>
&lt;bramus> … have a partial experimental thing in Chrome<br>
&lt;bramus> … to prove that we can have focusable pseudos<br>
&lt;bramus> … and that it supports these use cases<br>
&lt;bramus> … should add a few links with concrete demos in the issue<br>
&lt;bramus> … thats where we are at<br>
&lt;bramus> … want to get consensus on specific shape to push this forward<br>
&lt;bramus> … make sure everyone is happy<br>
&lt;bramus> astearns: other qs or comments?<br>
&lt;astearns> ack fantasai<br>
&lt;bramus> fantasai: great ? to to work on. spec needs a bit more explanation.<br>
&lt;bramus> … makes sense to have ability to have an existing anchor to be both a scroll marker and also having the pseudo<br>
&lt;bramus> … spec doesnt do a good job of pullin gthis together in coheren model<br>
&lt;bramus> … (editorial criticism)<br>
&lt;bramus> … makes sense to pursue this direction<br>
&lt;bramus> … with a little bit of work on the editorial side this would be a reasonable FPWD<br>
&lt;bramus> astearns: cool<br>
&lt;bramus> … what else do you want for this issue, rob?<br>
&lt;bramus> flackr: please open indiv issues on the proposal<br>
&lt;bramus> … will make work of editiroal work<br>
&lt;bramus> astearns: so you dont need resolutions?<br>
&lt;bramus> flackr: we alsready have a resolution to work on this (back february)<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-2315779853 using your GitHub account


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

Received on Wednesday, 28 August 2024 16:19:44 UTC