[css-overflow-5] Giving ::scroll-marker-group a name (and optionally text)

[flackr]

The ::scroll-marker-group pseudo-element is often used to implement a tablist following the tabs pattern, however currently this pseudo-element cannot define content. The tab list should be able to be labeled by the author:

If the tab list has a visible label, the element with role tablist has aria-labelledby set to a value that refers to the labelling element. Otherwise, the tablist element has a label provided by aria-label.

There are a few ways we could address this,

1. @vmpstr has suggested we add alt text to the scroll-marker-group property to give it a label, e.g.

   .scroller {
     scroll-marker-group: before / "Slides";
   }

   This however would not support adding a visual label.

2. Support the full content property with alt text on the ::scroll-marker-group pseudo-element, e.g.

   .scroller::scroll-marker-group {
     content: "Slides";
   }

   This would create the visible text "Slides" preceding the ::scroll-marker pseudo-elements. Alternately, empty content text with alt text could be used to only give it an accessible label without a visual one. The challenge with this model is that it may be difficult to get the layout for the label that you want.

3. Use a ::before pseudo-element to provide content at the start of the ::scroll-marker-group, e.g.

   .scroller::scroll-marker-group::before {
     content: "Slides";
   }

   This would create the visible text "Slides" ::before pseudo-element preceding the ::scroll-marker pseudo-elements. Alternately, empty content text with alt text could be used to only give it an accessible label without a visual one. One benefit over option 2 is that this also allows for customization other properties to better control how the "Slides" text flows w.r.t. the ::scroll-marker pseudo-elements, e.g. display: block | inline-block or position: absolute to label it out of flow.

4. Introduce a new pseudo-element, e.g. ::label?

   .scroller::scroll-marker-group::label {
     content: "Slides";
   }

   This is a less baked idea, similar to option 3 but may allow us to infer more semantic meaning on the generated content (i.e. that it serves as a label for its owning element).

My preference is option 2, as it directly supports also adding the label visually when this makes sense, and feels like a more canonical place to put content for the ::scroll-marker-group than giving it a ::before pseudo-element. This would also be useful when using nested ::scroll-marker-group pseudo-elements #11601 to label subgroups of scroll markers.

However, I think that we should support ::before and ::after (i.e. option 3) on the ::scroll-marker-group and ::scroll-marker pseudo-elements as well as it is just generally useful. I only think requiring this to label the group feels awkward and less intuitive than directly labelling the group.

[fantasai]

Remind me why this use case belongs in CSS rather than HTML?

[tabatkins]

...which use case? Scroll markers in general, or something more specific?

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-5] Giving ::scroll-marker-group a name (and optionally text).

The full IRC log of that discussion

