Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-grid] gap should autoprefix to grid-gap #1274

Open
Dan503 opened this issue Dec 26, 2019 · 11 comments
Open

[css-grid] gap should autoprefix to grid-gap #1274

Dan503 opened this issue Dec 26, 2019 · 11 comments

Comments

@Dan503
Copy link
Contributor

Dan503 commented Dec 26, 2019

In reference to this comment in the tailwind grid support pull request:
tailwindlabs/tailwindcss#1274 (comment)

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.

@Dan503
Copy link
Contributor Author

Dan503 commented Dec 26, 2019

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.

@ai
Copy link
Member

ai commented Dec 26, 2019

I'm not sure why Autoprefixer wouldn't support it.

Because Autoprefixer deals with vendor prefixes only.

@Dan503
Copy link
Contributor Author

Dan503 commented Dec 26, 2019

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.

@ai
Copy link
Member

ai commented Dec 26, 2019

  1. It will be inconsistency. If we will add gap, why we should not move postcss-preset-env?
  2. The current architecture is not ready for non-prefix.
  3. Warning with mentioning postcss-preset-env will work too.

@Dan503
Copy link
Contributor Author

Dan503 commented Dec 26, 2019

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.

@ai
Copy link
Member

ai commented Dec 26, 2019

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?

@Dan503
Copy link
Contributor Author

Dan503 commented Dec 26, 2019

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.

@adamwathan
Copy link

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.

@fschoenfeldt
Copy link

fschoenfeldt commented Jun 16, 2021

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.

@Dan503
Copy link
Contributor Author

Dan503 commented Jun 16, 2021

@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
Copy link

@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.

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-gap instead of gap because grid-gap is lower in the source order.

Good advice! I'll update my comment in case anyone wants to use this snippet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants