Header/Footer: Modularize CSS files and process with PostCSS. #6
Conversation
The contents will soon become too much to keep in a single file, and it's easier to separate while it's still small. PostCSS has most of the features of SASS, but is more future-proof.
|
What do you think makes PostCSS more future-proof? From a package dependency perspective, it looks like this PostCSS config has 8 dependencies, whereas the Sass setup in |
|
my understanding is that postcss is basically polyfilling future official css features, while sass is a custom thing. e.g., w/ a sass plugin you can use variables inside media queries, but postcss instead supports custom media queries also informed by this discussion: WordPress/gutenberg#14801 (comment) |
|
passer-by comment: PostCSS is pretty minimal, and you only opt into the features you need, that's why there are more deps for a PostCSS config. Usually you can find PostCSS plugins following official spec proposals, so at some point when browsers support that spec, you could remove the plugin and everything will keep working. If that's a feature you want, you'll need to check each plugin though - I see you've got It's also fairly straightforward to write small PostCSS plugins (maybe? I've written a few at this point so I'm probably biased), which can be used as helpers to do things like cleanup, format values, etc. Definitely an edge case but it's come in handy before. Those can be in the same codebase as the config, and used without needing to release a npm plugin or anything. |
|
great catch, switched to |
|
agreed, i opened WordPress/wporg-parent-2021#1 to track that, but am ambivalent about when to do it |
while working on WordPress/wporg-news-2021#28, the single
style.cssfile has become unwieldy, and at this point the the benefits of preprocessing now outweigh the pain of tooling IMO.it's easier to separate the files before that PR is merged
PostCSS has most of the features of SASS, but is more future-proof.