<JoshT> flackr: when using CSS scroll markers, we implicitly create a ::scroll-marker-group
<JoshT> ... for presentation and a11y tree, the element doesn't have a name to say what type of thing it's containing. maybe slides or pages or items
<JoshT> ... it's good practice and visually desirable to have a label
<JoshT> ... I wanted to get some consensus on what path we should follow here
<JoshT> ... i listed possible options.
<JoshT> ... without major syntactic changes, we could add the content before the pseudo on the scroll-marker-group
<JoshT> ... but wanted to get group's thoughts
<astearns> ack fantasai
<TabAtkins> q+
<JoshT> fantasai: when you're at the point where you need labels, you should probably use HTML
<astearns> +1 fantasai
<JoshT> ... when this was just a decorative thing, that seemed like it could be in css.
<JoshT> ... once it has content, it seems like it needs to be in the content
<astearns> ack TabAtkins
<JoshT> TabAtkins: I disagree with fantasai
<astearns> q+
<JoshT> ... we already have the alt property to add alt text before and after
<JoshT> ... we encourage adding content in the dom
<JoshT> ... but this labelling serves the same purpose
<JoshT> ... this might only apply in certain media queries and therefore be stylistic
<JoshT> q+
<PaulG> q+
<JoshT> ... I think simply labelling things is appropriate
<florian> q+
<TabAtkins> s/before and after/to ::before and ::after/
<JoshT> astearns: while I agree with the alt text comparison, I wonder if it's just that sort of thing. is there anywhere else in CSS where we apply an aria-label
<JoshT> flackr: this is wherever the content property applies
<JoshT> astearns: is it a label or more like a role?
<JoshT> ... do we need ways of setting roles for a11y affordances?
<astearns> ack astearns
<astearns> ack PaulG
<JoshT> PaulG: the examples of tabs would be a tab list and not just a group
<JoshT> ... so there are different roles for different collections of items
<JoshT> ... content is also problematic for accessibility, like with translations
<JoshT> ... so we tell people to avoid it
<JoshT> ... there are multiple issues. could we see examples with the role?
<JoshT> ... I suspect it will get complicated without a lot more hinting
<JoshT> flackr: this is not about setting the role. aria has examples of using a tablist role with a label
<JoshT> ... this is just a label that is a friendly name for the user to explain it. we are exploring changing tablist roles with a different property in a different issue
<JoshT> ... this would be similar to the aria-label property
<astearns> ack JoshT
<TabAtkins> JoshT: haven't read the issue yet, but TAG recently got back to you about this
<TabAtkins> JoshT: anything they mentioned that is relevant to this?
<TabAtkins> flackr: this specifically, not sure. tabs-or-links resolution from the other issue (about changing the role and interaction behavior) was directly in relation to some of the TAG feedback
<TabAtkins> flackr: I think this might have come up a bit as well. i'm trying to align the things that you should do to make your site a11y aligned, as easy as possible
<TabAtkins> flackr: so being able to give a more contextually meaningful label seemed like a nice thing for devs to be easy to do
<astearns> ack florian
<JoshT> florian: This is a passing thought. whether this should be done in CSS or HTML...
<JoshT> ... this seems like another case for cascading attributes
<keithamus> q+
<JoshT> TabAtkins: I don't think that's the case here. these are CSS generated and that would only work if you have the markup
<fantasai> +1 to cascading attribute sheets being useful for many of these kinds of cases, and also probably not relevant to this case
<JoshT> florian: so it's adjacent but not quite right
<astearns> ack keithamus
<JoshT> keithamus: Concerned about the recurring theme with scroll markers. The question of why it isn't in HTML.
<JoshT> ... this is the case again. If you supply a label with CSS for scroll makers, why not every element?
<JoshT> ... does the aria spec need to be updated to mention stuff about CSS?
<JoshT> ... does the a11y tree get more complex as a result?
<JoshT> flackr: you can already set a content value
<JoshT> keithamus: that's limited in scope
<JoshT> ... one property on pseudo-elements. this isn't a suggestion to allow content in a pseudo-element
<JoshT> flackr: this is
<JoshT> astearns: well in three of your four options
<PaulG> CSS pseudo element content, either :before or :after, must only be used for decorative purposes. If you insert meaningful content using a :before or :after pseudo element, it is in violation of success criteria 1.3.1.
<JoshT> flackr: yes. we have a pseudo-element and we want to give it pseudo-content
<PaulG> arguing that this is the same thing, is going to cause issues
<JoshT> astearns: as PaulG mentioned, the a11y folks don't like us doing that
<ntim> q+
<JoshT> ... I wonder, should we take the issue back to consider whether the use case should be addressed in HTML?
<JoshT> TabAtkins: I think your question is, 'should we be doing scroll markers in css at all?'
<JoshT> ... I don't know what is the more specific use case you might be targeting?
<JoshT> ... how could we do that in markup without the whole thing being in markup
<JoshT> PaulG: you could point to an element with content in it
<kizu> q+
<florian> q+
<JoshT> ntim: Keith's question is legit
<JoshT> ... we had discussions about adding event listeners onto the elements, and now labels
<JoshT> ... will we end up needing slotting inside pseudo-elements?
<JoshT> ... I think a boundary makes sense. we need to find a boundary
<fantasai> +1 to figuring out where the boundary is
<JoshT> kizu: someone mentioned on one of the threads about whether we can connect a HTML template to a pseudo-element
<JoshT> ... let's say we have a pseudo-element that provides something as content
<JoshT> ... then define the template in HTML which can be translated
<JoshT> ... one common case is adding icons. or adding more complex content
<keithamus> q+
<JoshT> ... something we never did before but could be explored
<JoshT> ... and could be dynamic
<JoshT> florian: on the HTML vs CSS discussion, it feels CSSy still. this is the presentation, not the content of the document
<JoshT> ... so having the whole thing or a chunk in CSS does make sense
<JoshT> ... if we have building blocks on both sides, that may work too. this is not pure content
<JoshT> ... I'm kind of sorry I pushed the discussion in that direction
<JoshT> ... are we going into abstract theoretical purity things
<TabAtkins> +1
<JoshT> ... but if this helps us find a better path, maybe that's right
<JoshT> keithamus: I don't think it's too abstract. I would have also raised it
<JoshT> ... there are common problems here with solutions today in HTML
<JoshT> ... the scroll-marker-group, is there more than one?
<JoshT> flackr: no
<JoshT> keithamus: so this could be a slotted element
<JoshT> ... it could be supplied to you if you want it fully decorated. but if you want to change the role or whatever, you could add a new HTML element into your container and that acts as the element that is slotted in
<florian> q+
<JoshT> ... it would be just like ::detail-summary. that would point to the detailed content of the summary
<ntim> (::details-summary does not exist anymore, ::details-content does though)
<JoshT> ... I think scroll markers could also fit that pattern
<JoshT> ... I think it solves the general problems that this design is pointing towards
<JoshT> florian: I am unsure. yes somewhat, but it bakes into the markup assumptions about how we will generate the whole thing which is a smell as well
<JoshT> keithamus: I guess I'm curious what presentation assumptions having an element in the dom makes
<JoshT> florian: maybe I misunderstood what you meant, but depending on when you use scroll-marker or -group at all, you might not need that element
<JoshT> ... you may have completely different presentation of the content that doesn't need these things at all
<JoshT> ... but if you do need them and they're not baked into the markup, you can't
<JoshT> ... or otherwise you have it and you need to adjust your markup
<florian> s/will generate/will present/
<JoshT> TabAtkins: this is related to how most UI frameworks have a container type.
<JoshT> ... in CSS, it is purely presentational and you can turn it off
<JoshT> ... that's the idea here too, where a styling choice can affect whether you have scroll markers
<JoshT> ... it is theoretically possible to have a pattern in HTML that has scroll markers
<JoshT> ... if it is something that can optionally generate scroll makers, then the presence/absence of it is CSS dependent
<JoshT> ... most of the questions like architectural decisions are the same
<JoshT> ... we're trying to avoid the situation where if we were to add markup for scroll markers, that would automatically do scroll makery stuff and you can't meaningfully turn it off
<JoshT> keithamus: we can have different semantics here. we could make it conditional even based on UA styling
<florian> q+
<JoshT> ... and that will make it affect the a11y tree
<JoshT> ... I'm concerned that we're extending this concept in ways that will create more burdens when we could just have an element on the page and influence the a11y tree normally
<JoshT> ... if someone wants to change any property for it, the solution already exists
<JoshT> fantasai: there are a number of scroll markery things we don't expect to generate in CSS. like a ToC where the content of the heading is the link. that would need to be done in the HTML
<JoshT> ... there is a set of use cases for scroll markers that we've already decided belong in HTML
<JoshT> ... I think going back to ntim's question, where do we draw the line for what use cases are in HTML?
<JoshT> florian: there is a tension here about what is a natural fit for the capabilities of the language
<JoshT> ... what is an appropriate decoupling of content and CSS?
<JoshT> ... they are overlapping
<JoshT> ... I maybe lean towards decoupling with presentational things being in CSS more often than not
<JoshT> ... it's presentationy and you may want to turn them off or on
<JoshT> fantasai: to the extent that the more something is coupled with the content, the more it belongs in HTML
<JoshT> ... also, would be useful if this issue had more concrete examples of what we mean by a tablist. they're normally labelled with something
<JoshT> ... that would be useful.
<JoshT> ... and we don't seem to have a consensus here. we should probably move on
<JoshT> flackr: I think that's fine to wrap up.
<flackr> https://github.com//issues/8892
<JoshT> ... I want to point out there's a similar issue for selecting content from pseudo-elements
<JoshT> ... I think part of this is dev ergonomics
<JoshT> ... I can try to distill this down. I don't know if we're getting anywhere but can bring back to issue
<JoshT> ... it's basically just a label for your scroll markers. I can put examples in the issue
<JoshT> florian: it may help focus

