Switching to Full Post CSS ?

[gael-boyenval]

🚀 Styleguide feature request (this is more a discussion)

Description

A clear and concise description of the problem or missing capability... After discussing the subject of the compiler tool we should use for building our CSS files with our brésilien friends, it seem that our current solution is not totally in phase with their needs and culture. So I open a discussion here where everybody will be able to discuss the pros and cons of it. ### Describe the solution you'd like If you have a solution in mind, please describe it. I'm not sure that I understood everything well, but they would prefer to use postCSS only with either the cssnext option or a set of plugins with the same abilities. CSS next a set of PostCSS plugins that allow us to build CSS future syntaxe instead of using a preprocessor like SASS. not everything come with the future syntax of CSS that is already available in SASS, but this approach as a benefit, when your CSS syntax feature is supported by your users (like variables, mixing etc...), you just delete the related plugin and serve your CSS with the already supported syntax. ### Describe alternatives you've considered Have you considered any alternative solutions or workarounds? Right now, we use SCSS. Why ? - because it can be integrated in a POSTCSS pipeline as well (and it is the most common good setup I know), and BUs use either POSTCSS or SASS, or are open to any solution. So it seemed to be the best option for everybody - it's the most used option across the world with large community and is well documented. I encourage everybody to discuss it here, and tell us if you are ready to switch, and if it could be a good solution for you or not.

[gael-boyenval]

here I will maintain this tables, and I will add stuffs as we talk about it :

Pros and Cons for POSTCSS only switch (with cssnext-like implementation )

PROS	CONS
	you can't mimic CSS variables with PostCSS since it's precompiled and css variables are completely inherited, they are limited to the :root element
we don't need to wait for browser support to write future CSS
it's just CSS
	some stuffs are drafts and we are not even sure that they will be implemented in any browsers (like apply, that are unofficial drafts)
	we still "need"(?) functions, loops, mixins with parameters, variable objects etc
We would have a "pure" postcss pipeline, and no dependency to sass (witch is written in C++)
PostCSS is extensible, we can write our own plugins if needed, or just install the ones we need
regardless we still need postcss to do stuffs like auto prefixing, or stylelint (the only linter that lint preprocessors-like langage)
	as we may need SCSS-like features, we may rely on POSTCSS alternatives that may be less documented or less stables. This would require to document the basic syntaxe
	bigger learning curve for developers (not as well known as SCSS and )

[andreolvr]

you can't mimic CSS variables with PostCSS since it's precompiled and css variables are completely inherited, they are limited to the :root element

What kind of limitation would we have? Can you explain a little bit more about this point?

[andreolvr]

bigger learning curve for developers (not as well known as SCSS and )

But this approach is just pure CSS, why would this have a bigger learning curve?

[gael-boyenval]

@andreolvr related to css variables:

css variable are inherited :

:root {
    --var :  10px;
}
.context {
    --var :  16px;
}

.elem {
     font-size: var(--var)
}

<div class="elem">hello</div>
<div class="context">
    <div class="elem">world</div>
</div>

in real CSS, the elem with hello text would be set to 10px font-size and the one with world text would be 16px font-size.

post-css is incapable of doing that since it has no knowledge about the Dom. it's why postcss CSS variables are limited to the root element.

you can't declare localized variables

[gael-boyenval]

@andreolvr regarding the bigger learning curve: it is very clear that we will need preprocessors features like mixins, functions, loops and if/else statements, calculations. Not using that would get us 10 years back in term of technology.

The learning curve will be big because we will have to use on top of CSS level 4 specs (that are not very well known), other postcss plugins to accommodate the need for the preprocessor features we loose getting rid of SCSS. Those plugins have their own syntax and documentation that need to be learned.

[andreolvr]

@gael-boyenval

post-css is incapable of doing that since it has no knowledge about the Dom. it's why postcss CSS variables are limited to the root element. you can't declare localized variables

This plugin solve all these problems. And also allow us to create variables inside media queries, and I don't know if this is possible with SASS.

it is very clear that we will need preprocessors features like mixins, functions, loops and if/else statements, calculations. Not using that would get us 10 years back in term of technology.

I don't think so, we don't use such features in LMBR and i'm pretty sure we are not 10 years late.

Angular and Vue.js use pure CSS by default. CSS Modules, is a pretty recent approach and also use mainly pure CSS.

Can you explain more why you think not using these features is being 10 years late?

other postcss plugins to accommodate the need for the preprocessor features we loose getting rid of SCSS Those plugins have their own syntax and documentation that need to be learned.

