safari flex bug

Philip Walton

Normalizing cross-browser flexbox bugs.

Update: as a follow-up to this article, I’ve created the Github repo Flexbugs : a community curated list of cross-browser flexbox issues and their known workarounds. The goal is if you’re building a website using flexbox, and something isn’t working as you’d expect, you can find the solution there.

Way back in September of 2013, while testing my Solved by Flexbox project, I discovered a bug in Internet Explorer 10 and 11 that was preventing my sticky footer from actually sticking to the bottom of the page. I spent some time trying to work around the issue, but all my attempts failed.

At first I was really annoyed. Before flexbox, it was impossible to build a sticky footer layout with just CSS unless you knew the exact dimensions of both the header and footer. [1] Flexbox changed this—finally we had respectable CSS solutions to today’s modern, responsive layouts.

After my initial disappointment, I eventually concluded that this honestly wasn’t that big of a deal, and I released the project, despite the buggy behavior. I mean, from a progressive enhancement standpoint, my solution was still pretty good. It worked in Chrome, Firefox, Opera, and Safari, and while it wasn’t perfect in Internet Explorer, it wasn’t completely broken either. The content was still accessible, and it would only render incorrectly on pages with minimal content. On longer pages, it looked just like every other browser.

A few weeks ago I received a pull request on Github that fixed the sticky footer issue with an IE-only @media rule. This got me thinking about the problem again, and I was determined to find a solution that didn’t require any browser-specific hacks.

As it turns out, there was a solution, and it was possible all along! I just wasn’t looking hard enough.

In this article, I’ll explain the solution, walk you through how I got there, and talk about the browser bugs I discovered along the way. I’ll also make some recommendations for how to write more cross-browser-compatible flexbox code in the future.

So what are the bugs?

The flexbox specification is not yet finalized, so there’s naturally going to be some lag between the latest drafts and browser implementations. This article is not meant to point fingers at any parties for being behind; instead, it’s meant to help front-end developers do what we do best—manage browser inconsistencies.

The following is a list of bugs I encountered while trying to get my sticky footer demo to work cross-browser:

• In IE 10-11, flex items ignore their parent container’s height if it’s set via the min-height property.
• Chrome, Opera, and Safari fail to honor the default minimum content sizing of flex items.
• IE 10-11 don’t allow unitless flex-basis values in the flex shorthand.

The min-height bug

In Internet Explorer 10 and 11, the min-height property can be used to size a flex container in the column direction, but that container’s flex item children will act as if they don’t know the size of their parent—as if no height has been set at all.

This is a problem for my sticky footer demo since sticky footer layouts traditionally require a min-height declaration of 100% (or 100vh ) to ensure that the content area is at least as tall as the browser window.

Since min-height wasn’t going to work, I needed to find another way.

Minimum content sizing of flex items

When flex items are too big to fit inside their container, those items are instructed (by the flex layout algorithm) to shrink, proportionally, according to their flex-shrink property. But contrary to what many browsers allow, they’re not supposed to shrink indefinitely. They must always be at least as big as their minimum height or width properties declare, and if no minimum height or width properties are set, their minimum size should be the default minimum size of their content.

According to the flexbox specification :

By default, flex items won’t shrink below their minimum content size (the length of the longest word or fixed-size element). To change this, set the min-width or min-height property.

Chrome, Opera, and Safari currently ignore this instruction and allow flex items to shrink to zero. As a result, you get content overlapping.

Unitless flex-basis

Prior to the release of IE 10, the flexbox spec at the time stated that a flexbox item’s preferred size required a unit when using the flex shorthand:

If the <preferred-size> is ‘0’, it must be specified with a unit (like ‘0px’) to avoid ambiguity; unitless zero will either be interpreted as as one of the flexibilities, or is a syntax error.

This is no longer true in the spec, but IE 10-11 still treat it as true. If you use the declaration flex: 1 0 0 in one of these browsers, it will be an error and the entire rule (including all the flexibility properties) will be ignored.

Finding an alternative sticky footer solution

I choose the sticky footer layout as the main example for this article because I encountered each and every one of these bugs while trying to find a cross-browser solution to it. But before I go into too many specifics, let’s make sure we’re all on the same page.

Here is the markup I’m using for my sticky footer layout:

And here’s the CSS that will make the footer stick in any spec-compliant browser:

Now, as I’ve already mentioned, this CSS should work, but due to the existing bugs and the fact that not all browsers are fully spec-compliant, it does not.

If you’re an experienced front-end developer, you know that any solution to a cross-browser problem not only needs to work today, but it needs to continue to work long after you finish a project.

A solution that depends on buggy behavior is no solution at all.

Based on everything I’ve said so far, here are my personal requirements for any acceptable alternative solution to the sticky footer layout problem. It must:

• work in all browsers [2]
• continue to work as browsers fix broken behavior
• not rely on any browser-specific hack

