- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 03 Sep 2025 16:49:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow-5] Giving ::scroll-marker-group a name (and optionally text)`. <details><summary>The full IRC log of that discussion</summary> <JoshT> flackr: when using CSS scroll markers, we implicitly create a ::scroll-marker-group<br> <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<br> <JoshT> ... it's good practice and visually desirable to have a label<br> <JoshT> ... I wanted to get some consensus on what path we should follow here<br> <JoshT> ... i listed possible options.<br> <JoshT> ... without major syntactic changes, we could add the content before the pseudo on the scroll-marker-group<br> <JoshT> ... but wanted to get group's thoughts<br> <astearns> ack fantasai<br> <TabAtkins> q+<br> <JoshT> fantasai: when you're at the point where you need labels, you should probably use HTML<br> <astearns> +1 fantasai<br> <JoshT> ... when this was just a decorative thing, that seemed like it could be in css.<br> <JoshT> ... once it has content, it seems like it needs to be in the content<br> <astearns> ack TabAtkins<br> <JoshT> TabAtkins: I disagree with fantasai<br> <astearns> q+<br> <JoshT> ... we already have the alt property to add alt text before and after<br> <JoshT> ... we encourage adding content in the dom<br> <JoshT> ... but this labelling serves the same purpose<br> <JoshT> ... this might only apply in certain media queries and therefore be stylistic<br> <JoshT> q+<br> <PaulG> q+<br> <JoshT> ... I think simply labelling things is appropriate<br> <florian> q+<br> <TabAtkins> s/before and after/to ::before and ::after/<br> <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<br> <JoshT> flackr: this is wherever the content property applies<br> <JoshT> astearns: is it a label or more like a role?<br> <JoshT> ... do we need ways of setting roles for a11y affordances?<br> <astearns> ack astearns<br> <astearns> ack PaulG<br> <JoshT> PaulG: the examples of tabs would be a tab list and not just a group<br> <JoshT> ... so there are different roles for different collections of items<br> <JoshT> ... content is also problematic for accessibility, like with translations<br> <JoshT> ... so we tell people to avoid it<br> <JoshT> ... there are multiple issues. could we see examples with the role?<br> <JoshT> ... I suspect it will get complicated without a lot more hinting<br> <JoshT> flackr: this is not about setting the role. aria has examples of using a tablist role with a label<br> <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<br> <JoshT> ... this would be similar to the aria-label property<br> <astearns> ack JoshT<br> <TabAtkins> JoshT: haven't read the issue yet, but TAG recently got back to you about this<br> <TabAtkins> JoshT: anything they mentioned that is relevant to this?<br> <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<br> <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<br> <TabAtkins> flackr: so being able to give a more contextually meaningful label seemed like a nice thing for devs to be easy to do<br> <astearns> ack florian<br> <JoshT> florian: This is a passing thought. whether this should be done in CSS or HTML...<br> <JoshT> ... this seems like another case for cascading attributes<br> <keithamus> q+<br> <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<br> <fantasai> +1 to cascading attribute sheets being useful for many of these kinds of cases, and also probably not relevant to this case<br> <JoshT> florian: so it's adjacent but not quite right<br> <astearns> ack keithamus<br> <JoshT> keithamus: Concerned about the recurring theme with scroll markers. The question of why it isn't in HTML.<br> <JoshT> ... this is the case again. If you supply a label with CSS for scroll makers, why not every element?<br> <JoshT> ... does the aria spec need to be updated to mention stuff about CSS?<br> <JoshT> ... does the a11y tree get more complex as a result?<br> <JoshT> flackr: you can already set a content value<br> <JoshT> keithamus: that's limited in scope<br> <JoshT> ... one property on pseudo-elements. this isn't a suggestion to allow content in a pseudo-element<br> <JoshT> flackr: this is<br> <JoshT> astearns: well in three of your four options<br> <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.<br> <JoshT> flackr: yes. we have a pseudo-element and we want to give it pseudo-content<br> <PaulG> arguing that this is the same thing, is going to cause issues<br> <JoshT> astearns: as PaulG mentioned, the a11y folks don't like us doing that<br> <ntim> q+<br> <JoshT> ... I wonder, should we take the issue back to consider whether the use case should be addressed in HTML?<br> <JoshT> TabAtkins: I think your question is, 'should we be doing scroll markers in css at all?'<br> <JoshT> ... I don't know what is the more specific use case you might be targeting?<br> <JoshT> ... how could we do that in markup without the whole thing being in markup<br> <JoshT> PaulG: you could point to an element with content in it<br> <kizu> q+<br> <florian> q+<br> <JoshT> ntim: Keith's question is legit<br> <JoshT> ... we had discussions about adding event listeners onto the elements, and now labels<br> <JoshT> ... will we end up needing slotting inside pseudo-elements?<br> <JoshT> ... I think a boundary makes sense. we need to find a boundary<br> <fantasai> +1 to figuring out where the boundary is<br> <JoshT> kizu: someone mentioned on one of the threads about whether we can connect a HTML template to a pseudo-element<br> <JoshT> ... let's say we have a pseudo-element that provides something as content<br> <JoshT> ... then define the template in HTML which can be translated<br> <JoshT> ... one common case is adding icons. or adding more complex content<br> <keithamus> q+<br> <JoshT> ... something we never did before but could be explored<br> <JoshT> ... and could be dynamic<br> <JoshT> florian: on the HTML vs CSS discussion, it feels CSSy still. this is the presentation, not the content of the document<br> <JoshT> ... so having the whole thing or a chunk in CSS does make sense<br> <JoshT> ... if we have building blocks on both sides, that may work too. this is not pure content<br> <JoshT> ... I'm kind of sorry I pushed the discussion in that direction<br> <JoshT> ... are we going into abstract theoretical purity things<br> <TabAtkins> +1<br> <JoshT> ... but if this helps us find a better path, maybe that's right<br> <JoshT> keithamus: I don't think it's too abstract. I would have also raised it<br> <JoshT> ... there are common problems here with solutions today in HTML<br> <JoshT> ... the scroll-marker-group, is there more than one?<br> <JoshT> flackr: no<br> <JoshT> keithamus: so this could be a slotted element<br> <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<br> <florian> q+<br> <JoshT> ... it would be just like ::detail-summary. that would point to the detailed content of the summary<br> <ntim> (::details-summary does not exist anymore, ::details-content does though)<br> <JoshT> ... I think scroll markers could also fit that pattern<br> <JoshT> ... I think it solves the general problems that this design is pointing towards<br> <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<br> <JoshT> keithamus: I guess I'm curious what presentation assumptions having an element in the dom makes<br> <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<br> <JoshT> ... you may have completely different presentation of the content that doesn't need these things at all<br> <JoshT> ... but if you do need them and they're not baked into the markup, you can't<br> <JoshT> ... or otherwise you have it and you need to adjust your markup<br> <florian> s/will generate/will present/<br> <JoshT> TabAtkins: this is related to how most UI frameworks have a container type.<br> <JoshT> ... in CSS, it is purely presentational and you can turn it off<br> <JoshT> ... that's the idea here too, where a styling choice can affect whether you have scroll markers<br> <JoshT> ... it is theoretically possible to have a pattern in HTML that has scroll markers<br> <JoshT> ... if it is something that can optionally generate scroll makers, then the presence/absence of it is CSS dependent<br> <JoshT> ... most of the questions like architectural decisions are the same<br> <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<br> <JoshT> keithamus: we can have different semantics here. we could make it conditional even based on UA styling<br> <florian> q+<br> <JoshT> ... and that will make it affect the a11y tree<br> <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<br> <JoshT> ... if someone wants to change any property for it, the solution already exists<br> <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<br> <JoshT> ... there is a set of use cases for scroll markers that we've already decided belong in HTML<br> <JoshT> ... I think going back to ntim's question, where do we draw the line for what use cases are in HTML?<br> <JoshT> florian: there is a tension here about what is a natural fit for the capabilities of the language<br> <JoshT> ... what is an appropriate decoupling of content and CSS?<br> <JoshT> ... they are overlapping<br> <JoshT> ... I maybe lean towards decoupling with presentational things being in CSS more often than not<br> <JoshT> ... it's presentationy and you may want to turn them off or on<br> <JoshT> fantasai: to the extent that the more something is coupled with the content, the more it belongs in HTML<br> <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<br> <JoshT> ... that would be useful.<br> <JoshT> ... and we don't seem to have a consensus here. we should probably move on<br> <JoshT> flackr: I think that's fine to wrap up.<br> <flackr> https://github.com/w3c/csswg-drafts/issues/8892<br> <JoshT> ... I want to point out there's a similar issue for selecting content from pseudo-elements<br> <JoshT> ... I think part of this is dev ergonomics<br> <JoshT> ... I can try to distill this down. I don't know if we're getting anywhere but can bring back to issue<br> <JoshT> ... it's basically just a label for your scroll markers. I can put examples in the issue<br> <JoshT> florian: it may help focus<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12176#issuecomment-3250008793 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 September 2025 16:49:18 UTC