[jasonwilliams]

I lean towards fantasai and keithamus that this belongs in HTML. In the long run developers may need richer semantics, other roles, labels, translatable text etc. We don’t really have a precedent for setting ARIA attributes via CSS, and as Josh noted, the content property is already discouraged for meaningful text. Other pseudo-elements like ::before/::after are decorative only, so they don’t carry this precedent either.

I also like Keith’s suggestion of a slotted element, since that offers more flexibility and keeps the semantics in the DOM. To my knowledge, slots are currently only used within shadow DOM, so extending that model to UA pseudo-elements like ::scroll-marker-group would be new? but it seems worth exploring.
I assume you would need 2 slots, one for the marker group and another for the markers themselves (so only one marker can be defined whilst the UA repeats it as necessary).

[keithamus]

To my knowledge, slots are currently only used within shadow DOM, so extending that model to UA pseudo-elements like ::scroll-marker-group would be new?

This is how the <details> element works under the hood. It is effectively:

<details>
  <template shadowrootmode="secret-browser-mode">
    <slot secret-browser-part="summary"><div>Details</div></slot>
    <slot secret-browser-pseudo="::details-content"></slot>
  </template>
</details>

(The secret-browser-* bits are made up for demonstration).

This means if you make a <details> element with no summary, you get a summary with contents of the default slot (<div>Details</div>). We could do the same for scroll-marker-group whereby an element that becomes a scroll container gets an effective shadow dom of:

