[css-overflow-5] ::scroll-marker should determine inherited interactivity from ::scroll-marker-group

[flackr]

It's common practice to make the offscreen pages in a carousel inert, however, the ::scroll-marker pseudo-elements generated for them should not be. In general, it would make sense for them to inherit their interactivity from the ::scroll-marker-group as this is the control into which they are placed.

E.g. in the following example, only the current page is interactive, but the markers to go to the other pages are expected to be interactive.

<style>
.scroller {
  scroll-marker-group: after;
  overflow: auto;
  scroll-snap-type: x mandatory;
}
.page {
  interactivity: inert;
  @container scroll-state(snapped: inline) {
    interactivity: auto;
  }
}
.page::scroll-marker {
  counter-increment: page;
  content: counter(page);
}
</style>
<div class=scroller>
  <div class=page></div>
  <div class=page></div>
  <div class=page></div>
  <div class=page></div>
</div>

[flackr]

If actually inheriting from the scroll marker group is difficult, we could disallow interactivity on ::scroll-marker and have its used interactivity be that of the containing ::scroll-marker-group. This would mean that authors couldn't individually control the interactivity of the scroll markers, only the entire group, which doesn't seem like there's much of a need for. I suspect we could revisit this.

[vmpstr]

In the same spirit, it may be worth considering visibility: it may be a little strange for a visibility: hidden item to get a marker that is also visibility: hidden. There may be other properties as well (user-select maybe?)

[css-meeting-bot]

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

The full IRC log of that discussion

<TabAtkins> flackr: the a11y guidelines for carousel recommend inerting content that's not on screen
<TabAtkins> flackr: but if you inert the element that establishes the smarker, th emarker appears in a different spot
<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
<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
<TabAtkins> +1
<TabAtkins> astearns: so resolution is interactivity of ::scroll-marker is based on interactivity of ::scroll-marker-group
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: interactivity of ::scroll-marker is based on interactivity of ::scroll-marker-group
<TabAtkins> fantasai: there's a comment in the issue about visibility too
<TabAtkins> flackr: i'm open to doing this with more properties, but maybe we take those as separate resolutions
<fantasai> TabAtkins: visibility also doesn't have same issue as interactivity, no a11y recommendations
<fantasai> TabAtkins: if doing visibility it's up to you to manage
<TabAtkins> fantasai: so ::scroll-marker originates from the element that generates it, correct?
<TabAtkins> fantasai: but in the box tree it's a child of ::scroll-marker-group
<TabAtkins> fantasai: where does it inherit from?
<TabAtkins> flackr: its originating element
<TabAtkins> fantasai: i think that's part of the confusion here. seems author would probably want it inheriting from scroll-marker-group
<TabAtkins> flackr: there are some... it's useful to inherit ccustom properties from the target to set styles or content on the marker
<TabAtkins> flackr: so it's a bit of a mix
<fantasai> TabAtkins: when we support scroll markers that are real elements, much harder to change their inheritance patterns
<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
<TabAtkins> s/florian/fantasai/
<TabAtkins> fantasai: they'll get their color from their in-flow parent instead
<TabAtkins> flackr: when we have real-element scroll markers, they *will* be children of the group
<TabAtkins> flackr: there are just a lot of use-cases where it's useful to refer to properties in what it's pointing to
<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.
<TabAtkins> flackr: i suppose inheriting a counter is useful. you don't always want them to be counted separately
<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
<TabAtkins> astearns: i think this is something we should consider, but not sure we'll get to a resolution on changing that today
<TabAtkins> flackr: does it make sense to resolve on interactivity, and have an issue on inheritance generally?
<TabAtkins> astearns: yes, people not in the room that probably have opinions
<TabAtkins> flackr: i'll file an issue