Support for display: grid; and its props would be swell.
We had originally planned to ship grid utilities, but it turns out browser support is still not there. In fact, grid in IE10/11 is a dumpster fire. At this point we only want to add utilities to Tailwind that can be safety used. Here is a comment from an earlier PR:
Hmm, tricky. I think our current approach makes a lot of sense. I see a ton of value in Tailwind only offering utilities that are practical to use given today's browser support. This is the exact same reason we're not including grid classes in the core right now. I could see things like grid being added as optional extensions (which is actually the plan), but not included in core until they have a sufficient amount of browser support.
One thing you can obviously do is create your own utilities if you want to use these. Check out this doc page for more info: https://tailwindcss.com/docs/adding-new-utilities
That said, we are planning to add an optional extension to Tailwind for grid for those living on the bleeding edge. Then, long term, that will likely be merged in and become part of Tailwind core.
I'd recommend simply using flex to build your grids at this point. It's wonderfully easy with the sizing helpers. For example, to create a three column grid with a gutter, you could do this:
<div class="flex flex-wrap -mx-4">
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
</div>
I think you mean <div class="flex flex-wrap -mx-4"> ;)
Cool...wouldn't mind contributing to a fork to figure that out.
Frig, yes, I'll update that. Been a long couple of days.
Yeah but who uses IE10/11? :)
@jackmcdade TOO MANY PEOPLE π
I must be delightfully isolated then, I haven't supported IE in years with Statamic and have had exactly zero complaints. Interesting!
Really eh? According to this website, IE usage is still at 6.72%. Depressing.

In my experience that's generally low enough on a product where you can say "We support the latest cross-platform browsers" and be fine. Those 6% are often not people who would ever be in the market for some of things we build.
Yeah I really think it comes down to who your target audience is.
Yep. And my target audience would enjoy some grid helpers. π
But honestly, wrapping that spec might be more work than it's worth. It's all container level stuff, and I think a single class with some rules is probably easier to manage than a string of utility classes with breakpoint modifiers.
Yeah, @adamwathan and I actually already have a pretty solid idea of how we want to implement. As mentioned, we wanted to ship it with alpha, but decided against it last minute (due to browser support). We will have this added soon, I promise Jack! β€οΈ
It's a perfectly reasonable thing to cut in an alpha. I support you guys. πΎ
I might just be an idiot, but how would i go about making a simple 3 column layout with margins around each column (gutter in bootstrap), without the last element being pushed to the next line?

Kinda unrelated to display: grid stuff, but check out the docs on Grid.

