LGTM2 On Monday, August 24, 2026 at 11:46:46 AM UTC-7 [email protected] wrote:
> 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/0b50c3cc-a19a-4e40-81ab-e477d1841b4en%40chromium.org.
