postcss
Add Option to only allow Grid in IE by using Areas or Autoplacement Algorithms
Support of Grid for IE is hard to guarantee since it does not support auto placement. Autoprefixer can ensure support when either autoplace mode is activated, or grid-template-areas are being used. The former is not applicable for all situations (e.g. the order should be different than in the DOM). The latter only works when grid-template-areas, grid-template-rows and grid-template-columns are provided in the same rule.
The problem is that when writing CSS that follows neither approach, IE compatibility might break silently. E.g. when not using areas but grid-column/row on child elements directly - which would be totally supported by IE, but only when not using auto placement for any child. PostCSS cannot check this, as it does not know anything about the DOM structure. So the safe way would be to dissallow it.
I would suggest to add an option that throws an error when using any css rule combination that does not enable the „areas“ or „autoplacement“ algorithms, and also when grid-column/row is encountered. Plus a control comment to opt out and use manual placement with grid-column/row on ones own risk. Combined with „Treat Warnings as Errors“ (#1165) this would enable a rather resilient backward compatibility with IE.
I think a new strict setting would be good.
// same as grid: true but only allows Grid if grid-areas is used
autoprefixer({grid: true, strict: "grid"})
// same as grid: "autoplace" but only allows Grid if grid-areas or autoplacement is used
autoprefixer({grid:"autoplace", strict: "grid"})
By splitting strict off into a seperate setting, it means that there is potential to also use strict for other forms of translation in future that don't exist yet.
I originally thought of having "strict" and "strict-autoplace" grid settings but it would get messy when it comes to control comments.
We want the control comments to clearly convey that they are disabling strict mode. My first thought was using alias settings like how grid: no-autoplace is an alias for grid: on but I think that is a bit convoluted.
For control comments, I think the strictness should inherit the autoplacement setting rather than override the setting.
/* autoprefixer grid: autoplace */
/* autoprefixer strict: grid */
/* warning triggered */
.strict-grid-error {
display: grid;
}
/* no warning */
.relaxed-grid {
/* autoprefixer strict: off */
display: grid;
}
Why not grid: strict?
Because I was over thinking it 😅
If we do go with {grid:"strict"} we should also provide {grid:"strict-autoplace"} so that people on old projects that aren't autoplacement compatible can still use strict mode.
There will need to be a new alias for grid: on
/* autoprefixer grid: non-strict */
=
/* autoprefixer grid: on */
I also thought of adding this alias:
/* autoprefixer grid: non-strict-autoplace */
=
/* autoprefixer grid: autoplace */
But if the user is explicitly turning off strict mode then they probably aren't interested in using the autoplacement algorithm so it is probably not worth implementing.
Ok so to clear things up:
// grid: on in strict mode
{grid:"strict"}
// grid: "autoplace" in strict mode
{grid:"strict-autoplace"}
// grid: on in strict mode
/* autoprefixer grid: strict */
// grid: on in normal mode
/* autoprefixer grid: non-strict */
// grid: "autoplace" in strict mode
/* autoprefixer grid: strict-autoplace */
I think those are all the things that are needed.
I don't think we need /* autoprefixer grid: non-strict-autoplace */ because if they are using autoplacement then they don't need to turn off strict mode.
Do we really need strict but not autoplace? I think we added autoplace just to avoid major bump.
The issue that @fabb has is that he is working on a project that is old and not autoplacement compatible.
If we make strict mode only available when autoplacement is enabled then it would prevent old code bases from adopting it.
If you want to use strict mode as a way of insentivising devs to upgrade their code base to be autoplacement compatible then that is another option. That would cut out the autoplacement specific rules. It wouldn't help @fabb and people like him though in the short term.
Actually my project is not so old 😅 The thing rather is that the order of elements can be changed with a prop on my react components (mainly if a label should appear before or after the content it labels). Since it might be view width dependent, changing the order of children in the DOM also isn‘t an option.
If we go down the path of insentivising devs to upgrade their code bases, then these would be the new changes needed:
// grid: "autoplace" in strict mode
{grid:"strict"}
// grid: autoplace in strict mode
/* autoprefixer grid: strict */
// grid: autoplace in normal mode
/* autoprefixer grid: non-strict */
If autoplacing and strict could only be activated together, I could still deactivate it both together using a control comment for regions where the autoplacing does the wrong thing. But then it would really be necessary to disallow grid-column/row outside these regions, otherwise the autoplacing itself can silently break stuff on IE, when it contradicts the manually set grid-column/row values.
The point of strict mode is to force people to use either the autoplacement algorithm or grid areas. If autoplacement is causing an issue then that means that you should be using grid areas.
Using grid areas will prevent the autoplacement algorithm from activating.
Or are you saying that this should equate to grid: on?
/* autoprefixer grid: non-strict */
Actually maybe that is better. If the user is turning off strict mode, it is signalling that they don't want to use autoplacement. Autoplacement can get in the way of manual placement so it makes sense to disable autoplacement when grid is set to non-strict in a control comment.
So these are the new commands:
// grid: "autoplace" in strict mode
{grid:"strict"}
// grid: autoplace in strict mode
/* autoprefixer grid: strict */
// grid: on in normal mode
/* autoprefixer grid: non-strict */
Autoplacement can get in the way of manual placement
Exactly.
The problem is that when grid-template-areas is not set, PostCSS cannot know if any child sets grid-column/row manually. So IMHO any grid-column/row statement is potentially unsafe and indicates a possible incompatibility with IE. That‘s why I would throw a warning on every grid-column/row declaration in strict mode (at least as long as IE is in the browsers). Except when deactivating strict mode with a control comment, because then the dev signals that s/he has thought about that exact case (and is hopefully using manual placement for all children).
@bogdan0083 could you take a look at this issue?
I would like to be able to mention this feature in my upcoming autoplacement article but it needs to be implemented for me to make mention of it.
@Dan503 I'm very busy this month, don't have time for Autoprefixer issues.
I might take a look at it in January though.
Sorry guys 😕.
I stumbled over a conceptual issue when thinking through „output a warning on every grid-column/row declaration in strict mode“. I have both an npm package and a main app module that both use Autoprefixer and css minification. That results in the Autoprefixer actually executing 2 times for the same css, the alteady transformed css of the package gets piped through Autoprefixer again in the (next.js based) client project because it packs it up into several chunks. Now when I would have a control comment somewhere in the npm package source code to silence a grid-column/row warning, it will work correctly while compiling the package, but this control comment will be removed due to minification. So now when I use that package in my client project, the Autoprefixer warning would pop up again.
The probably cleanest way would be to deactivate Autoprefixer for the imported css - which only works if the client package has configured Autoprefixer with the same browsers. I don‘t know yet how to configure webpack to not run Autoprefixer for the imported css, probably somehow inject control comments to it. It doesn‘t seem very practical though.
@fabb If someone has Autoprefixer running twice that is a problem with their config, not with Autoprefixer. Your use case is not Autoprefixer's concern.
@bogdan0083 That’s fine. It's the holiday season. I just wanted to flag this with you as the highest priority issue right now.
@Dan503 Yeah sure, but since I suggested the thing with the warning, Inwanted to add a warning for the suggestion 😉. Joke aside, since it seems to be a default setup of next.js to run PostCSS on imported css too, my suggestion might create more problems than solve.