oh, with negative margins I see. thanks.
Didn't mean to derail the issue, my apologies.
The issue with using flex for grids (which let's be honest is hardly an issue, flex is amazing π), is that the margins are don't count as part of the columns. Meaning, you'll get 1/3 + 1/3 + 1/3 plus your margins, which is over 100%. This is causing the wrapping you're seeing.
As you've just noted, you just need to use negative margins and padding:
<div class="flex flex-wrap -mx-4">
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
<div class="w-1/3 px-4"></div>
</div>
Or you can nest your column stuff inside a wrapper with padding. Pick your poison.
Yep, totally, good point.
<div class="container mx-auto mt-4 p-4 bg-grey-light ">
<div class="flex flex-wrap font-mono -mx-2">
<div class="w-full md:w-1/3 sm:w-1/2 px-2">
<div class="bg-blue" style="height: 100px;">
I am a blue box inside of here
</div>
</div>
<div class="w-full md:w-1/3 sm:w-1/2 px-2">
<div class="bg-blue" style="height: 100px;">
I am a blue box inside of here
</div>
</div>
<div class="w-full md:w-1/3 sm:w-1/2 px-2">
<div class="bg-blue" style="height: 100px;">
I am a blue box inside of here
</div>
</div>
</div>
</div>
Produced the result i was expecting.
It'd be hard to do named rows/columns, but I guess you wouldn't need to if it's all inline?
Yet another thing held back by worrying about IE :(
Stats from 2 million (out of 1 billion total) websites based on page views is not something to go by.
Is there any way to use a prefix for outdated browsers, like we do for screen sizes?
@m1guelpf Auto-prefixer does prefix for grid in outdated browsers, but unfortunately IE is still a mess. It's using an old version of the grid spec, and has tons of features missing. To the point that it's no more useful than just using Flexbox, which has fantastic browser support.
@bbashy We plan to add grid before a 1.0 release. We left it out of alpha for two reasons:
The browser support problem. It's real. Maybe not for everyone's target audience. But for enough that we felt it was unwise to include. Here are recent stats from a SaaS app of mine:

We simply ran out of time. We didn't want to hold back the alpha release for it.
So, please hold tight, it's coming.
If people see things don't work in IE, they try another browser. It's simple. IE is not on mobiles, so no need to worry about that.
People won't change unless they're forced to. Stop supporting old browsers and that number will go down and others up.
People can't always try another browser. I've had some government clients who cannot install any other browser on their computers, so they are forced to use IE.
With Edge having full Grid support and it now being considered an evergreen browser, this should be much easier to deal with moving forward. However the reality is that not everyone has a choice to simply switch browsers.
Not sure why you'd be using this on a Gov site/software but that's true.
Doesn't have to be a Gov site, just one that would be accessible from their computer. Same goes with some private sector enterprise type companies as well. We do work for a local utility company and they are pretty much locked down, though they do have either Chrome or Firefox (can't remember at the moment) installed by default.
Okay folks, let's not turn this into a big browser compatibility discussion. There are obviously going to be varying opinions on this complex problem.
Point is, we're going to add grid at some point in the nearer future and leave this decision your hands. π€
I build sites for governments, big enterprise, big non profit, schools, and colleges, all of whom are stuck with old IE. Itβs not their fault and not under their control. IE 11 support is vital.
Oops I slipped in late. Sorry Jonathan. π
All good brother! β€οΈ
So excited for grid support and 0.2.0! @reinink I know it's not something devs enjoy being asked, but as I am planning to bring Tailwind to our team and our new stack, is there a roadmap or rough timeline for the 1.0 release? No pressure though! We'll definitely get going with the alpha :)
Also, just a consideration since we're still dealing with IE - I wonder if / where it makes sense with some overlap (I understand grid is NOT a replacement for flexbox),that by using grid utility classes, we also get feature queries that fallback to flex.
For example - https://codepen.io/primalivet/pen/ryjKmV
maybe it could be like -
.grid-class {
@supports (display: grid) {
`grid code`
}
`@apply flex classes`
}
With a giant caveat that it would only work for limited use-cases. If there is a mapping that is sensible for some base classes, that would still remove some work from doing fallback logic 100% manually.
You should still be able to use ms-grid, grid and flex combined with @supports.
taking the flex method for making grids... is there a way to make all divs in that list match the size of the first one? or the taller one ?
https://jsfiddle.net/4yw6ocv2/
Usually by just adding .flex-1 to each child.
Do you mean the heights? Better open a new issue.
@eduarguzher That's actually impossible with Flexbox unfortunately:
https://stackoverflow.com/questions/36004926/equal-height-rows-in-a-flex-container
...but can be done with CSS Grid apparently.
thank you for your answers guys, I think it is not a big problem for the case I have... was an interesting question/answer anyways
@reinink Can you elaborate how you would implement grid support?
I mean with the ability to use repeat and grid-template and etc, it would be a challenge to (fully) implement grid as a utility class.
what might be interesting (though not purely class driven) is to leverage CSS custom properties at the local scope level to pass in attributes that a class is expecting.