Using height instead of min-height

If you’ve been around for a while, you may remember that Internet Explorer 6 never supported the min-height (or width) property. It did, however, treat height:100% the same way other browsers treated min-height:100% , so all the original sticky footer solutions would recommend setting height:100% in an IE 6-only stylesheet.

Knowing this, using height:100vh instead of min-height:100vh was one of the first workarounds I tried. It actually did work in IE, but it didn’t work in Chrome, so I immediately wrote it off.

As it turns out, I should have read the spec closer instead of simply assuming Chrome was right and IE was wrong.

In CSS, you typically choose to use min-height over height to protect yourself from the dreaded overflow. When there’s too much content, an explicit height will mean there’s either going to be clipping, overlapping, or a scroll bar. And in many situations, those are all bad. However, when you’re dealing with the body element (as you are in a sticky footer layout), a scroll bar is no big deal. It’s actually what you want. So if you define an explicit height of 100vh on the body and there’s too much content, the end result should be the same.

So then the question is: why didn’t this work in Chrome?

Minimum sizing bugs

Previously, I mentioned that some browsers mistakenly allow flex items to shrink to less than their default minimum content size, resulting in content overlap. This is why swapping min-height for height didn’t work when I tested it in Chrome.

What should happen is the header, footer, and content elements should all shrink to their default minimum content size (but not less). If these elements (combined) have more content than can fit on the screen, the body element should overflow with a scroll bar like it usually does. The header, footer, and content elements should all render normally, one on top of the other, with no overlap.

What was happening instead is Chrome was allowing the header, footer, and content elements to shrink to smaller than their default minimum content sizes. As a result, instead of the overflow happening on the body element, it was happening on the header, footer, and content elements themselves. And since the default overflow value of those elements is visible , their content was overlapping with each other. The footer was fixed to the bottom of the page, and the page content was overflowing below it.

Luckily, there’s an easy solution to this problem.

The flexbox spec defines an initial flex-shrink value of 1 but says items should not shrink below their default minimum content size. You can get pretty much this exact same behavior by using a flex-shrink value of 0 instead of the default 1 . [3] If your element is already being sized based on its children, and it hasn’t set a width , height , or flex-basis value, then setting flex-shrink:0 will render it the same way—but it will avoid this bug.

Avoiding unitless flex-basis

The unitless flex-basis bug is by far the easiest of the three to work around, but it’s arguably the hardest one to track down when encountered in the wild.

My original solution to the sticky footer problem applied a declaration of flex:1 to the main content element. Since a flex value of 1 is shorthand for 1 1 0px , [4] and since I knew I didn’t want any shrinkage going on, I decided to use 1 0 0px instead.

This worked just fine until I tested it in IE.

The problem ended up being a combination of this IE bug and my CSS minifier: the minifier was converting 1 0 0px to 1 0 0 (which has a unitless flex-basis value), so IE 10-11 ignored this declaration entirely.

Once I finally discovered the root of the problem, the fix was trivial. Either set an explicit flex-basis value or use 0% in the flex shorthand. Note, using 0% is better than 0px since most minifiers won’t touch percentage values for other reasons.

Putting it all together

The following is a quick summary of the bugs discussed in this article and their respective solutions:

• min-height on a column flex container won’t apply to its flex item children in IE 10-11. Use height instead if possible.
• Chrome, Opera, and Safari do not honor the default min-content size of flex items. Set flex-shrink to 0 (instead of the default 1 ) to avoid unwanted shrinkage.
• Do not use unitless flex-basis values in the flex shorthand because IE 10-11 will error. Also use 0% instead of 0px since minifiers will often convert 0px to 0 (which is unitless and will have the same problem).

With all these bug and workarounds in mind, here is the final, alternative solution I came up with. It may not be as clean or intuitive as the way I originally promoted, but it does meet all of my requirements for an alternative solution:

• It works in all browsers.
• It’s spec compliant, so it should continue to work as bugs are fixed.
• It does not use any browser-specific hacks.

I’ve added comments to the CSS to clarify which parts are workarounds:

To see this new solution in action, check out the updated Solved by Flexbox sticky footer demo .

It’s Mid-2022 and Browsers (Mostly Safari) Still Break Accessibility via Display Properties

It was late 2020 when I last tested how browsers use CSS display properties to break the semantics of elements.

I had been waiting for Safari to fix how it handles display: contents for four years now, and was excited when the announcement came in June. Then I started testing the latest Safari Technical Preview and the results were not good . That prompted me to give each of Chrome, Firefox, and Safari a fresh run to see how they performed.

The following results are each set in a table with a numbered list following that provides more detail on any cells that are numbered:

