[css-grid] gap should autoprefix to grid-gap
In reference to this comment in the tailwind grid support pull request: https://github.com/tailwindcss/tailwindcss/pull/1274#issuecomment-568920481
I think autoprefixer should translate gap to grid-gap.
Note that this should happen even if the grid prefixing setting is set to false since this is not an IE Grid compatibility issue. It is a modern CSS Grid issue.
Input CSS:
.gap-20 {
gap: 20px;
}
Expected output:
.gap-20 {
grid-gap: 20px;
gap: 20px;
}
Current output:
.gap-20 {
gap: 20px;
}
grid-gap is essentially just a prefixed version of gap now, so I'm not sure why Autoprefixer wouldn't support it.
Autoprefixer should detect caniuse data for the gap property and display: grid
If the browser does not support display: grid then prefixing is not required.
If the browser supports gap then prefixing is not required.
If the browser supports display: grid but does not support gap then prefixing is required.
I'm not sure why Autoprefixer wouldn't support it.
Because Autoprefixer deals with vendor prefixes only.
What harm does it do to include support for this?
This is essentially a standardised vendor prefix. There isn't really much difference between this and something like -webkit-something.
Adding support for this makes the lives of developers and library authors easier and leads to less kilobytes being downloaded by users since autoprefixer can only apply it when it is needed.
- It will be inconsistency. If we will add
gap, why we should not movepostcss-preset-env? - The current architecture is not ready for non-prefix.
- Warning with mentioning
postcss-preset-envwill work too.
I guess a warning is better than nothing.
It at least gives users direction in terms of what they should do for the best browser support.
OK. If we found gap: without grid-gap:, but some of prefixes do not support gap, we show a warning about postcss-preset-env. Right?
Yeah basically.
If gap is found but not grid-gap, and there are browsers on the browserslist config that support grid-gap but not gap then produce a warning that directs users to postcss-preset-env.
Just throwing in my two cents here, I'm surprised this is out of scope for autoprefixer but the complex IE11 grid polyfill stuff is fair game. Feels like that should definitely be moved to postcss-preset-env this transformation belongs there too.
So for now we would write:
Input CSS:
/* autoprefixer grid: autoplace */
.my_grid {
display: grid;
grid-template-columns: 1fr 1fr;
grid-gap: 1rem;
gap: 1rem;
}
which will transform into:
.my_grid {
display: -ms-grid;
display: grid;
-ms-grid-columns: 1fr 1rem 1fr;
grid-template-columns: 1fr 1fr;
grid-gap: 1rem;
gap: 1rem;
}
Which, at the end of the day, feels like prefixing. But anyway, it works for me.
@fschoenfeldt if you are only using it for CSS grid it is maybe not worth writing the gap version at all since grid-gap works everywhere that gap does but gap does not work everywhere that grid-gap does.
Also, if you are going to add both manually, you should write the outdated one above the newer one so that the newer one takes priority in the browsers that support it. The way you wrote it, all browsers that support grid will use grid-gap instead of gap because grid-gap is lower in the source order.
@fschoenfeldt if you are only using it for CSS grid it is maybe not worth writing the
gapversion at all sincegrid-gapworks everywhere thatgapdoes butgapdoes not work everywhere thatgrid-gapdoes.
VSCode hints me that usage of grid-gap is discouraged because it's outdated. I feel like I'm better safe than sorry using both properties.
Also, if you are going to add both manually, you should write the outdated one above the newer one so that the newer one takes priority in the browsers that support it. The way you wrote it, all browsers that support grid will use
grid-gapinstead ofgapbecausegrid-gapis lower in the source order.
Good advice! I'll update my comment in case anyone wants to use this snippet.