CSS scroll-marker-group modes

at a glance

syntax

The value-definition grammar, quoted verbatim from the scroll-marker-group propdef in CSS Overflow 5 (fetched 2026-10-04):

scroll-marker-group: none | [ [ before | after ] || [ links | tabs ] ]

The || combinator means a position keyword (before | after) and a mode keyword (links | tabs) may each appear at most once, in either order — scroll-marker-group: after tabs and scroll-marker-group: tabs after are both valid. If the mode keyword is omitted, links is the default mode (spec: “This is the default mode if omitted”). Note the grammar also permits a bare mode keyword with no position keyword; the spec prose read on 2026-10-04 defines ::scroll-marker-group box placement only for before and after, so the placement for a bare-mode value is not explicitly stated — specify a position keyword in practice. There is no error surface beyond parsing: a declaration that does not match this grammar is simply invalid and ignored, per CSS Syntax 3 error handling (see each mode’s Errors section for the fallback consequences).

the two modes

Per CSS Overflow 5 §3.1.6 Scroll Marker Modes, a ::scroll-marker-group operates in either links or tabs mode based on the scroll-marker-group value of its originating element. Each mode has its own reference page covering syntax, roles, focus behavior, activation, examples, and compatibility:

what changes for existing content

scroll-marker-group itself shipped in Chrome 135; before Chrome 154 the property accepted only none | before | after (the value set recorded in BCD). From Chrome 154, any existing scroll-marker-group: before or after declaration operates in links mode, since the spec makes links the default when the mode keyword is omitted. The Intent to Ship discussion flagged exactly this as the feature’s main compatibility risk: fixing a default mode alters focus order and accessibility roles for pages already using scroll markers (usage was reported at roughly 0.09% of page loads in the thread). How pre-154 Chrome ordered focus and assigned roles for markers is not stated in the sources read here; if your carousel relied on the earlier implicit behavior, re-test focus order in 154 and declare tabs explicitly where you want tablist semantics.

activation behavior

When a scroll marker with a non-null scroll target is activated (by explicit invocation or arrow-key focus), CSS Overflow 5 §3.1.9 scrolls the target element into view (block and inline alignment “start”, within the nearest common ancestor scroll container). If the activation was an invocation, the browser follows the hyperlink, updating the URL. The modes then diverge:

• tabs mode — “Retain focus on the scroll marker element.” (how real tabs behave)
• links mode — “Set the sequential focus navigation starting point to the originating element, losing focus from the scroll marker.” (how clicking an internal <a href="#target"> link behaves)

examples

A tabbed carousel using tabs mode — adapted from the explainer’s tabs-mode example:

.slides {
  /* Core tabs mode declaration: position keyword + mode keyword */
  scroll-marker-group: after tabs;

  display: flex;
  overflow-x: auto;
  scroll-snap-type: x mandatory;

  & > div {
    min-width: 100%;
    scroll-snap-align: center;

    /* Each slide gets a marker, collected into the group */
    &::scroll-marker {
      content: "";
      display: inline-block;
      width: 1rem; height: 1rem;
      border-radius: 50%;
      border: 1px solid #444;
    }

    /* The active tab marker */
    &::scroll-marker:target-current {
      background: SelectedItem;
    }
  }
}

Switching the declaration to scroll-marker-group: before links; turns the same markup into a table-of-contents-style navigation list (see the links mode reference for a full example).

Upstream live demos by the feature author: tabs mode CodePen and links mode CodePen (from the ChromeStatus sample links).

browser compatibility

BCD css/properties/scroll-marker-group.json (fetched 2026-10-04) records the base property and its none/before/after values, but has no entry yet for the links and tabs values. The mode rows below are therefore interim data from the ChromeStatus API record, labelled as such:

Baseline: limited availability for the parent scroll-markers web-feature (webstatus.dev, queried 2026-10-04); ChromeStatus records “Missing feature” for a modes-specific web-feature id. Feature-detect with CSS.supports("scroll-marker-group", "after tabs") and treat the modes as a Chromium-only progressive enhancement.

security and privacy

CSS Overflow 5’s Appendix C and Appendix D state that the specification “introduces no new privacy considerations” and “no new security considerations”. The accessibility-relevant caveat is a direct consequence of the documented tabs behavior: content of inactive tab panels is hidden from the accessibility tree (the spec’s substitute for hand-written interactivity: inert management), so content that assistive-technology users must always be able to reach should not live only inside an inactive panel of a tabs-mode scroll container. This caveat is gendn guidance derived from the spec’s tree-pruning behavior, not a normative warning.

specifications

see also

• gendn: links mode reference · gendn: tabs mode reference
• MDN: scroll-marker-group (base property; its formal-syntax block already shows links | tabs but the modes are otherwise undocumented there as of 2026-10-04)
• MDN: ::scroll-marker-group · MDN: ::scroll-marker
• Explainer: scroll-marker-group modes vs. WAI-ARIA patterns
• CSSWG issue #12122 · CSSWG PR #13627 (merged 2026-03-17)
• chrome-platform-showcase: scroll-marker-group modes demos (five concepts, route 200)
• ChromeStatus — CSS scroll-marker-group modes (5109685301673984)
• blink-dev Intent to Ship — CSS scroll-marker-group modes