- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jan 2025 16:20:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `https://github.com/w3c/csswg-drafts/issues/10916`, and agreed to the following: * `RESOLVED: Spec scroll-marker-contain` <details><summary>The full IRC log of that discussion</summary> <andreubotella> topic: https://github.com/w3c/csswg-drafts/issues/10916<br> <andreubotella> Github: https://github.com/w3c/csswg-drafts/issues/10916<br> <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<br> <andreubotella> flackr: What that means is, one of those links will have :target-current match<br> <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?<br> <andreubotella> flackr: this would be the thing authors would need to set on their table of contents<br> <andreubotella> florian: You put it on the table of context, and how do we determine which one's current?<br> <andreubotella> flackr: Based on the position of the anchor scrollers<br> <andreubotella> flackr: this is the same algorithm we use for the pseudo-element: the first one that (...)<br> <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?<br> <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<br> <andreubotella> flackr: it would cycle at the same interval as :hover, it's not a tight cycle<br> <andreubotella> flackr: because we're using the position as determined before doing style and layout<br> <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."<br> <andreubotella> florian: I guess you would have to scroll again to reevaluate that and break the loop<br> <emilio> q+<br> <andreubotella> . /s/this/the element having scroll-marker-contain: auto/<br> <andreubotella> fantasai: We need the grouping because we need to compare the different targets in the group<br> <andreubotella> flackr: yeah, we need to compare the different targets to the scroll position to see which is the target<br> <andreubotella> fantasai: what are your thoughts about using the keyword auto?<br> <andreubotella> flackr: it's a keyword which implies "do something semi-smart"<br> <andreubotella> fantasai: is it an on-off value?<br> <andreubotella> flackr: yes<br> <andreubotella> emilio: By resolving on this, are we also resolving on how the targeting would happen?<br> <andreubotella> emilio: I don't know how this would work with the common ToC use cases<br> <andreubotella> flackr: we have had discussions about that, but we need a mechanism to determine which target location is current<br> <kizu> q+<br> <andreubotella> emilio: But for this property, the target locations would be everything (...)<br> <florian> q+<br> <astearns> ack emilio<br> <andreubotella> emilio: If the thing that contains the target is a link to a header, does it do the right thing?<br> <andreubotella> flackr: yes<br> <andreubotella> kizu: do we need anything special for two nested scroll container?<br> <andreubotella> kizu: two containers, one of which has a scroll list<br> <andreubotella> flackr: they would be treated as separate lists<br> <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<br> <andreubotella> s/outer list if something in the inner is current/ (i think)<br> <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<br> <astearns> ack kizu<br> <andreubotella> flackr: having the property be able to be nested the way it is, you could have the property in a (...) contain group<br> <andreubotella> flackr: even the ones that are not in view would have a contain item<br> <andreubotella> flackr: but I suspect you'd only want to use one list<br> <andreubotella> flackr: but there are use cases for multiple list with a single active item<br> <astearns> ack florian<br> <andreubotella> florian: what about multiple links to the same target? do they all become current at the same time?<br> <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<br> <andreubotella> flackr: i think i set the first one is :target-current<br> <andreubotella> flackr: if we can agree at a high level this sounds good, and then we can figure out details, that would be great<br> <andreubotella> PROPOSED RESOLUTION: Spec scroll-marker-contain<br> <andreubotella> florian: having spec text will enable these discussions better<br> <andreubotella> RESOLVED: Spec scroll-marker-contain<br> <andreubotella> astearns: This is specifying just auto?<br> <andreubotella> flackr: `auto` and `none`. we can decide if that's the right name<br> <fantasai> Yeah, I think we need to think about that `auto` keyword<br> <andreubotella> Github: https://github.com/w3c/csswg-drafts/issues/11098<br> <dbaron> github: https://github.com/w3c/csswg-drafts/issues/10916<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-2607685735 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 January 2025 16:20:25 UTC