• There was a Chrome 113 regression where cell semantics (which have display: contents were removed from the accessibility tree. This was fixed in Chrome 115. 1448706
• <ol> s and <ul> s are not treated as lists, but <dl> s perform fine.
• There was a Chrome 113 regression where description lists had no list item semantics. This was fixed in Chrome 115. 1448706
• There was a Chrome 113 regression where headings no longer conveyed semantics. This was fixed in Chrome 115. 1448706
• Shows as a button in the accessibility inspector, but does not receive keyboard focus; cannot be navigated with JAWS 2022 button command ( B ); can be activated with a mouse, touch, and screen reader virtual cursor. 1366037
• As of Chrome 115, still does not receive keyboard focus (so inoperable with keyboard) but now can be activated with screen reader commands.
• <th> s with flex and grid are exposed as cells, not headers. 1711273
• Using NVDA 2022.1–2023.1, the table reports the wrong number of rows and columns and cannot be navigated with table navigation commands ( Ctrl + Alt + ← ↑ → ↓ ).
• Tested in Firefox 113 and all is well.
• Inserts text leaf between each list item; NVDA announces each item in the list when navigating by list ( L ).
• Shows as a button in the accessibility inspector, but does not receive keyboard focus; cannot be navigated with NVDA button command ( B ); can be activated with a mouse, touch, and screen reader virtual cursor; dev tools show a keyboard use warning. 1791648
• VoiceOver announces the wrong column and row count for each table; VoiceOver does not announce column headers when moving between columns; VoiceOver table navigation commands do not work ( Ctrl + Option + ⌘ + ← ↑ → ↓ ). 239478 , 239479
• VoiceOver announces the entirety of each row as a run-on and announces no column nor cell counts. This appears to be a regression in Safari 16.5.
• VoiceOver does not announce ordered or unordered lists as lists (description lists are fine); VoiceOver does not navigate to ordered or unordered lists with list navigation ( Ctrl + Option + ⌘ + X ). 243486 , 243373 , 259487
• VoiceOver announces the entirety of each description list as a run-on. This appears to be a regression in Safari 16.5.
• Does not receive keyboard focus; cannot be navigated with VoiceOver button command ( Ctrl + Option + ⌘ + J ); can be activated with a mouse. 243486 , 255149
• As of Safari TP 151, can be navigated with VoiceOver button command ( Ctrl + Option + ⌘ + J ) but its accessible name is not announced.
• As of Safari TP 152, its accessible name is announced.
• Safari 16 has regressed from Safari TP 152; the accessible name is not announced and it has none in the accessibility tree.
• In Safari 16.5 it announces as button, can be navigated as a button with VoiceOver only. It can be activated with VoiceOver Ctrl + Option + Space only. It does not accept keyboard focus and so cannot be activated with keyboard alone.
• Safari 17 now treats description lists as description lists (no run-on announcement).
• Works as expected as of Safari 17.
• Does not announce as a button and is not exposed when navigating by controls, but can be activated. Also has no focus style.
• Table data cannot be accessed using VoiceOver when swiping or using read-all, and swiping from within table after using explore-by-touch does not advance to next cell. This appears to be a regression in Safari 16.5 (previously you could at least move through the text). 257458
• VoiceOver treats all cells as in column 1 and does not provide column headers. 243474
• VoiceOver does not announce ordered or unordered lists as lists (description lists are fine).
• Fires on double-tap with VoiceOver.
• In Safari 16.5 it announces as button, can be navigated as a button, and activates with and without VoiceOver. It still has no default focus ring.
• Announces as heading as of Safari 17, but can not be navigated as a heading. 261978

Chrome cleaned itself up and has held steady for more than 20 versions. Firefox needs work, but at least saw a tiny improvement. Safari made one tiny improvement but has a much bigger deficit, and I don’t trust it will improve much given its now twice-promised fix for display: contents .

The following four embedded CodePens are what I used for testing. These do not account for all scenarios or use cases, but at least provide a baseline set of results. They were all created in early 2020. I adapted them by adding horizontal rules between each test since VoiceOver was concatenating some elements with display: contents to the prior element.

Each links to a CodePen debug mode so you can test it directly, without the iframe or wrapper cruft.

HTML Tables

Visit the tables test in debug mode .

See the Pen Tables with Assorted Display Properties by Adrian Roselli ( @aardrian ) on CodePen .

Visit the lists test in debug mode .

See the Pen Lists with Assorted Display Properties by Adrian Roselli ( @aardrian ) on CodePen .

Visit the headings test in debug mode .

See the Pen Headings with Assorted Display Properties by Adrian Roselli ( @aardrian ) on CodePen .

Visit the buttons test in debug mode .

See the Pen Buttons with Assorted Display Properties by Adrian Roselli ( @aardrian ) on CodePen .

I have not gone through all the old browser bugs, identified outstanding open bugs, nor filed fresh bugs. I just don’t have the energy. I am hoping readers can confirm or deny my findings, however, so if/when I muster that energy I have confirmation these issues aren’t just a failing on my end.

I have written about display properties, tables, and accessibility a bunch over the last few years. Others have also kicked in a pile of posts. This list is not exhaustive.

• It’s OK to Use Tables , 16 July 2012
• Hey, It’s Still OK to Use Tables , 1 November 2017
• A Responsive Accessible Table , 2 November 2017
• Tables, CSS Display Properties, and ARIA , 20 February 2018
• Tables, JSON, CSS, ARIA, RWD, TLAs… , 2 April 2018
• Display: Contents Is Not a CSS Reset , 1 May 2018
• Functions to Add ARIA to Tables and Lists , 12 May 2018
• a11yTO Conf: CSS Display Properties versus HTML Semantics , 21 October 2020
• CSS3 — Appendix B: Effects of display: contents on Unusual Elements
• Data Tables by Heydon Pickering
• Short note on what CSS display properties do to table semantics by Steve Faulkner, 4 March 2018
• How display: contents; Works by Ire Aderinokun, 27 Mar 2018
• More accessible markup with display: contents by Hidde de Vries, 20 April 2018, updated to reference this post

Update: 15 July 2022

I heard back from someone who works on WebKit ( finally ) and he confirmed the issues I found with the following bugs:

• Bug 242779 – AX: display:contents elements are inserted in the wrong position when they have inline renderer siblings , 14 July 2022
• Bug 239479 – AX: Support display:contents for table elements , 18 April 2022

Update: 22 July 2022

I tested Safari Technology Preview 149 today. No change.

Update: 4 August 2022

I tested Safari Technology Preview 150 today on macOS 12.5. No change.

Update: 6 August 2022

More updates from Tyler Wilcock , namely that three commits have landed in WebKit that address the heading and button examples in this post:

• Closes new bug Bug 243373 – AX: An unnecessary group is created for every block-flow box with no other useful AX semantics , 30 July 2022
• Also closes its older duplicate Bug 242779 – AX: display:contents elements are inserted in the wrong position when they have inline renderer siblings , 14 July 2022
• Closes new bug Bug 243474 – AX: On iOS, display:contents elements are inserted in the wrong position when they have inline renderer siblings , 2 August 2022
• Closes new bug Bug 243486 – AX: AXCoreObject::textUnderElement always returns an empty string for display:contents elements , 3 August 2022

I am thrilled to see the now-rapid progress from Tyler specifically. Compared to the current silence from Apple’s dedicated developer relations arm, past Apple mis-representation of fixes, and years of Apple’s failure to test for these obvious issues, this has been a breath of fresh air.

No idea which Safari Technical Preview will see these updates, but I am hopeful they will make it to Safari 16.

Update: 16 August 2022

I tested Safari Technology Preview 151 today on macOS 12.5.1. No change except a button with display: contents is now partially exposed in one context.

Update: 27 August 2022

I tested Safari Technology Preview 152 today. No change except a button with display: contents now has its accessible name announced.

Update: 11 September 2022

I tested Safari Technology Preview 153 today. No changes.

Update: 12 September 2022

I tested Safari 16 on macOS 12.6 today. It is equivalent to Safari TP 151. Tables with display properties are difficult to impossible to navigate with VoiceOver. Buttons with display: contents have no accessible name and do not activate on Enter ↵ . The minor improvements since Safari 15 (and before) are not enough to make buttons or tables accessibility supported on macOS. All this despite the following claim today:

Safari 16 introduces a re-architecture of WebKit’s accessibility support on macOS. […] Safari 16 also greatly improves accessibility support for elements with display:contents by ensuring they are properly represented in the accessibility tree. WebKit Features in Safari 16.0 , 12 September 2022

And this claim in June 2022:

I’m so happy that the severe mistake implementing `display: contents` and how it impacts the accessibility tree — one that originally shipped in all browsers — is now finally fixed in all browsers. (Including on iOS! Ooops my bug on Can I Use.) pic.twitter.com/IGrvMTM1Rv Jen Simmons (@jensimmons) 13 June 2022

And this claim in March 2022:

WebKit fixed an accessibility bug with display:contents , which incorrectly hid content from the accessibility tree. This fix makes it possible to freely use this display value to remove a box from the DOM tree , while still including its children. This can be useful when you want to adjust which box is the child of a Flexbox or Grid container, for instance. New WebKit Features in Safari 15.4 , 14 March 2022

Web developers, I have big news! Safari 15.4 is here, packed with 70+ new features — lazy loading, dialog, :has(), Cascade Layers, svh/lvh/dvh, focus-visible, accent-color, display: contents fix, scroll-behavior, Manifest icons, BroadcastChannel & more: webkit.org/blog/12445/new-webkit- Jen Simmons (@jensimmons) 14 March 2022

And this claim two days after I posted this update:

This is clearly a bug in Safari 16.0. One that we have already resolved. The fix is currently in Safari 16.1 beta. Comment on #6451 Safari 16 (release version) still broken

I really wish Apple had a dedicated Safari Twitter account instead of hanging its evangelist and/or the open source WebKit project out there to take the heat. That is unfair.

Remember that this is not an excuse to beat up the devs at Apple. If you are doing that, you are being unnecessarily mean to individuals who may have no control over broader organizational decisions. Do not be that guy / person / jerk.

Update: 13 September 2022

I filed an issue to update the Can I Use entry for display: block , and it was merged overnight: #6451: Safari 16 (release version) still broken

The Can I Use flex and grid data comes from the MDN browser-compat-data , so I filed an issue there: #17776 css.properties.display – Safari (thru 16) flex, grid, contents problems

Update: 17 September 2022

Apple’s devrel team came through and filed another PR at Can I Use (while still engaging me in my PR) and undid my changes. The good news is that for the first time Can I Use reflects that Safari 15.x and older never properly supported display: contents , acknowldegment of its prior false claims. The less good news is that both Apple and Can I Use believe that Safari supports display: contents when using it on buttons or tables renders them inaccessible in Safari 16. Clearly we have different ideas of the term supported .

Update: 20 September 2022

Following some informal community polling , Can I Use has restored Safari’s “partial support” entry for display: contents :

My efforts have probably earned me no fans at Apple, though at least one Apple devrel person might agree with the change.

Update: 13 November 2022

No improvements in Safari 16.1. Here I demonstrate how the row and column counts are way off for the tables.

Here I am using Chrome 107, Firefox 106, and Safari 16.1 trying to Tab ↹ to the <button> with display: contents . It is worth noting that neither adding role="button" nor tabindex="0" will fix this.

Update: 29 November 2022

Promising work on resolving a Firefox bug where <th> s with CSS flex and grid are exposed as cells, not headers:

This revision fixes the problem by moving the th NativeRole logic into the TableCellAccessible class, then calling that logic from both the ARIA grid cell accessible NativeRole and from HTMLTableHeaderCellAccessible, as before. This revision also updates tests reliant on the old behavior, including beefing up an existing test aimed at this bug specifically. Comment 6 on 1711273 Losing columnHeader role when setting CSS display on a table

When that deploys it will leave Safari ≤16.1 as the last browser that breaks tables using CSS display properties.

Update: 20 December 2022

Stumbled across this piece of advice on Twitter promoting the use of display: contents :

The HTML <details> element 1 cannot become a flexbox or grid container ( display: flex and display: grid are ignored). This restriction is specified in the HTML Standard ( The <details> element is expected to render as a block box 2 ) and implemented in all browsers. It is possible to work around this limitation with display: contents 3 . […] twitter.com / LeaVerou/status /1563912029827747840 developer.mozilla.org / docs/Web /HTML/Element /details html.spec.whatwg.org / multipage /rendering.html # the-details-and-summary-elements mastodon.social / @simevidas /109538578812286095 […] Web Platform News, 19 December 2022

This is a case of trying to solve one very specific problem, layout core to an element, with a flamethrower and no regard for what else goes up in flames. In this case it is keyboard accessibility. To demonstrate that, I made a demo :

See the Pen Untitled by Adrian Roselli ( @aardrian ) on CodePen .

This is the outcome of specs that do not clarify how the content model should (or should not) be affected, browsers that ignore the bug for years, and developers who cannot be bothered to test with the one device attached to all their computers (keyboard, for those reading who never use on for testing).

The CSS display: contents property looks like such a simple salve, but in the end guarantees an access barrier.

Update: 8 April 2023

I tested Safari 16.4 on macOS 12.6.4 today. No changes.

Meanwhile, Chromium has a change ready to go that will allow elements with display:contents to be focused (3910374) , which is meant to honor CSSWG issue #2632 stating Elements that have display: contents can still be focused… .

David Baron also filed a WebKit bug and requests for Mozilla and WebKit to take a position on display: contents focusability specifically:

• WebKit Bug 255149 – elements with CSS display:contents are not focusable
• #772 Request for Mozilla Position: focusability of elements with display:contents
• WebKit #164 focusability of elements with CSS display:contents

Update: 24 May 2023

Safari on iPadOS 16.5 seems to have regressed since I can no longer get to table contents using read-all or swiping when the table has flex , grid , or block . I am forced to use explore by touch to get into the table, and even then I cannot move between cells with swiping. On the bright side, buttons work well now with contents (though I would like a default focus outline).

Safari 16.5 on macOS also appears to have regressed with tables and description lists that have display: contents . Buttons, while improved, are sadly still inaccessible to keyboard users when using contents .

Firefox 113 on Windows fixed a long-standing bug with tables, so congratulations are due there.

Chrome 113 on Windows and Android seems to have decided anything with display: contents must have its semantics stripped. This change may have happened prior to Chrome 113, which is my fault for not testing each release. Either way, tables, lists, and headings are now broken and buttons remain broken.

In response to my social media posts about this today, David Baron promptly filed a Chromium issue: 1448706: elements with display:contents no longer exposed in accessibility tree

Update: 30 May 2023

Within 48 hours of me posting the Chrome regression on Mastodon, folks from the Chrome team (current and past) confirmed the regression, identified the cause, filed an issue, fixed the issue, and queued it to roll out in Chrome 115 (scheduled for 12 July). Thanks to David Baron, Alice Boxhall, and Aaron Leventhal.

While this kind of pro-active bug fix is great to see in action, there is still a significant barrier for users that will take about 3 months and 2+ versions for them to see fixed.

Meanwhile, I filed a new bug against Safari on iPadOS 16.5, Bug 257458 – AX: Tables with display properties are skipped, report wrong col/row counts , which includes the following video:

In the Safari issue I cite eighteen distinct bugs:

• Tables with display: flex on the <tr> cannot be navigated into using swipe gestures (swipe right or left).
• Tables with display: flex on the <tr> are skipped when using read-all.
• Tables with display: grid on the <tr> cannot be navigated into using swipe gestures (swipe right or left)
• Tables with display: grid on the <tr> are skipped when using read-all.
• Tables with display: block on the <td> and <th> give the wrong column count.
• Tables with display: block on the <td> and <th> announce each <th> with the first <th> when first entering a row.
• Tables with display: block on the <td> and <th> announce each column header <th> as a row header.
• Tables with display: block on the <td> and <th> announce each column header <th> as column 1.
• Tables with display: block on the <td> and <th> announce each <td> with the wrong or no column header.
• Tables with display: block on the <td> and <th> announce each <td> as column 1.
• Tables with display: inline-block on the <td> and <th> give the wrong column count.
• Tables with display: inline-block on the <td> and <th> announce each <th> with the first <th> when first entering a row.
• Tables with display: inline-block on the <td> and <th> announce each column header <th> as a row header.
• Tables with display: inline-block on the <td> and <th> announce each column header <th> as column 1.
• Tables with display: inline-block on the <td> and <th> announce each <td> with no column header.
• Tables with display: inline-block on the <td> and <th> announce each <td> as column 1.
• Tables with display: contents on the <td> cannot be navigated into using swipe gestures (swipe right or left).
• Tables with display: contents on the <td> are skipped when using read-all.

I filed the following additional issues/PRs:

• MDN Browser Compat: #19994: Safari Table Support – CSS Display Properties Break Tables
• Pull request for CSS inline-block at Can I Use (there appears to be no entry for block , but the same bugs apply): #6731: Update inline-block.json for Safari bugs

I have low hopes for the MDN Brower Compat charts updating since #17776: css.properties.display – Safari (thru 16) flex, grid, contents problems has been open and untouched since September 2022.

Similarly, Safari issue Bug 239479: AX: Support display:contents for table elements has sat for over a year (filed 18 April 2022).

Update: 7 June 2023

I updated Bug 257458 – AX: Tables with display properties are skipped, report wrong col/row counts to include results of testing with Safari 16.5 and VoiceOver on macOS 12.6.6:

• Tables with display: flex on the <tr> cannot be navigated into using table navigation.
• Tables with display: flex on the <tr> cannot be navigated into using swipe gestures.
• Tables with display: block on the <th> announce each as a cell.
• Tables with display: block on the <td> and <th> do not support navigating within a column.
• Tables with display: block on the <td> and <th> do not announce column headers.
• Tables with display: inline-block on the <td> and <th> announce the entirety of cells in a row as a single node.
• Tables with display: inline-block on the <td> and <th> do not support navigating within a column (because it is treated as one column).
• Tables with display: inline-block on the <td> and <th> do not announce column headers.
• Tables with display: contents on the <td> and <th> cannot be navigated into using table navigation.
• Tables with display: contents on the <td> and <th> are skipped when using read-all.
• Tables with display: contents on the <td> and <th> have each row read as a single string of text.

So far I have seen no signals about this from Apple’s WWDC Safari and CSS talk , despite demonstrating some of these properties.

The Safari 17 beta announcement suggests some fixes for display: contents , but not for the issues I cite here. Which is insight that there are likely far more issues than the four types of elements I have tracked in this post.

Update: 21 July 2023

Progress in Safari Technology Preview 174 on macOS. Items 19–33 are addressed. I found two new issues, which are a function of the fixes:

• Tables with display: contents on the <td> and <th> can be navigated into using table navigation, but VoiceOver announces each cell as “blank”.
• Tables with display: contents on the <td> and <th> do not announce cell contents when using read-all. VoiceOver simply announces the column and row position.

I added these to the Safari bug that has gottent traction . I am not updating the support table owing to regressions I have seen in other TPs. I will update it when and if the fixes come to Safari 17.

I did not test Safari TP on iPadOS as I cannot seem to locate a TP for the platform.

Update: 13 August 2023

More progress in Safari Technology Preview 176 on macOS. The two new bugs I found are fixed. Granted, they should never had made it to the TP where I could find them, but at least I someone (me) caught them.

I did not test on iPadOS nor iPhoneOS. I did not re-test any prior issues for regressions. Apple is not paying me enough (nothing, actually) to do all of its QA.

I am not updating the support table above owing to regressions I have seen in other TPs. I will update it when and if the fixes come to Safari 17. Safari 17 is in beta now, but I am not testing it. I also understand not all Safari 17 features will be supported in macOS 12 or even 13, but I see no reason these fixes would not be. It would be a shame if users would have to upgrade hardware just to use tables for the first time in years.

Update: 14 August 2023

I confirmed that Chrome 115 fixes the regresions I identifed in May . Lists and buttons with display: contents are still broken. This is most obvious with TalkBack where navigating to the sample lists rattles off the entire list as one single string of text.

Update: 22 September 2023

Significant progress in Safari 17 for iPadOS. Tables work now, which is spectacular. I find it odd that calling a native HTML element that only functions correctly in assistive technology years after the issue was reported “spectacular” when it should simply be expected, but here we are.

I did not expect lists to get any update. Apple has made a decision on that which is unlikely to change. It annoys some users, not others, and makes devs grumpy.

Headings with display: contents now announce as headings when you encounter them, but you cannot navigate by them. That is a disappointment because it feels like Safari was so close and Safari Technology Preview 179 on macOS does not have this problem. Which makes this statement not quite accurate:

WebKit for Safari 17.0 fixes our remaining accessibility issues with display:contents . WebKit Features in Safari 17.0

Buttons continue to not have a focus ring, but all browsers are struggling with this.

Update: 7 October 2023

Very good progress in Safari 17. Tables and description lists are no longer broken when display properties are applied. Buttons with display: contents , however, are still inoperable by keyboard users and problematic for VO users (and I confirmed is also the case in Safari TP 180).

Meanwhile, the heading issue I reported for Safari 17 on iPadOS ( 261978 – AX: Headings with `display: contents` cannot be navigated ) has been marked as a VoiceOver issue with no insight when it will be fixed. But marking it a VoiceOver issue means Safari can claim to have no bug so yay?

Apple seems reasonably confident it has finally fixed its historically years-lagging support (despite prior claims), and so has been doing the rounds suddenly arguing all the other browsers and specs need to fix display: contents issues while using its own claims of (abruptly and questionably) better support to bolster them:

• CSS Working Group Comment on #3040 [css-a11y][css-display] display: contents; strips semantic role from elements from 2018.
• Web Platform Tests #568 display: contents

I also filed a PR with Can I Use to amend the one filed by Apple three weeks ago (I was unable to review owing to travel and this is not my job slash no one is paying me).

With Safari almost there on basic support and Apple now pushing for the specs and browsers to agree, after sitting it out for a few years, I am excited that the end is in sight. Which I expect before WCAG 3.

Update: 11 June 2024

Filed a new bug on Safari and how it handles a display property with tables: 275366 – AX: Tables with show/hide rows report wrong counts and block access to some rows in VoiceOver .

While this falls down over display: none versus flex or grid or contents , its still a display property that had been well supported when I first made the example.

After all, who doesn’t like regression testing years-old features with every Safari release?

Update: 5 September 2024

Ahmad Shadeed discusses display: contents in a new post and specifically notes accessibility concerns:

CSS display: contents is known to cause accessbility issues when used with HTML tables, headings, buttons, and lists. Please make sure to avoid using it on such elements. Here are some further resources: CSS display contents , 4 September 2024

Those four things he cites are simply what I tested. It required too much effort on my part to test everything , so I used a sub-set of HTML elements that covered a good range of features.

More direct advice would be: do not use display: contents on anything that can take focus or is interactive. Probably avoid it on things with richer semantics (such as tables and lists and headings and so on).

Also, be cautious with reading order. Pay attention to the section of this CSS Day talk related to display: contents , at roughly 36:30.

YouTube: Layout and Reading Order | Rachel Andrew | CSS Day 2024 , 50:46

Then go read Request for developer feedback on reading-flow and elements with display: contents . If you work in accessibility in particular, please weigh in. Part of the reason display: contents is such a mess is because it was poorly specified and the needed digital accessibility expertise was not part of that process.

Update: 16 September 2024

I have cautioned for some time now, including the prior update, that you must test every use of display: contents and not rely solely on my limited tested in this post (and prior posts) nor claims of browsers.

As evidence:

Fixed display: contents on tbody elements preventing table rows from being properly exposed in the accessibility tree. ( 282413@main ) (129131780) Release Notes for Safari Technology Preview 203 , 11 September 2024

In other words, tables are still broken in Safari if you use display: contents , and will be at least until this latest fix makes it to a production Safari release. I have no interest in going through every permutation of every table construct to test other things Apple has missed. That’s Apple’s job.

Reply I encounter similar issues when I wish to set grid on the body element and display contents on the main element. The main issue I have is implementing a skip to content link that targets the main[display: contents] element :( I think this should be of interest to the community since the following is a common DOM pattern: Skipping the main element would really be a shame Neil Osman ; 1 August 2022 at 7:36 am . Permalink

In response to Neil Osman . Reply part of my comment was sanitized, so here is a demo that illustrates my point https://codepen.io/WW3/pen/XWEVoqN Neil ; 1 August 2022 at 10:15 am . Permalink

Reply Thank you for posting this and for continuously testing for the current state of things. display: contents seems really valuable as CSS grid becomes more commonplace, but until some of these issues are fixed I’m still going to avoid grid entirely (where feasilbe) in cases where display: contents would be necessary. Clayton ; 13 March 2023 at 6:21 pm . Permalink

In response to Clayton . Reply FWIW, I think an alternate approach might be to test the problematic instances on your audience’s browsers and then decide which cases you can ignore and which cases are problems. But I very much understand the frustration — I have been there for a few years now. Adrian Roselli ; 19 March 2023 at 8:05 pm . Permalink

Reply […] from the accessibility tree in response to certain display properties, including display: none. It’s Mid-2022 and Browsers (Mostly Safari) Still Break Accessibility via Display Properties by Adrian Roselli covers this in more […] MDN’s AI Help and lucid lies - Seirdy ; 5 April 2024 at 7:41 pm . Permalink

Leave a Comment or Response Cancel response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

Safari flex-basis animation bug #176

DrummerHead commented Sep 14, 2016

• 👍 1 reaction

gregwhitworth commented Sep 14, 2016

Sorry, something went wrong.

philipwalton commented Oct 17, 2016

DrummerHead commented Oct 17, 2016

• 👍 2 reactions

jeegurda commented Nov 7, 2017 • edited Loading

dotnetCarpenter commented Dec 5, 2017

• 👍 4 reactions

dotnetCarpenter commented Nov 5, 2020 • edited Loading

• 🎉 1 reaction

No branches or pull requests

Safari 14.1 Adds Support for Flexbox Gaps

DigitalOcean provides cloud products for every stage of your journey. Get started with $200 in free credit!

Yay, it’s here! Safari 14.1 reportedly adds support for the gap property in flexbox layouts. We’ve had grid-gap support for some time, but true to its name, it’s limited to grid layouts. Now we can use gap in either type of layout:

Apple’s been rather quiet about the update. I didn’t even hear about it until Eric Meyer brought it up in an email, and he only heard about it when Jen Simmons tweeted it out.

Did you see, Safari 14.1 shipped yesterday… including support for Gaps in Flexbox. (*Can I Use & MDN still need to be updated, so they don't show support yet… but it's there! Try it out.) — Jen Simmons (@jensimmons) April 27, 2021

I checked the WebKit CSS Feature Status and, sure enough, it’s supported . It just wasn’t called out in the release notes. Nothing is posted to Safari’s release notes archive just yet, so maybe we’ll hear about it officially there at some point. For now, it seems that Maximiliano Firtman ‘s overview of iOS 14.5 is the deepest look at what’s new .

And how timely is it that Eric recently covered how to use the gap property , not only in grid and flexbox layouts, but multi-column as well.

Apple has pulled Safari 14.1 update for Mojave and Catalina: https://eclecticlight.co/2021/04/30/apple-has-pulled-safari-14-1-update-for-mojave-and-catalina/

Oh geez! Thanks for the heads up.

It’s such a practical feature. But what about horizontal-gap and vertical-gap, was not it better? In the other hand second parameter?

Grid still supports that I think? No? Flexbox is just one-directional so I guess it makes sense that it doesn’t, although I could imagine a world where that second param is the spacing between rows when flexbox wraps.

About flippin’ time. They also introduced support for <input type="date/time/datetime"> , I believe. Perhaps they’re keeping it quiet because they’re embarrassed at how long it’s taken them.

Safari is the new IE.

I’m starting to see why it was probably pretty vital for Jen Simmons to jump ship from Mozilla to Safari, but if she’s whipping it into shape at Apple, I’m all for it.

Here are the release notes: https://webkit.org/blog/11648/new-webkit-features-in-safari-14-1/

One thing which is missing there is correct support of scroll-margin and scroll-padding – the end of negative-margin + positive-padding hack for scrolling to anchor when having fixed navbar.

Frekin’ FINALLY!!!

Ok, that’s a good news, but i think we’re not going to use this for… at least two years, because of retrocompatibility?

Happy and sad at the same time.

I am so waiting for Lazy Load. Now it’s natively everywhere, but not yet in Safari.