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/CAJh39TNZGvFoE5pkRTv3AmEw5Yf%3DZ__zr%3DntC98_gw8jT8Kz9Q%40mail.gmail.com.