https://css-tricks.com/css-attr-function-got-nothin-custom-properties/
It could potentially let us pass in values from the markup to the CSS classes that expect a repeat value, etc.
Vars can just be defined in the root and are not supported by all browsers.
@DanielRuf yes, vars can be defined in the root, but if you want context-specific vars to pass configurations to your classes, you can override these root values per component.
As for them not being supported in all browsers, if you're using CSS Grids in the first place, this point is moot since CSS variables have the same browser support as the modern Grid implementation.
What about ms-grid?
You still need a fallback for vars.
I did say modern grid implementation, since pxwee commented on repeat and grid-template
Well, this would clearly drop IE11 support if no @supports and other declarations are used.
Foundation Sites has the same discussion about the next grid.
This brings us back to the first reply in this thread.
Right, I am not getting into the argument of whether to use grids or not. The optional extension for those living on the bleeding edge is still the right call. The burden of the choice is on the developer.
I'm only suggesting a class implementation that might be flexible (pass variables in the markup to the classes, to avoid having to write CSS one-offs classes for anything grid-specific).
we can still reliably use predefined classes and pass in custom values, as opposed to writing inline-styles.
Just my 2 cents, from a standing point of a back end developer, must-sometimes-be-a-front-end-guy for strictly application development. We do not do web sites.
I find grids very useful and use them everywhere lately. It feels natural, much more than flexbox.
But, I do not miss grid support in Tailwind as I see them like easy to transform<TABLE>. Grids (at least mine), serve a special purpose in an application and not two of them are alike. So, I define and style them locally and just @apply what I need.
Regarding the use of older browsers, I stand on moving on and politely ask my users to upgrade. I do provide an alternative styling for non-grid browsers which does not necessarily replicate the gridded one. Think of it as a stripped-down version of the app. They soon realise the potential in browser upgrade. BTW, it improves web security in general. You upgrade obsolete hardware, you upgrade obsolete OS, so please, just upgrade your browser or be limited. As you are in a case of old hardware or old OS. It's like asking Apple to make APFS working on Lion. Want new functions? Move on!
What I specially like about this product, and the principle behind it, is how is stays out of my way. I @apply heavily to keep my view files clean and generic. Combined with my styling, it is the best of both-worlds, namely using the frameworks and I'll-do-it-from-scratch approach. Kinda like writing your own Bootstrap or Foundation. Or Bulma. Or any popular framework.
Again, this is me and my use cases. I accept that it's different with web sites and wider browser support.
From my point of view, don't make too much of it right now. If grids don't make it into core, fine. If they do, also fine. I'll just PurgeCss and move on. :D
Purely for informational purposes, here's Rachel Andrew's recent post on browser support -
I agree with @pxwee5 that a lot of the complex functionality of CSS Grid Layout is probably not even all that possible to do with utility classes (particularly grid-template-areas). CSS Grid Layout very much probably stands on it's on as a whole separate thing I think. It's easily the most powerful addition to CSS ever added.
So for anyone really wanting to use CSS Grid now, and not have to worry about fallback support, if you are onto the awesomeness of PostCSS, then this PostCSS plugin both makes CSS Grid easier and has a pretty slick fallback support setup built in! And there's no reason you can't use this with Tailwind. What I love about Tailwind is it's so much more friendly and open to using regular (old school) class names in combination with utility classes.
I also agree. Any attempt at abstraction is going to leave somehting out or be as complex as the Grid itself. I was just looking at a set of Vue components and decided I'd rather just use Grid styles with Vue & Tailwind. As @onetrev says, it's good that plain old CSS works with Tailwind as well.
Though that pictorial PostCSS plugin is very nice indeed! :)
I am already using CSS Grid, writing this with Grid-Area-Templates. I have written a bigger Sass Mixin in which I translate the grid area templates for IE10 to Edge 15 is the first grid specification. Possible gaps are included in the calculation.
Advantage compared to the PostCSS plugin, it is only baked on spec 1, no absolutely positioned containers and no ASCII code images. You need a javascript to recognize IE10 - Edge 15 (bowser.js), so that the fallback runs, all other browsers use the current specification.
The browser support for CSS Grid looks really nice now
@reinink Any chance of showing an example gist of what you have already thought of for a grid file? I'm fine just loading it in myself but if you've already done a rough draft I'd be happy to just test it :D
There is a Tailwind plugin for CSS Grid, but it's an example of a plugin, not an official plugin, so I think subject to breaking changes: https://github.com/tailwindcss/plugin-examples/blob/master/plugins/css-grid/index.js
I've been using it for simple cases, and it works quite well!
Has anybody taken this up? What would it take to implement it?
Hey all,
Found this thread looking at TailwindCSS compatibility. I do a lot of work with fortune 500 - 100's companies internal web communications. IE usage averages 50 - 75%. Not Edge. IE. In the past year IE10+ is around 96 - 99% of the total IE usage so we're hoping to use more modern tools for these clients.
Just thought I'd throw it out there as, depending on your target audience, IE usage is alive and well. If your audience is in that world, you should consider those stats.
Hope it helps someone!
@filljoyner It's time to stop IE11 support, really. IE11 is ruining the web and we all know it.
Fortune 500 companies should have plenty of resources to update their legacy software to use the latest Windows machine and get on IE Edge.
Why are we trying to accommodate companies that are way richer the rest of the world combined is way beyond me.
Anyhow, this should be up to the dev using Tailwind, not Tailwind itself.
Being it a utility-first CSS framework for rapid UI development, CSS Grid support is a must.
@pxwee5 While I can appreciate your frustration as I too do not like dealing with IE, know my comment is informed from years of stats and experience in supporting these customers.
A principled stand is great and I'm not trying to steer this project in any direction. I just wanted to present another perspective where very large organizations aren't as nimble as leaner outfits and require a lot of time to securely adopt new tech.
I reached out to Adam about legacy grid system support (floats for days!) a few months back to get his thoughts. At the time he was working on the ability to extend Tailwind and suggested checking that out when it was released as I could bolt it on as an extension. I got busy and have yet had a chance to pursue.
It is great to know that Tailwinds has a system to extend though.
@filljoyner
This is no reason to not add it. Tailwind is a utility framework. It should be there as an option, so that people who DO want to use it CAN, and those that DON'T, don't have to...
Also, let's be honest, the only reason IE is even still remotely used is because for whatever reason, the trend emerged that web developers should be supporting every single browser, even if it's from 10 years ago. All this mindset does is halt progression and keeps people on bad technology.
Hypothetically, let's say every site in the world drops IE support and has a message saying βWe don't support IE, upgrade to Chrome/Firefox/etc...β
I guarantee 95% of them would upgrade no questions asked. What does this mean? They are running newer technology. This means they get a better experience using our websites, we get a better experience creating the website since we no-longer have to cater for a deprecated web browser, and overall (almost) everyone wins...
If this doesn't happen, then we are just going to be left attempting to cater for every web-browser under the sun (let's make our site work in netscape and mosaic!!!) instead of spending time doing what we should be doing, building the site and its functionality.
Anyway, regardless of my opinions above, it's still a fact that I'm sure everyone will agree that css-grid needs to be added. Even if it's just and offical (and updated) module/custom utility. So that people who WANT to use it, CAN.
This is no reason to not add it.
There were/are many reasons not to add it:
css-grid needs to be added. Even if it's just and offical (and updated) module/custom utility. So that people who WANT to use it, CAN.
You already can use CSS Grid though! π€¦ββοΈ We have tons of documentation on the site about extending Tailwind either by writing your own CSS or by writing a plugin. There is NOTHING stopping you from using CSS Grid, and me not writing the perfect CSS Grid plugin for you in my spare time for free and updating/maintaining it forever does not count as an obstacle.
DO ππ» IT ππ» YOUR ππ» SELF ππ» THAT'S ππ» WHY ππ» WE ππ» DID ππ» ALL ππ» THE ππ» WORK ππ» TO ππ» MAKE ππ» THE ππ» FRAMEWORK ππ» SO ππ» EASY ππ» TO ππ» EXTEND
We'll ship CSS Grid utilities by default eventually, until then please stop complaining about something that you can already EASILY do yourself, thanks to hundreds of hours of work I've done for you for free to give you all the documentation and functionality you need to extend the framework.
As someone using tailwind (in every project I possibly can!) and who also uses Grid whenever possible, I completely back up Adam's comments above. CSS Grid is so incredibly powerful _and_ succinct, how do you abstract that away into a few (or even many) classes? The dev who can capture the full power of Grid (like Adam said: and not just reimplement some flexbox capability) in an easy-to-grok list of classnames for quick usage would indeed be an incredible engineer. Not to mention, why do we need Grid? To center content in a div? To create some boring, static 4- or 6-column layout? Absolutely not. Grid gives us the ability to _in a few, short, carefully chosen lines of CSS_ take complete creative control of the _entire layout_ of the page/section. Grid defies frameworks.
Does a Grid plugin sound cool? Sure, we all love playing with new tools. But is it going to enhance our abilities with Grid itself? I sincerely doubt it.
@adamwathan
I apologise. I did not intend for my comment to come across as aggressive or to sound ungrateful for the work you have done.
Now that you have established other challenges with it, I completely understand. The thing that was frustrating me is just how people were using browser compatibility (for a single browser) as the ONLY argument.
I will start looking into extending tailwind as I've only ever used the base framework.
Again, apologies if my previous comment came across in a way I didn't intend it to.
Yeah but who uses IE10/11? :)
@jackmcdade
20% of Japan :smile:

