SASS or CSS, let's decide here

[ianbelanger79]

As per the slack discussion in the Twenty Nineteen kickoff meeting. We need to decide to use either SASS or plain CSS. Make your case

[CalumChilds]

CSS. It's the result of SASS anyway, so why put barriers up for no reason?

[gregrickaby]

Sass.

Let's use modern development practices and let the compiler deal with sorting, prefixing, sniffs, and all the other amazing optimization benefits that can help make shipping this (under a tight deadline) easier.

The barrier to entry can be as low as npm i and gulp

[fabiankaegy]

Because of the nature Themes that include Editor Styles for Gutenberg there need to bee two separate stylesheets inside the theme folder. Both of them will have to share a lot of code in order to get the wanted experience. Having to maintain two similar codebases will result in differences and errors.

If there is a well documented way of on boarding people to use sass that would make it way more maintainable.

[asharirfan]

I think Sass is the way to go because it makes the code more maintainable. We will also be able to automate the prefixing and other minor tasks related to CSS 💯

For the beginners, the process can be documented in the readme file to get them started.

[mor10]

As per #34, if Sass is selected, a unified build process should be included in the theme to ensure consistency. The /sass/ folder is aggressively modularized making it hard for people now familiar with Sass processing to understand exactly how to wire things together.

[mor10]

That said, I vote for no Sass. In my view, syncing styles between front and back end is not sufficient reason to use an abstraction layer for CSS.

[joyously]

Default themes are used as examples and many people create child themes for them for their site customization. I advocate CSS for the ease of use for the end user, not anything to do with development now.
Modern development: a compiler isn't modern, it's a crutch.
Editor stylesheet: Gutenberg is nothing new in this area. All themes supporting editor styles have a separate editor stylesheet. The question here is are we supplying a stylesheet for the Classic Editor also?
Maintainable: plain CSS is more easily maintained, no compiler needed, single file.
All of the arguments for SASS are for the development now. None are for the end users, who are the least likely to have the knowledge or inclination to use SASS.

What is going to be in the zip file that gets stored in the theme repository?

There are ways to get the benefits of a compiler without the compiler. One is a small javascript that does prefixing automatically. Another that works with it is a polyfill for CSS Custom Properties. With these, nothing else is needed.

[tarikhamilton]

*Sass

Sass is going out of vogue due to CSS variables, but having a bunch of smaller partial files is 💯 x better for organizing.

Compromise: include a scss or sass folder, build the project that way, but don't minify the CSS file, so people are free to edit CSS or venture into the SCSS files.

And building can be done through webpack, as WordPress already uses it.

[mharis]

@tarikhamilton's suggestion is a logical compromise. Not really a compromise but a solution!

[joyously]

How does "Sass is going out of vogue" mesh with "build the project with a sass folder"?
There needs to be a non-minified version of the CSS in the end product. That is part of the Theme Requirements (for review) and GPL (readable source code). Why have something going out of vogue when it isn't needed?
And just because WordPress is using webpack doesn't mean end users are. A theme is so simple, it shouldn't need building.

[fabiankaegy]

@joyously I agree that there were editor stiles before Gutenberg. But whey were minimal compared to the amount of customisation you need in order to achieve the Gutenberg goal of having the backend looking very much like the frontend content.

[mharis]

@joyously The end result can be non-minified which is a good solution for people who would want to customize the CSS directly without executing the build process. That will be simple enough for a developer who wouldn't want to deal with build process issues.

[tarikhamilton]

@joyously in regards to Sass going out of vogue, but still suggesting a sass folder: Sass is becoming less necessary with component-based front-ends, but those also require build tools. If we wanted minimum build tools, Sass would be the easiest way to get modularity, which is a good development practice. All you would need is node-sass.

I'm ultimately advocating for Sass, but suggesting to not minify the output. It's basically 2017 theme, but with an optional Sass folder that you can build from, if you wish. The output CSS file can be made to resemble 2017's style.css file, so it is friendly to use.

Also, webpack wouldn't require it to be built to use. The built files can be distributed with the theme, so it'd only be for development and it'd only require a single command for use; no future configuring necessary.

[joyously]

What modularity is needed? You can enqueue multiple stylesheets. The guys advocating inline styles for performance probably won't like that, though. I'm not sure what's wrong with one style file. It definitely makes the cascade more obvious for debugging CSS issues.

If you have Sass for development, it will need to be part of the zip file, as that is what is stored in the theme repository, so any future fixes need the whole thing. I would prefer to keep the zip as light as possible, and no build needed now or in the future.

[mharis]