<template shadowrootmode="secret-browser-mode">
  <slot secret-browser-part="scroll-marker-group" secret-browser-pseudo="::scroll-marker-group"><!-- some default html here --></slot>
</template>

[flackr]

@keithamus for clarity, would it look something like this?

<style>
.carousel { scroll-marker-group: after; }
.carousel::column::scroll-marker { content: ""; }
</style>
<div class=carousel>
  <div class=item></div>
  <div class=item></div>
  <div class=item></div>
  <div class=item></div>
  <scroll-marker-group>
    Scroll marker group label:
  </scroll-marker-group>
</div>

Presumably the <scroll-marker-group> element should wrap the generated markers, but are the markers added after the user provided content or does the user provide something that contains them? E.g.

  <scroll-marker-group>
    Scroll marker group label:
    ::column(1)::scroll-marker
    ::column(2)::scroll-marker
  </scroll-marker-group>

Or is the idea that the author wouldn't be allowed to provide any contents for the <scroll-marker-group> element but could include it in an element that provides those details, e.g.

<style>
.carousel { scroll-marker-group: after; }
.carousel::column::scroll-marker { content: ""; }
</style>
<div class=carousel>
  <div class=item></div>
  <div class=item></div>
  <div class=item></div>
  <div class=item></div>
  <div class=marker-group>
    Scroll marker group label:
    <scroll-marker-group><!-- Contents are replaced by the markers --></scroll-marker-group>
  </div>
</div>

[keithamus]

I think all of those are viable options, depending on if the use cases justify requiring content inside the element. I'm unsure if we would want another self closing element (not that you provided one in your examples), but there is precident for elements (e.g. <select>) to not render any of their children or be more selective about the rendered children.