Crazy, right?
IMHO it would be very useful to add support for CSSGrid in the form of an _official_ tailwind plugin (for instance, something like the vue and vue-router plugin).
Although tailwind does offer great flexibility to its users by allowing them to add more functionality in the form of plugins, the benefit of an official plugin is that the original values chosen for various grid properties (gap sizes, etc...) would be inline with the opinionated values chosen for tailwinds design system, ensuring a consistency with the tailwind defaults
Finally, as @tehpsalmist notes, it is really challenging to capture the full power of Grid in a list of classnames, however I think that it worth trying to come up with a basic solution that can be then enhanced by contributors
I would be very glad to be of any assistance in case the core team decide to procced with the development of this plugin
@adamwathan and tailwind members/contributors thank you for the work done :clap:
Yep, there is absolutely no sense in adding classes to handle grid.
Best shot would be plugin/directive, but at the end of the day... grid API is already straight forward, in this case, I can't imagine adding a layer of abstraction on top of it will make things easier.
I just wrote this comment to have an excuse to thank you for your great work.
For reference, BlueprintCSS by @coryrylan has still found some use for a set of utility classes around CSS Grid Layout https://blueprintcss.dev/docs/grid
https://blueprintcss.dev/docs/why-grids-and-utilities :eyes:
At that level with utilities, it is really a wrapping flexbox, but because of grid-gap it does have its appeal. Unfortunately, wide support for gap is still a long way down the road.
Implemented in v1.2.0.
Is align/justify-items/content supported for grids? I can only seem to find these properties in the documentation regarding to flex, but not grid.
These are flexbox relevant things, not CSS grid which is only for layout. Not for positioning contents and elements in general. CSS grid does not replace flexbox.
I understand CSS grid does not replace flexbox. But these properties are not only flexbox related. They also influence the CSS grid position in its container, and box placement inside a CSS grid cell.
The ones we include definitely work for both Flexbox and grid, all they do is set the properties π
.items-start {
align-items: flex-start;
}
.items-end {
align-items: flex-end;
}
.items-center {
align-items: center;
}
.items-baseline {
align-items: baseline;
}
.items-stretch {
align-items: stretch;
}
.self-auto {
align-self: auto;
}
.self-start {
align-self: flex-start;
}
.self-end {
align-self: flex-end;
}
.self-center {
align-self: center;
}
.self-stretch {
align-self: stretch;
}
.justify-start {
justify-content: flex-start;
}
.justify-end {
justify-content: flex-end;
}
.justify-center {
justify-content: center;
}
.justify-between {
justify-content: space-between;
}
.justify-around {
justify-content: space-around;
}
.justify-evenly {
justify-content: space-evenly;
}
.content-center {
align-content: center;
}
.content-start {
align-content: flex-start;
}
.content-end {
align-content: flex-end;
}
.content-between {
align-content: space-between;
}
.content-around {
align-content: space-around;
}
We are missing some though (justify-items, justify-self) and our *-start variations use flex-start not just start, so the behavior might be slightly different than you want in some cases.
Yes, it was the justify-items that I was missing.
Maybe the flex- prefix could be fixed if the generated css looked like
.flex.items-start {
align-items: flex-start;
}
.grid.items-start {
align-items: start;
}
Would you consider adding this? If so, I will be happy to create a pull request for this
After giving this some more thought, I think the best solution are class utilities like:
{content|items|self}-{x|y}-{start|center|stretch|...}
I have created a plugin for this tailwindcss-grid-placement
This does avoid the problem of flex-start vs start and provides complete control over the grid and its' items.
@adamwathan If you would like a PR for this, just let me know
Thanks @subhero24! These are definitely necessary for full grid control.
Most helpful comment
There were/are many reasons not to add it:
You already can use CSS Grid though! π€¦ββοΈ We have tons of documentation on the site about extending Tailwind either by writing your own CSS or by writing a plugin. There is NOTHING stopping you from using CSS Grid, and me not writing the perfect CSS Grid plugin for you in my spare time for free and updating/maintaining it forever does not count as an obstacle.
DO ππ» IT ππ» YOUR ππ» SELF ππ» THAT'S ππ» WHY ππ» WE ππ» DID ππ» ALL ππ» THE ππ» WORK ππ» TO ππ» MAKE ππ» THE ππ» FRAMEWORK ππ» SO ππ» EASY ππ» TO ππ» EXTEND
We'll ship CSS Grid utilities by default eventually, until then please stop complaining about something that you can already EASILY do yourself, thanks to hundreds of hours of work I've done for you for free to give you all the documentation and functionality you need to extend the framework.