Thanks Rob for contextualizing the compat risk and the reason for the new default. Please do keep an eye out for issues as this goes out, but seems like a reasonable change to me. LGTM1 contingent on ensuring that the WPTs are updated to expect the new behavior.
On Wednesday, August 19, 2026 at 4:39:48 PM UTC-7 [email protected] wrote: > On Wed, Jul 29, 2026 at 8:04 PM 'Dan Clark' via blink-dev < > [email protected]> wrote: > >> I want to dig into the compat question a bit more too. The 0.09% usage >> from https://chromestatus.com/metrics/css/timeline/popularity/793 is >> above the threshold we'd typically accept for outright breakage. To what >> degree do you expect sites assuming the old default to be impacted by this >> change? It seems like the scroll markers will become tab stops, and will >> have a different accessibility role. In your experience with sites using >> the feature, would this tend to be a breaking change or more of a small >> tweak to how users will interact with the component? > > > Users are primarily interacting with the component using touch or a mouse > where they wouldn't notice anything different. However, even keyboard users > can still fully use link style markers. > > >> Does that same answer apply to users of assistive tech who could be >> impacted by the default role change? > > > Accessibility users will previously have seen tab roles on the markers > themselves, but often not with the associated tabpanel and often not having > the expected activation or exclusive access semantics. > > With this change, these markers will become links to the content they > point to, matching how they behaved before by default (except for focus > group-like tabbing). The tabs mode imposes additional constraints necessary > to implement the tabs model—namely, changing the implied role of the > referenced content and removing the inactive content from the focus > order/a11y tree. > > *> 3) These mods are direct response to CSS Carousels criticism from both >> devs and different WGs.* >> >> Are there links to any of these conversations you could reference? >> > > https://github.com/w3c/csswg-drafts/issues/12122 is the main issue where > this proposal was discussed. It addresses the main concerns that the > current implementation did not provide the expected semantics by default. > Some of these concerns are linked from the original I2S: > https://groups.google.com/a/chromium.org/g/blink-dev/c/7EQ8-VzPZh0/m/NMyrGCjuAAAJ > . > > >> The compat risk goes away if we were to instead make tabs mode the >> default. I'd like to better understand the motivation for going with >> "links" as the default given the risk it entails. >> > > The tabs mode may be a riskier default to switch existing usage to, given > that it removes inactive content from the tab order/a11y tree to match the > expected tab/tabpanel model by default. Links behave similar to how scroll > markers previously worked where they scroll to the target but any > additional implications are up to the developer to apply, other than the > different keyboard focus/interaction you noted. > > Links is also consistent with the behavior you get by default with the > related scroll-target-group property. > > Thanks, >> Dan >> On Monday, July 27, 2026 at 11:39:29 AM UTC-7 Dan Clark wrote: >> >>> It'd be good to get WPT coverage at least for the focus order changes. >>> Several such tests already exist (for example >>> scroll-marker-next-focus.html >>> <https://github.com/web-platform-tests/wpt/blob/1985b47aa8/css/css-overflow/scroll-markers/scroll-marker-next-focus.html>), >>> >>> but they still expect the default behavior to be "tabs". This might explain >>> why several of the WPTs are failing in Chrome Experimental but passing in >>> Stable: >>> https://wpt.fyi/results/css/css-overflow/scroll-markers?label=master&product=chrome%5Bexperimental%… >>> >>> <https://wpt.fyi/results/css/css-overflow/scroll-markers?label=master&product=chrome%5Bexperimental%5D&product=chrome%5Bstable%5D&aligned.> >>> >>> Seems to me like the existing set of tests should be updated to handle the >>> new default, and there should be tests that validate focus order for both >>> "links" and "tabs" mode. >>> >>> The Carousels TAG review >>> <https://github.com/w3c/csswg-drafts/issues/12122> is still in >>> progress, and the latest response from the TAG actually has some comments >>> relevant to this change: >>> https://github.com/w3ctag/design-reviews/issues/1037#issuecomment-3189080896, >>> >>> particularly the note on developers choosing between "tabs" and "links" >>> semantics. Will there be documentation that helps developers understand >>> that choice? >>> >>> On Friday, July 24, 2026 at 3:48:40 AM UTC-7 [email protected] wrote: >>> >>>> 1) Current usage is extermly low/close to 0 ( >>>> https://chromestatus.com/metrics/css/timeline/popularity/793), so this >>>> improvement is just on time. >>>> 2) WPT tests can only cover some basics unfortunetly, as these mods are >>>> more about AX and focus order on pseudo-elements, we mostly have our own >>>> unit tests for now. But soon WPT driver will support new AX features so >>>> we'll hopefully be able to test more things. >>>> But notice that current scroll-marker-group WPTs do test some simple >>>> focus order cases. >>>> 3) These mods are direct response to CSS Carousels criticism from both >>>> devs and different WGs. >>>> 4) I though that since we've had general TAG review for CSS Carousel I >>>> don't need a separate one? >>>> 5) I'll update the other necessary things. >>>> >>>> понедельник, 20 июля 2026 г. в 18:50:00 UTC+2, [email protected]: >>>> >>>>> It’s stated here that “links” mode will be the default, but when I >>>>> experiment with the example at >>>>> https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/scroll-marker-group >>>>> >>>>> it looks like “tab” mode is the scroll-marker-group behavior that’s >>>>> shipped >>>>> in Chromium today. Changing this will cause a difference in behavior for >>>>> sites that already use scroll-marker-group without specifying the mode, >>>>> e.g. sites will see the single tab stop on a scroll-marker-group become >>>>> multiple tab stops. Is this compatibility risk something you’ve >>>>> considered? >>>>> >>>>> >>>>> >>>>> *> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>> >>>>> >>>>> *> Yes > https://wpt.fyi/css/css-overflow/scroll-markers >>>>> <https://wpt.fyi/css/css-overflow/scroll-markers>* >>>>> >>>>> This looks like test coverage for the broader scroll-marker-group >>>>> feature, but is there coverage for the new functionality being proposed >>>>> here? The only of these tests with “mode”, “link”, or “tab” in the name >>>>> are >>>>> already passing in Chrome Stable. >>>>> >>>>> >>>>> >>>>> *> Web developers: No signals* >>>>> >>>>> >>>>> >>>>> It would be better if we could point to some evidence of developer >>>>> interest. Who is asking for this feature? >>>>> >>>>> >>>>> >>>>> *> TAG review status* >>>>> >>>>> *Not applicable* >>>>> >>>>> Can you say why TAG review isn’t applicable? >>>>> >>>>> >>>>> >>>>> >>>>> *> Gecko: No >>>>> signal (https://github.com/mozilla/standards-positions/issues/1161 >>>>> <https://github.com/mozilla/standards-positions/issues/1161>) > WebKit: >>>>> No >>>>> signal (https://github.com/WebKit/standards-positions/issues/447 >>>>> <https://github.com/WebKit/standards-positions/issues/447>)* >>>>> >>>>> >>>>> >>>>> I think it’s reasonable to reuse the Gecko and WebKit signals for >>>>> carousel, but it’d be nice to post an update to those threads mentioning >>>>> that you intend to ship this additional behavior. >>>>> >>>>> >>>>> >>>>> Lastly, please request the other reviews in Chromestatus (Privacy, WP >>>>> security, etc). >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> *From:* [email protected] <[email protected]> *On Behalf Of * >>>>> Chromestatus >>>>> *Sent:* Wednesday, July 15, 2026 12:40 PM >>>>> *To:* [email protected] >>>>> *Cc:* [email protected] >>>>> *Subject:* [blink-dev] Intent to Ship: CSS scroll-marker-group modes >>>>> >>>>> >>>>> >>>>> *Contact emails* >>>>> >>>>> [email protected] >>>>> >>>>> *Explainer* >>>>> >>>>> https://gist.github.com/danielsakhapov/aa8e744701224994609aebb3e9e316e3 >>>>> >>>>> *Specification* >>>>> >>>>> https://drafts.csswg.org/css-overflow-5/#scroll-marker-modes >>>>> >>>>> *Summary* >>>>> >>>>> The scroll-marker-group property is enhaced to support modes: 1) >>>>> 'links' - The generated ::scroll-marker-group operates in "links" mode, >>>>> functioning like a navigation list. This is the default mode if omitted. >>>>> 2) >>>>> 'tabs' - The generated ::scroll-marker-group operates in "tabs" mode, >>>>> functioning like a tablist. Each mode changes focus order and >>>>> accessibility >>>>> behavior of ::scroll-marker-group and ::scroll-markers, following >>>>> WAI-ARIA >>>>> patterns. More details: # The links mode (default) This mode is designed >>>>> to >>>>> mimic standard Navigation Landmarks combined with fragment anchors. ## >>>>> Semantic roles The ::scroll-marker-group takes on the navigation role, >>>>> and >>>>> the ::scroll-marker elements take on the link role. This perfectly maps >>>>> to >>>>> the <nav> + <a> structural pattern. ## Keyboard navigation All >>>>> ::scroll-marker elements are sequential tab stops, natively acting like a >>>>> list of standard anchor links. ## Unaffected targets The originating >>>>> elements do not get forced into any role, leaving the document's natural >>>>> semantic structure intact. ## Activation focus management When a link >>>>> marker is activated, it sets the sequential focus navigation starting >>>>> point >>>>> to the target element (the originating element), and focus is lost from >>>>> the >>>>> marker. This mimics the native behavior of clicking a standard internal >>>>> <a >>>>> href="#target"> link. # The tabs mode This mode is designed to natively >>>>> replicate the Tabs Pattern and serves as the interactive foundation for >>>>> the >>>>> Tabbed Carousel Pattern. ## Semantic roles The ::scroll-marker-group is >>>>> implicitly assigned the tablist role, ::scroll-marker elements act as tab >>>>> roles, and their originating elements get the tabpanel role. This mirrors >>>>> the required WAI-ARIA Tabs structure. ## Keyboard navigation (roving >>>>> tabindex) It follows the complex keyboard interactions outlined in >>>>> standard >>>>> practices. Only the active ::scroll-marker acts as a tab stop. Users use >>>>> arrow keys to navigate the focusgroup (switching between markers), >>>>> preventing the "tab trap" of having to tab through 20 carousel dots. ## >>>>> Focus scope management The marker acts as a focus navigation scope owner. >>>>> Pressing Tab from the active marker moves focus directly into the active >>>>> tabpanel content, matching the specification for tabbed interfaces. ## >>>>> Tree >>>>> pruning Content from inactive tabs is explicitly hidden from the >>>>> accessibility tree. This mimics the expected behavior of >>>>> aria-hidden="true" >>>>> or inert on inactive tab panels, saving developers from manually >>>>> scripting >>>>> state changes. ## Activation focus When a marker is activated, focus is >>>>> retained on the marker, which is exactly how standard tabs operate. >>>>> >>>>> *Blink component* >>>>> >>>>> Blink>CSS >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> >>>>> >>>>> *Web Feature ID* >>>>> >>>>> Missing feature >>>>> >>>>> *Motivation* >>>>> >>>>> *No information provided* >>>>> >>>>> *Initial public proposal* >>>>> >>>>> *No information provided* >>>>> >>>>> *TAG review* >>>>> >>>>> *No information provided* >>>>> >>>>> *TAG review status* >>>>> >>>>> Not applicable >>>>> >>>>> *Goals for experimentation* >>>>> >>>>> None >>>>> >>>>> *Risks* >>>>> >>>>> >>>>> >>>>> *Interoperability and Compatibility* >>>>> >>>>> *No information provided* >>>>> >>>>> *Gecko*: No signal ( >>>>> https://github.com/mozilla/standards-positions/issues/1161) >>>>> >>>>> *WebKit*: No signal ( >>>>> https://github.com/WebKit/standards-positions/issues/447) >>>>> >>>>> *Web developers*: No signals >>>>> >>>>> *Other signals*: https://github.com/w3c/css-aam/issues/18 >>>>> >>>>> *WebView application risks* >>>>> >>>>> *Does this intent deprecate or change behavior of existing APIs, such >>>>> that it has potentially high risk for Android WebView-based applications? >>>>> * >>>>> >>>>> *No information provided* >>>>> >>>>> >>>>> >>>>> *Debuggability* >>>>> >>>>> *No information provided* >>>>> >>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>> >>>>> Yes >>>>> >>>>> *Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>> >>>>> Yes >>>>> https://wpt.fyi/css/css-overflow/scroll-markers >>>>> >>>>> *Flag name on about://flags* >>>>> >>>>> *No information provided* >>>>> >>>>> *Finch feature name* >>>>> >>>>> *No information provided* >>>>> >>>>> *Non-finch justification* >>>>> >>>>> *No information provided* >>>>> >>>>> *Rollout plan* >>>>> >>>>> Will ship enabled for all users >>>>> >>>>> *Requires code in //chrome?* >>>>> >>>>> False >>>>> >>>>> *Estimated milestones* >>>>> >>>>> No milestones specified >>>>> >>>>> >>>>> >>>>> *Anticipated spec changes* >>>>> >>>>> *Open questions about a feature may be a source of future web compat >>>>> or interop issues. Please list open issues (e.g. links to known github >>>>> issues in the project for the feature specification) whose resolution may >>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>> of >>>>> the API in a non-backward-compatible way). * >>>>> >>>>> *No information provided* >>>>> >>>>> *Link to entry on the Chrome Platform Status* >>>>> >>>>> https://chromestatus.com/feature/5109685301673984?gate=6191471012216832 >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com/>. >>>>> >>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> >>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> >>>> >>>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a57e20c.854c7482.198413.02a4.GAE%40google.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a57e20c.854c7482.198413.02a4.GAE%40google.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/26f0c678-14d6-438e-9068-2fa148940188n%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/26f0c678-14d6-438e-9068-2fa148940188n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3e92470d-a9f1-4980-bfbf-2a7e55842d19n%40chromium.org.
