CSS display contents: Browser Support, Use Cases, Issues

What is CSS display: contents?

CSS display: contents is a value of the display property defined in the W3C CSS Display Module Level 3 specification. The element itself produces no box, so its border, background, padding, width, and height are ignored, while its children and pseudo-elements still render and join the parent's flex or grid container.

Which browsers does CSS display: contents support?

CSS display: contents works in every major modern browser, with global support around 95%. The version where it first shipped, and any accessibility caveats, vary by engine.

What are the use cases of CSS display: contents?

display: contents shines whenever a wrapper element exists for HTML or component reasons but should not break a flex or grid layout. The property lets the wrapper stay in the markup while its children act as direct grid or flex items.

• Promote nested children to grid items: Wrap a group of cards inside a section or article tag for semantics, then set the wrapper to display: contents so the cards line up on the parent grid's tracks instead of getting trapped in a separate sub-container.
• Style components from a third-party framework: When a UI library outputs an extra wrapping div around its slot, display: contents hides the wrapper from layout so your CSS Grid or Flexbox parent can address the inner content directly without a fork or override.
• Subgrid alternative for flex layouts: Subgrid solves the alignment problem for grid containers, but flex containers cannot use it. display: contents on intermediate wrappers is the closest substitute when you want grandchildren to align with the flex parent's items.
• Conditional layout collapse: Toggling a wrapper between display: block and display: contents lets the same markup render as a grouped card on small screens and as a flat row of children on large screens, with no DOM swap and no JavaScript reflow cost.
• Server-rendered list normalization: Server frameworks often emit a ul wrapper around a single li even when the surrounding grid expects flat rows. display: contents on the ul keeps the list semantics for assistive tech on modern browsers and lets the li participate in the grid.
• Tailwind CSS contents utility: Tailwind ships a contents class that compiles to display: contents, so designers can apply the behavior straight from a class attribute without writing custom CSS.

What are the known issues with CSS display: contents?

CSS display: contents has a thin set of known issues that all trace back to one root: browsers historically tied semantics to the box, not to the element. Modern engines have fixed most of the bugs, but legacy versions still surface them, so the gotchas matter for any team that supports older OS releases.

• Accessibility roles dropped in older browsers: Chrome below 89, Firefox below 62, and Safari below 16 strip the role from any element with display: contents, so screen readers no longer announce list, button, or heading semantics. The CSSWG draft says this is incorrect, and modern browsers keep the role.
• Replaced elements collapse to display: none: img, input, video, canvas, iframe, embed, and object treat display: contents as display: none per the CSS Display Module Level 3 spec, so the element vanishes entirely. Use a non-replaced wrapper instead when you need this behavior.
• Tables lose their table role: Setting display: contents on table, thead, tbody, or tr breaks the table accessibility role on every browser before the engine fixes landed. Screen readers stop announcing the rows and columns, even when sighted users still see them. Avoid the property on table elements.
• Buttons lose click-target semantics: Older WebKit and Chromium versions remove the button role from a button styled with display: contents, so keyboard navigation skips it. Pair the property with role="button" and tabindex="0" as a defensive fallback when you must support legacy iOS Safari.
• fieldset and legend layout quirks: Several browsers ignore display: contents on fieldset entirely and continue to render the box, because the form rendering pipeline is hard-coded around it. Wrap the fieldset content in a different element if you need the children to participate in a grid.
• No effect on the box-generation cascade: The element with display: contents leaves no box, so margin, padding, border, background, transform, opacity, and outline are all ignored. Move those declarations to either the parent or to the children.

In my experience, the loudest production bug from display: contents shows up on iOS Safari 16 builds where a navigation list rendered fine visually but VoiceOver announced "blank" instead of the list, because the older WebKit accessibility tree had not yet caught up. The cheapest fix is a feature query that disables display: contents on browsers that fail an in-page accessibility-role probe.

How do you check if a browser supports CSS display: contents?

Detect display: contents by reflecting it through the CSSOM and the CSS.supports() API. Both checks should agree before you apply the property to a semantic wrapper.

• Open the DevTools console: Press F12 or right-click the page and choose Inspect, then switch to the Console tab.
• Reflect the value through the CSSOM: Create a div in JavaScript, set element.style.display = 'contents', and read the value back. If the browser supports the value, the read-back is the literal string "contents"; otherwise it is empty.
• Confirm with CSS.supports(): Call CSS.supports('display', 'contents'). The method returns true on Chrome 65+, Edge 79+, Firefox 37+, Safari 11.1+, Opera 52+, and Samsung Internet 9.2+, and false on Internet Explorer and unsupported builds.
• Gate the rule with @supports: Wrap any display: contents declaration in @supports (display: contents) so older browsers fall back to the wrapper's default block or inline box without breaking the layout.
• Add an accessibility probe for older engines: The CSSOM check returns true on Chrome 65 and Safari 11.1, but the role-stripping bug existed on those versions. Combine the support check with a User-Agent or version sniff if you must keep semantics safe on older builds.

Paste this snippet into the DevTools console of any browser to confirm display: contents support and verify both the CSSOM and CSS.supports() agree.

// Paste this into the DevTools console to confirm display: contents support.
const probe = document.createElement('div');
probe.style.display = 'contents';
const reflected = probe.style.display === 'contents';
console.log('reflected style:', reflected ? 'supported' : 'not supported');

// Confirm CSS.supports() agrees, since the CSSOM check is the authoritative one.
const cssSupports = CSS.supports('display', 'contents');
console.log('CSS.supports check:', cssSupports ? 'supported' : 'not supported');

// Final verdict combines both checks.
console.log('display: contents available:', reflected && cssSupports);

Citations

All CSS display: contents version numbers, accessibility notes, and platform behavior in this guide come from these primary sources:

• MDN Web Docs - display CSS property: developer.mozilla.org/en-US/docs/Web/CSS/display
• MDN Web Docs - display-box reference: developer.mozilla.org/en-US/docs/Web/CSS/display-box
• W3C CSS Display Module Level 3 (Editor's Draft): drafts.csswg.org/css-display/#valdef-display-contents
• CSSWG Drafts Issue #3040 - display: contents strips semantic role: github.com/w3c/csswg-drafts/issues/3040
• WebKit Bug 185679 - Element not exposed to accessibility tree: bugs.webkit.org/show_bug.cgi?id=185679
• Hidde de Vries - More accessible markup with display: contents: hidde.blog/more-accessible-markup-with-display-contents/
• Adrian Roselli - Display: Contents Is Not a CSS Reset: adrianroselli.com/2018/05/display-contents-is-not-a-css-reset.html
• Eric Bailey - display: contents considered harmful: ericwbailey.design/published/display-contents-considered-harmful/
• web-platform-tests Interop Issue #568 - display: contents accessibility: github.com/web-platform-tests/interop/issues/568
• MDN Web Docs - CSS.supports() API: developer.mozilla.org/en-US/docs/Web/API/CSS/supports_static