LGTM3 On Mon, Aug 24, 2026 at 11:47 AM Alex Russell <[email protected]> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0b50c3cc-a19a-4e40-81ab-e477d1841b4en%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/CAOMQ%2Bw-LvtuWrZD9mjAG%3D0%3D8QYj3zFWGdA9ed261TN65C6kC9Q%40mail.gmail.com.
