WordPress.org

Make WordPress Core

Opened 17 months ago

Last modified 9 months ago

#50627 new enhancement

CSS Build process: Consider removing autoprefixer from the source folder.

Reported by: youknowriad Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Build/Test Tools Keywords:
Focuses: css Cc:

Description

Right now, the CSS build process is a bit unclear to me. It seems like there's a precommit hook to apply postcss autoprefixer to the CSS fils in src folder. This results in "source code" and "built code" to be mixed together.

The issue becomes more apparent as we explore using new techologies list CSS custom properties. If we continue with the current setup it means we'd have to include in the source code both the CSS variables used, and the necessary fallback for IE11 (as CSS variables are not supported there). So whenever we want to change the value of the CSS variable, we'd have to update all the fallback values, diminishing the value of the CSS variable in the first place.

Autoprefixer and CSS Custom properties are the examples I have in mind right now, but this can be problematic for any similar CSS feature we'd be interested in.

I think we should consider only applying the PostCSS tweaks (autoprefixer) to the build folder only. The downside is that the source "css" files won't have the necessary fallbacks for legacy browsers but they will still continue to work in most recent browsers.

In an ideal world, source and dist are completely different but it's too soon for that as a lot of core developers still use the "src" folder.

Change History (2)

#1 @isabel_brison
9 months ago

So whenever we want to change the value of the CSS variable, we'd have to update all the fallback values, diminishing the value of the CSS variable in the first place.

Wouldn't we have to do that anyway? Unless there's a postcss processor that automatically adds fallback values, in which case we wouldn't need to change any fallbacks manually. (I don't know of any that do this without compiling the variables to static CSS, which kind of defeats the purpose of using variables in the first place.)

Another thing worth considering is if our main uses for postcss are IE-related, we may not need it for much longer: https://make.wordpress.org/core/2021/03/04/discussion-dropping-support-for-ie11/

#2 @youknowriad
9 months ago

My original thinking here is that we should remove any build step for the source folder and only keep the raw source in the src folder, any built files should be git ignored and only generated in CI and such.

For the CSS part (last I checked), we do build file and put them in the CSS folder, which means there's a cycle where the actual source files are not entirely written by hand, they are written and then modified using the build tool (and repeat).

Another thing worth considering is if our main uses for postcss are IE-related, we may not need it for much longer:

Yes, that's a good point unless we start writing using PostCss or Sass like we do in Gutenberg to ease maintenance in the future. (For instance to define mixins, variables....)

Note: See TracTickets for help on using tickets.