Re: [csswg-drafts] [css-overflow-5] ::scroll-marker should determine inherited interactivity from ::scroll-marker-group (#11746)

The CSS Working Group just discussed `[css-overflow-5] ::scroll-marker should determine inherited interactivity from ::scroll-marker-group`, and agreed to the following:

* `RESOLVED: interactivity of ::scroll-marker is based on interactivity of ::scroll-marker-group`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> flackr: the a11y guidelines for carousel recommend inerting content that's not on screen<br>
&lt;TabAtkins> flackr: but if you inert the element that establishes the smarker, th emarker appears in a different spot<br>
&lt;TabAtkins> flackr: we think the interactivity of the scroll marker shoulod be based on the interactivey of the scroll-marker-group, which is based on the scroll container<br>
&lt;TabAtkins> flackr: currently authors *could* work aorund this by manually un-inerting with 'interactivity', but it feels like a hack. we should do this implicitly<br>
&lt;TabAtkins> +1<br>
&lt;TabAtkins> astearns: so resolution is interactivity of ::scroll-marker is based on interactivity of ::scroll-marker-group<br>
&lt;TabAtkins> astearns: objections?<br>
&lt;TabAtkins> RESOLVED: interactivity of ::scroll-marker is based on interactivity of ::scroll-marker-group<br>
&lt;TabAtkins> fantasai: there's a comment in the issue about visibility too<br>
&lt;TabAtkins> flackr: i'm open to doing this with more properties, but maybe we take those as separate resolutions<br>
&lt;fantasai> TabAtkins: visibility also doesn't have same issue as interactivity, no a11y recommendations<br>
&lt;fantasai> TabAtkins: if doing visibility it's up to you to manage<br>
&lt;TabAtkins> fantasai: so ::scroll-marker originates from the element that generates it, correct?<br>
&lt;TabAtkins> fantasai: but in the box tree it's a child of ::scroll-marker-group<br>
&lt;TabAtkins> fantasai: where does it inherit from?<br>
&lt;TabAtkins> flackr: its originating element<br>
&lt;TabAtkins> fantasai: i think that's part of the confusion here. seems author would probably want it inheriting from scroll-marker-group<br>
&lt;TabAtkins> flackr: there are some... it's useful to inherit ccustom properties from the target to set styles or content on the marker<br>
&lt;TabAtkins> flackr: so it's a bit of a mix<br>
&lt;fantasai> TabAtkins: when we support scroll markers that are real elements, much harder to change their inheritance patterns<br>
&lt;TabAtkins> florian: so if you set 'color' on ::scroll-marker-group, that doesn't change the color on the ::scroll-markers inside of it, which is a bit surprising<br>
&lt;TabAtkins> s/florian/fantasai/<br>
&lt;TabAtkins> fantasai: they'll get their color from their in-flow parent instead<br>
&lt;TabAtkins> flackr: when we have real-element scroll markers, they *will* be children of the group<br>
&lt;TabAtkins> flackr: there are just a lot of use-cases where it's useful to refer to properties in what it's pointing to<br>
&lt;TabAtkins> fantasai: is it only custom properties? if you set font on scroll-marker-group it doesn't inherit to the markers. if you generate markers from headings and some have various text styles, they'll get a random mix.<br>
&lt;TabAtkins> flackr: i suppose inheriting a counter is useful. you don't always want them to be counted separately<br>
&lt;TabAtkins> fantasai: i think properties hsould inherit from the scroll-marker-group, but originating element is still the target element, so attr() or counter() returns the value from that element<br>
&lt;TabAtkins> astearns: i think this is something we should consider, but not sure we'll get to a resolution on changing that today<br>
&lt;TabAtkins> flackr: does it make sense to resolve on interactivity, and have an issue on inheritance generally?<br>
&lt;TabAtkins> astearns: yes, people not in the room that probably have opinions<br>
&lt;TabAtkins> flackr: i'll file an issue<br>
</details>


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


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

Received on Wednesday, 2 April 2025 15:55:43 UTC