safari css grid not working

CSS Grid not display correctly in Safari

I have a couple of CSS Grid elements and they display perfectly in Chrome and Firefox, however when in Safari they are all messed up. I have tried some of the solutions shown in other posts but nothing has worked. The grid is also not working right in Safari on iPad but is fine on iPhone. What’s up with THAT?

Here is my site Read-Only: **[ https://preview.webflow.com/preview/kelly-hoopers-website?utm_medium=preview_link&utm_source=designer&utm_content=kelly-hoopers-website&preview=de6225062126e07a94a005cb2d8a3aa8&pageId=608709fce1d822a9235430e9&mode=preview

CSS grid is not fully supported by all browsers. What version of Safari are you using? This page shows which browsers support CSS grid and which browser versions do not support CSS grid. Also, if you look at the known issues tab on the “Can I Use” page it says “Safari does not yet support intrinsic and extrinsic sizing with grid properties such as `grid-template-rows’”.

hi @freedj I have looked on your issue and your problem is with settings of container 12 and grid images height. All you have to do is to set container 12 to block and images height to auto . Here is a short video how to do that.

https://cln.sh/7e5RdN

AMAZING! Thank you!!

I have this problem too but can’t seem to work out how to fix it. On the homepage I have a testimonial section which breaks on Safari, also using a grid. Can anyone help?

Read only link: https://preview.webflow.com/preview/earthfound?utm_medium=preview_link&utm_source=designer&utm_content=earthfound&preview=610dcbf4d7d396411512e3b3cd157507&workflow=preview

I also had a problem with a grid in Apple Safari and found out it had to do with: Grid > Distribute. I changed this to: Grid > Distribute > Content Start and now it is displayed properly.

Maybe you can do something with it.

[solved] CSS grid not displaying correctly on actual mobile browsers (all displays correctly when testing mobile screens on desktop though )

CSS grid is not displaying correctly on actual mobile browsers (all displays correctly when testing mobile screens on desktop though). EDIT: The issue here happens only on Safari IOS.

i.e. Browser debugging is misleading. This is inconsistent and not how this should work.

What am I missing?

See this for the solution: [solved] Need workaround to make CSS grid work on IOS Safari

My best guess would be that CopePen is rendering the page for a desktop, on your phone. That being said, the devTools that come with Chrome are very powerful, and could be fixing any media-query related CSS for you.

Basically, if you resize your browser, without using the dedicated devTools you will see that the page is not responsive anyway.

Hope this helps.

Thanks for writing @Sky020 !

The same actually happens outside Codepen (I’ve just deployed to Netlify).

Could you clarify further what you mean with “if you resize your browser, without using the dedicated devTools you will see that the page is not responsive anyway.”?

Reason is: I’ve just deployed the code on Netlify and when I resize the browser without the dedicated devTools I do not have issues with styling.

I guess my issue with this is that I’m lacking trust on devTools to code with CSS grid. Is this common? Is there anything else I may have gotten really wrong here? Or should I simply not trust devTools and go ahead and implement some media queries?

Quick fix. I am running late.

See how that works.

Thanks again for reverting @Sky020 ! I’m really kind of lost with this styling!

Sadly your suggestion didn’t fix it. See attachment.

I’m also struggling even to fix it with any type of media queries (while still keeping it CSS grid based). Nothing seems to fix it.

I’d love to

understand that discrepancy between desktop debugging of mobile screens, but also

looking for suggestions for any media queries that might fix this styling - keeping it CSS grid based (because nothing I implement is fixing it).

This discrepancy only happens on IOS devices. (i.e. everything running Safari - and all rest given they are all Safari on IOS).

according to https://caniuse.com/#search=grid , IOS safari should render css grid, but I’m seemingly doing something very wrong here… Pointers welcome.

Sorry to see it is not working. Unfortunately, I am unable to emulate it on my laptop. It is concerning that there is a discrepancy between the debug tools and Safari.

Here is something that might help, but I cannot test it:

Note: The values “flex” and “inline-flex” requires the -webkit- prefix to work in Safari. w3schools w3schools display

Have a look at those, and, at least for all of your display properties, add the -webkit- prefix for Safari. Browser Support

Thanks. I’ve applied all types of CSS prefixers but nothing.

For others in the future: Safari IOS does not support extrinsic sizing with grid properties such as grid-template-columns. Check known issues at: https://caniuse.com/#search=grid

I have no solution to this, nor a workaround, at this stage.

See my response in your other thread about the intrinsic/extrinsic sizing.

FYI. The browser can not emulate devices. For true cross browser testing you need to test on the actual devices. There are online tools (mainly commercial) that you can use as well.

CSS grid not displaying properly on Safari

Hi all! I’ve been trying to figure out what I’m doing wrong with my CSS grid items, but I’m at a loss. They display properly on both Chrome and Firefox, but in Safari, the items in the grid container don’t seem to be aligning to the end of the container (even though “align-items: end” is showing up in the inspector).

Can anyone else see what I’m doing wrong here?

https://www.shainanacion.com/brand-design

wouldnt load at all for me on mobile. the site timed out. tried the root url as well.

Ok now its working. i see on mobile in portrait view everything is good. once i go to landscape that first row of divs below the main part gets messed up. and you have checked the landscape settings for this? i would check the actual size views in the browser rather than shrinking the browser itself. usually you can do this when inspecting the page

Hey John! Thanks for checking it out. The problems I’m having seem to be with the type of browser (Safari) irrespective of aspect ratio. In every test those grid blocks are displaying incorrectly as compared to how they’re displayed on Firefox or on Chrome (see screenshots below):

I see some of the issues now more clearly.

@John_McConnell Thank you for the idea. I tried that, but it didn’t seem to help; everything looks the same as it did prior to using these overrides.

@Andre Maybe you have some ideas?

Also, this is a better page to see the malfunction on: Ala-carte - Shaina Nacion Design Studio

Update: I was able to solve the problem. For some reason (I still don’t know why this worked) I had to put the grid container into another div with “display: grid” and then it displayed properly.

So if anyone else is having this issue with Safari, try doubling up on your CSS grid containers!

Related Topics

• Skip to main content
• Skip to search
• Skip to select language
• Sign up for free

CSS Grid Layout and progressive enhancement

In Spring of 2017, we saw for the first time a major specification like Grid being shipped into browsers almost simultaneously, and we now have CSS Grid Layout support in the public versions of Firefox, Chrome, Opera, Safari and Edge. However, while evergreen browsers mean that many of us are going to see the majority of users having Grid Layout support very quickly, there are also old or non-supporting browsers to contend with. In this guide we will walk through a variety of strategies for support.

The supporting browsers

CSS Grid Layout is unprefixed in all modern browsers. Support for all the properties and values detailed in these guides is interoperable across browsers. This means that if you write some Grid Layout code in Firefox, it should work in the same way in Chrome. This is no longer an experimental specification, and you are safe to use it in production.

Is it safe to use CSS grids for my layout?

Yes. As with any front-end technology choice, the decision to use CSS Grid Layout will come down to the browsers your site visitors are typically using.

Starting to use Grid in production

It is worth noting that you do not have to use grid in an all or nothing way. Start by enhancing elements in your design with grid, that could otherwise display using an older method. Overwriting of legacy methods with grid layout works surprisingly well, due to the way grid interacts with these other methods.

Floats used to be used to create multiple column layouts. If you're supporting an old codebase with floated layouts, there will be no conflict. Grid items ignore the float property; the fact is that a grid item takes precedence. In the example below, I have a simple media object. If the float is not removed from legacy CSS, as the container is a grid container, it's OK. We can use the alignment properties that are implemented in CSS Grids.

The float no longer applies, and I can use the CSS Box Alignment property align-self to align my content to the end of the container:

The image below shows the media object in a non-supporting browser on the left, and a supporting one on the right:

Using feature queries

The above example is very simple, and we can get away without needing to write code that would be a problem to browsers that do not support grid, and legacy code is not an issue to our grid supporting browsers. However, things are not always so simple.

A more complex example

In this next example, I have a set of floated cards. I have given the cards a width , in order to float them. To create gaps between the cards, I use a margin on the items, and then a negative margin on the container:

The example demonstrates the typical problem that we have with floated layouts: if additional content is added to any one card, the layout breaks.

As a concession for older browsers, I have set a min-height on the items, and hope that my content editors won't add too much content and make a mess of the layout!

I then enhance the layout using grid. I can turn my <ul> into a grid container with three column tracks. However, the width I have assigned to the list items themselves still applies, and it now makes those items a third of the width of the track:

If I reset the width to auto , then this will stop the float behavior happening for older browsers. I need to be able to define the width for older browsers, and remove the width for grid supporting browsers. Thanks to CSS Feature Queries I can do this, right in my CSS.

A solution using feature queries

Feature queries will look very familiar if you have ever used a media query to create a responsive layout. Rather than checking a viewport width, or some feature of the browser or device, we check for support of a CSS property and value pair using an @supports rule. Inside the feature query, we can then write any CSS we need to apply our modern layout, and remove anything required for the older layout.

Feature queries have excellent browser support, and all of the browsers that support the updated grid specification support feature queries too. You can use them to deal with the issue we have with our enhanced: floated layout.

I use an @supports rule to check for support of display: grid . I then do my grid code on the <ul> , set my width and min-height on the <li> to auto . I also remove the margins and negative margins, and replace the spacing with the gap property. This means I don't get a final margin on the last row of boxes. The layout now works, even if there is more content in one of the cards, than the others:

Overwriting other values of display

Due to the problems of creating grids of items using floats, many of us would use a different method to the floated method shown above to lay out a set of cards. Using display: inline-block is an alternate method.

Once again I can use feature queries to overwrite a layout that uses display: inline-block , and again I don't need to overwrite everything. An item that is set to inline-block becomes a grid item, and so the behavior of inline-block no longer applies. I have used the vertical-align property on my item when in the inline-block display mode, but this property does not apply to grid items and, therefore, is ignored once the item becomes a grid item:

Once again it is the width on the item we need to address, and then any other properties we want to enhance. In this example I have again used gap , rather than margins and negative margins to create my gutters.

How does the specification define these overrides?

The CSS Grid Layout specification details why we can overwrite the behavior of certain properties when something becomes a grid item. The key sections of the specification are:

• Establishing Grid Containers
• Grid Item Display

As this behavior is detailed in the specification, you are safe to rely on using these overrides in your support for older browsers. Nothing described here should be seen as a "hack". Rather, we are taking advantage of the fact that the grid specification details the interaction between different layout methods.

Other values of display

When an element has a parent set to display: grid it is blockified , as defined in the CSS display specification . In the case of our item set to inline-block , this is why display: inline-block no longer applied.

If you are using display: table for your legacy layout, an item set to display: table-cell generates anonymous boxes. Therefore, if you use display: table-cell without any parent element set to display-table , an anonymous table wrapper is created around any adjacent cells, just as if you had wrapped them in a div or other element set to display: table . If you have an item set to display: table-cell , and then in a feature query change the parent to display: grid , this anonymous box creation will not happen. This means you can overwrite display: table based layouts, without having additional anonymous boxes.

Floated elements

As we have already seen, float and also clear have no effect on a grid item. Therefore you do not need to explicitly set items to float: none .

Vertical alignment

The alignment property vertical-align has no effect on a grid item. In layouts using display: inline-block or display: table , you might use the vertical-align property to perform basic alignment. In your grid layout you then have the far more powerful box alignment properties.

Multiple-column layout

You can also use multiple column layout as your legacy browser plan, as the column-* properties do not apply when applied to a grid container.

Further reading

• For an excellent explanation of feature queries, and how to use them well, see Using Feature Queries in CSS (2016) .
• CSS Grid and the New Autoprefixer (2018)

CSS Grid Layout (level 1)

Method of using a grid concept to lay out content, providing a mechanism for authors to divide available space for layout into columns and rows using a set of predictable sizing behaviors. Includes support for all grid-* properties and the fr unit.

• 4 - 24 : Not supported
• 25 - 28 : Not supported (but has polyfill available)
• 29 - 56 : Disabled by default
• 57 : Supported
• 58 - 123 : Supported
• 124 : Supported
• 125 - 127 : Supported
• 12 - 15 : Partial support
• 16 - 123 : Supported
• 3.1 - 5.1 : Not supported
• 6 - 10 : Not supported (but has polyfill available)
• 10.1 - 17.3 : Supported
• 17.4 : Supported
• 17.5 - TP : Supported
• 2 - 18 : Not supported
• 19 - 39 : Not supported (but has polyfill available)
• 40 - 51 : Disabled by default
• 52 - 53 : Supported
• 54 - 124 : Supported
• 125 : Supported
• 126 - 128 : Supported
• 9 - 27 : Not supported
• 28 - 43 : Disabled by default
• 44 - 108 : Supported
• 109 : Supported
• 5.5 - 8 : Not supported
• 9 : Not supported (but has polyfill available)
• 10 : Partial support
• 11 : Partial support

Chrome for Android

Safari on ios.

• 3.2 - 5.1 : Not supported
• 6 - 10.2 : Not supported (but has polyfill available)
• 10.3 - 17.3 : Supported
• 17.5 : Supported

Samsung Internet

• 4 : Not supported (but has polyfill available)
• 5 : Not supported
• 6.2 - 23 : Supported
• 24 : Supported
• all : Not supported

Opera Mobile

• 10 - 12.1 : Not supported
• 80 : Supported

UC Browser for Android

• 15.5 : Supported

Android Browser

• 2.1 - 4.1 : Not supported
• 4.2 - 4.4.4 : Not supported (but has polyfill available)

Firefox for Android

• 14.9 : Supported

Baidu Browser

• 13.52 : Supported

KaiOS Browser

• 2.5 : Supported
• 3 : Supported

See also support for subgrids

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.

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>

Instantly share code, notes, and snippets.

peter-mouland / product-card--safari.css

• Download ZIP
• Star 0 You must be signed in to star a gist
• Fork 0 You must be signed in to fork a gist
• Embed Embed this gist in your website.
• Share Copy sharable link for this gist.
• Clone via HTTPS Clone using the web URL.
• Learn more about clone URLs
• Save peter-mouland/383fbe32972d1ca576e412db899db104 to your computer and use it in GitHub Desktop.

Safari 14.1 Adds Support for Flexbox Gaps

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.