@joyously Performance issues comes with enqueuing multiple stylesheets.

I don't think Sass files bundled within the theme zip file is a huge issue, even dev tooling.

Moving towards a modern toolset shows improvement, it's not a crutch for end users. It only improves the overall experience by standardizing and optimizing resources.

[swissspidy]

What can Sass do what you can't do with PostCSS? And which of these features are actually needed for this theme?

[paaljoachim]

SASS or CSS is not really the point as I see it.

Bottom line who is the theme created for? Who will likely use it?
What is a core theme mainly used for?

I see core themes as a way to learn best practice used in the general WordPress community with all levels of knowledge. Are we trying to keep things at the level of beginner, intermediate or advanced? Or perhaps a mix of all of them.

One way is to keep things simple. Then include documentation of how to make it more advanced.
It becomes more difficult if one does the opposite (an advanced core theme with documentation for how to make it simpler).
It is easier for someone at an advanced level to use documentation to make the theme more advanced then it is for a beginner to adjust code to make it easier to understand.

Bottom line is lets teach people how to use TwentyNinteen core theme code and Gutenbergs various features in a simple as possible way and then have documentation that shows intermediate and advanced methods.

[fabiankaegy]

How should we go about deciding this. I don't want to rush this decision, but it would be helpful to either include instructions for the build system or start refactoring for just plain css.

And especially with the very short timeline for twenty nineteen in general we probably shouldn't wait too long.

Any thoughts?

[CalumChilds]

We settle it with a poll.

[paaljoachim]

A poll really says nothing. Only personal preference.
Lets look at advantages and disadvantages of both methods and have a closer discussion about it. Perhaps even make a post on make core in regards to getting community feedback.

[joyously]

One more reason not to use Sass: #73

[chrisblakley]

I just stumbled across this post and for what my thoughts are worth I would lean towards Sass, but if it requires anything outside of WP Core (including Gutenberg) or the theme itself to compile, then I would put a hard "no" against it. Even if it's super easy for a user to implement a Sass compiler, it is still a non-0 hurdle to get over.

I think WordPress default themes would be a great way to introduce people to Sass- especially since raw CSS can still be written in Sass (and perhaps it could be implemented in a way that writing directly to the style.css file would override any Sass compilations). But I also think that core WordPress themes should not have any barriers to getting functionality to work- WordPress has proliferated because it does not require additional functionality that is not already installed on most servers.

[colorful-tones]

CSS (with PostCSS) - so we can write the latest CSS (nesting, variables).

Let’s also keep in mind that minifying into a single file isn’t the best performance. HTTP2 and multiplexing is gaining momentum, which allows us to load many smaller files when we need, and not necessarily everything, all the time, and all at once.

[briannaorg]

Functionally, we are already using Sass, but without the benefits of additional tooling like Stylelint or PostCSS - as an example, I compiled with a fresh install of node-sass before making a pull request and style.css has been stripped of all quotes, which does not match the master branch. It would be nice if we had Stylelint or PostCSS handling formatting in a uniform way, as well as documented guidelines on whether or not to compile before making a PR. At any rate, I vote Sass, because it's already in master so it seems like that decision has been made, but I think some slight additional post processing would be helpful.

[briannaorg]

Any thoughts?

It would be handy if CONTRIBUTOR.md were updated with instructions for the existing Sass usage (ie, use node-sass, example commands, use X for linting) while this decision is being made).

[allancole]

Thanks for all the feedback, everyone. To summarize some of what's been discussed:

CSS:

• Is widely understood, easy to pick up.
• Is traditionally used for themes.
• Does not require a build process — it works out of the box.

Sass:

• Would allow us to more easily share code between multiple stylesheets (style.css, style-editor.css, etc.).
• Has the benefit of better code organization via partial files.
• Can automate prefixing and other small typical tasks.
• Would allow us to integrate tools like Stylelint or PostCSS, to result in cleaner code.
• Requires a build process.

Ultimately, the theme should move forward with Sass.

Sass might seem scary for those who haven't written it before, but it accepts standard CSS — it is designed to be readable and writable by those who already know CSS.

Sass can (and should) produce readable, non-minified CSS. If someone wants to customize the theme on their own, they can edit this plain CSS file directly. Sass is not required for child themes. Child themes will extend the the compiled CSS files, so child theme authors can use whatever method they choose. Our decision here is only prescriptive for the core development of the Twenty Nineteen theme itself.

It's also worth noting that Gutenberg uses Sass extensively. Using Sass here will help developers move back and forth between theme development and Gutenberg development without adapting to drastically different setups. If theme authors learn Sass, that'll help prepare them for Gutenberg development as well.