That's not the idea, we just use only what is/will be in CSS.

[gael-boyenval]

@andreolvr :

About variables: what you show me about css variables is not the same, it work exactly like SCSS variables, not like CSS specification level 4 variables. Please look more closely at my exemple. I'm talking about cascading inheritance. a more precise one :

:root {
    --var :  10px;
}
.context {
    --var :  16px;
}

.elem {
     font-size: var(--var)
}

<div class="elem">I will be 10px with PostCSS and CSS4</div>
<div class="context">
    I will be 16px with PostCSS and CSS4
    <div class="elem">I will be 10px with PostCSS but 16px with CSS4</div>
</div>

About preprocessors features :

• no optioned mixins, that mean no class instantiation helpers, or utility generator, or any classes that you may not want to add to your bundle, but let the user instantiate in his environment. Like a grid/cell generator for exemple.
• no map-get, so impossible to create authorized values for a given property. (just an example)
• no customs warning or logs without if / else statements.
• no value computation dependending on the user configuration (ex: the value of the local REM)
• no calculation.calc() provide calculation, but client-side, witch is unnecessary in most of the cases. (why would you make the user do calculation if it's not related to his own unknown context)
• no DEV / PROD differences in code source if required etc...

I can go on for ages.

CSS will never replace completely Preprocessors since everything that it is doing is at execution time, and preprocessor is doing it only at compilation time. Many things can and should be done client side with modern CSS, but not everything.

Sure we can do without, but it is clear to me that we are loosing a lot of good things that css will never replace because of it's inherent execution environment.

About css modules: I personally never saw a serious project using css module without postCSS preprocessor-like syntaxes. And We are talking about a JS environment with a component based architecture that is built-in. It's not the case for all BUs. Plus many people are getting away from css modules for css-in-js solutions where javascript is providing the preprocessor features with more flexibility.

about using what will be in css: The problem is, you can't really know, since most of the replacements of preprocessors stuff may change of specs or even be abandoned. What if the behavior of the apply spec change ? It's a non-official spec with no guaranty that it will be implemented, and no guaranty that it will be implemented with the same behavior. You may need to change all the instances of apply in your code when it will be validated. Apply the the closest we can find off a mixin, and cannot take any parameters.

The things that are only specified today in CSS specs exist, are so much more advanced and with a guaranty of long term support stability in preprocessors for more than 10 years now...

[melanieanglardLMFR]

Hi everybody,

We don't currently have enough experience with postCSS versus SASS. We are interesting in testing postCSS for a long time, without going away from SASS. At LMFR, we are using a lot of preprocessor's features and don't see how to go on a full CSS use.

We're afraid of loosing the modularity brough by SASS... resulting in a huge increase of css weight in pages.

In fact, we are working with SASS for 6 months, our team's member doesn't have the same skills and capabilities on css, less or sass. We have to consider the learning curve with a lot of attention because we are a team of 20 members. We agree to use postCSS with Sass, and why not testing css-next instead of sass in a second time to prepare the next major design system's update.

[gael-boyenval]

Thank's @melanieanglardLMFR and @andreolvr it's good to have your feedback.

Discussing it, I personally think that :

• there is CSS4 features that we should not use because their behavior cannot be the same in a compiled environment as they are in the execution one and it is misleading to use this syntax if the expected behavior does not match the specs :

  • custom properties (CSS4 variables)
  • apply and set (because it rely on custom properties)
  • calc() expended with post-css (support seems good enough to use it directly in production code)

• we will need preprocessors features at least for variables, mixins, functions etc... and using sass seem to be the most well known option for all BUs, since it is fully compatible with postCSS

• but there is still a lot we can gain from a CSSnext approach, and definitively should use, when features behaviors are not tied to the execution environment (mostly syntactic sugar) :

  • Autoprefixer (obviously)
  • custom media queries
  • media queries ranges
  • image-set()
  • color functions (if required)
  • font-variant
  • all the cool pseudo-selectors

with Autoprefixer 9+ we may even be able to use css grids, with some constraints.

I encourage you to look at the cssnext features, as all his features are available as plugins for PostCSS

what do you say ?

[andreolvr]

@gael-boyenval Sorry for the late reply. I don't have much more to say. Personally, I still prefer the CSS approach, but what you said makes total sense. Thanks for explaining your opinion about the points I mentioned. :sunglasses:

[gael-boyenval]

For reference, here a PR for the PostCSS pipeline. It does not fully match what we've said here yet, but the idea is to make it available as a NPM package for everyone : https://github.com/adeo/design-system--styleguide/pull/73.