To use Sass effectively, we need two things:

1. A shared build process. This needs to be simple, standard, and require few dependencies. People should be able to get this up and running with little configuration. Based on our research to date, it sounds like a npm / node-sass approach will be the easiest solution for us. We considered grunt and webpack but ultimately landed on npm because WordPress core will drop support for grunt in the near future and webpack seemed too robust when we only need to compile a few .scss files.
2. Documentation. Initially, this would just describe the build process and should be part of CONTRIBUTING.md. It should then expand to explain best practices towards leveraging Sass for both front-end and editor styles without duplicating code. (We can track this in Document Sass compilation, editor style syncing #31)

To get the ball rolling on this, there’s a PR that lays down the foundation for the tool here: #169 It still needs a bit more work before merging into master, so I’ll leave comments on the PR with details on whats missing.

Thanks again for the discussion and debate.

[joyously]

I don't agree with your summary, but oh well.
Does this mean that the zip file I download from GitHub will have the correct CSS?

Once the theme is in the repository, will it still have the Sass files?

[colorful-tones]

Sass:

• Would allow us to more easily share code between multiple stylesheets (style.css, style-editor.css, etc.).
• Has the benefit of better code organization via partial files.
• Can automate prefixing and other small typical tasks.
• Would allow us to integrate tools like Stylelint or PostCSS, to result in cleaner code.
• Requires a build process.

Actually, there is a fundamental misunderstanding, because all the reasons you summarize that make Sass beneficial are fully available as CSS with PostCSS.

This is quite disconcerting.

[emeaguiar]

Nowadays CSS alone is almost as powerful as Sass, it would be good if developers start to move away from Sass and start using CSS + PostCSS.

It keeps the code clean, understandable. Plus, as mentioned in the comments above, the features mentioned for the use of Sass are already available in CSS, and they're here to stay. So there's really no point anymore.

[colorful-tones]

There is some antiquated misinformation being disseminated. Sass is no longer considered “modern”. Since CSS is capable of nesting, @imports, variables.

Also, concatenation and minifying to a single style.css is no longer best performance (HTTP2, multiplexing).

I’m not necessarily advocating that TwentyNineteen must have the latest modern tooling, but I am advocating for awareness of what is currently possible.

Some further reading:

• “Performance Best Practices in the HTTP/2 Era” / Delicious Brains
• “Introduction to HTTP/2” / Google Web Fundamentals
• postcss-import
• postcss-nesting
• “Using CSS custom properties (variables)” / MDN Web Docs

[kjellr]

@emeaguiar + @colorful-tones: I thoroughly appreciate the feedback and education you're both offering on this. The awareness you're raising is essential to help bring WP into the future. 🙌

Regarding the decision around Sass, I'd like to note that another important factor that was taken into consideration was time. As you know, the repo was originally built using Sass. Switching away from Sass would likely inject some level of unknown into our timeline: Would we need to refactor parts of the code that wouldn't otherwise need to be touched? Would switching away speed us up? Or slow us down?

Judging by many of the the comments above, and by the ~100 PRs we've had in just two days, our use of Sass hasn't slowed down development considerably thus far. Given that we have just a month now to get the theme finished and merged into Core, it's essential for us to keep this momentum up.

Aside from that: as noted above, we're following the lead of Gutenberg here. Gutenberg uses Sass, so there's precedent to follow that path too. This doesn't mean the next default theme won't use CSS/PostCSS, but for now in this moment, Sass seemed to be the best path forward.

Thanks again for your feedback, and for the links you've shared. I suggest we all read up so that we can continue pushing the web forward.

[ianbelanger79]

Personally, I don't see the benefits of using SASS, outweighing the learning curve for theme developers who are used to plain CSS.

That being said, maybe we could have 2 versions of the theme available:

• One with the stylesheet already complied into style.css, with no SASS files
• Another which has the SASS files un-compiled and all of the necessary tooling needed to compile them

IMO, I would prefer the theme not use SASS

[allancole]

Really, appreciate all the valuable feedback here!

I do understand that a lot of folks want to use just plain CSS. Sass already accepts plain CSS syntax, so the learning curve is already very low when it comes to adding styles to .scss files. There is a relatively light learning curve that comes from the build tool and we’ll be providing instructions on how to install and setup shortly.

Ultimately, we want to keep things moving forward so we can make sure this thing makes it into 5.0 ;-)

I’m gonna go ahead and close this ticket but keep an eye on #169 and #31 for details on how the build tool will work.