Modularize CSS

[iamkunaldesai]

In the era of HTTP/2 it is better to have multiple smaller CSS than a One big one.

Current CSS can be divided into 3-4 parts.

Here the print css can be added seperately which will load only if you print the webpage.

Just suggesting.

[nickcernis]

Thank you for this feedback, @iamkunaldesai.

We would like to modularize the CSS too. I'll leave this issue open as a placeholder for that future work, and to discuss the strategy here before the implementation is done.

[nickcernis]

Questions I have about the basic implementation of this that anyone reading is free to contribute answers to:

1. What CSS system should we use and why? Candidates are:

• Sass
• PostCSS
• Plain CSS but with newer features with a baseline for browser support, such as CSS variables; this may require PostCSS to polyfill for older browsers for now, but seems more future-friendly. (https://hospodarets.com/you-might-not-need-a-css-preprocessor/ )

2. Do we release Genesis Sample in two flavors (the “modular CSS version” and the “compiled style.css” version, albeit with better names)?

3. If Genesis Sample has dual versions, what needs to change to communicate that a developer and non-developer version is available?

4. Will this change alienate a core Genesis demographic? (I am thinking of users who have expressed a desire for Genesis Sample to stay simple; those who were vocal about the change made with the configuration API where code was pulled out of functions.php into the config folder, for example.) If so, what can we do to reduce the impact?

5. Should we continue to load CSS as one stylesheet, or split it via a modular loading API or block styles?

6. Should stylesheets live in their own styles directory, or does it make sense for any of them to live in the config directory? (Since basic font and color styling is really configuration.)

7. What is our strategy to sync block styling on the front and back end?

Once we have some opinions on these, the next steps would be to:

• Adjust existing npm build scripts and tooling.
• Make any changes required in Genesis to facilitate modular loading if needed.
• Start extracting repeated code and styling configuration into variables.

[jb510]

Great summary @nickcernis !

As a small agency building a lot of custom themes over the years we having explored a lot of this territory and I've got opinions.

1. What CSS system should we use and why? Sass, PostCSS, Plain CSS w/ features

¯_(ツ)_/¯

We're 100% SCSS. I'd be totally fine with moving to PostCSS or PlainCSS+Features. As much as this is about neatly modularizing the files, for me the far more important part to get right is the build script. (specifically running it through autoprefixer and building a css sourcemap).

Hence I'm not concerned about which pre-css language, but rather that whatever the build process is, it allows folks to easily swap between them.

I'm confident whatever is chosen, someone outside will maintain a forked version converted to their preferred style. Converting the CSS and their plugins/mixins/etc... is generally not difficult until you get into very advanced and complex approaches that I wouldn't expect in sample.

2. Do we release Genesis Sample in two flavors (the “modular CSS version” and the “compiled style.css” version, albeit with better names)?

No. I think we should just give users the option to use source files or the compiled files as a starting point, but they should always be modularized.

For the former we'd just give users the intructions: "If you do not wish to use the build tools / modularized CSS as a starting point you can safely delete the /scss folder (/assets, etc...), and then use the following css files as your starting point.

An important question becomes, do you use style.css at all?

• Is style.css dynamically built or static?
• If dynamic, does the header comment block get programatic built (we pull from package.json) or is it static text in a scss file?

3. If Genesis Sample has dual versions, what needs to change to communicate that a developer and non-developer version is available?

Per above, I'd communicate to the developer how to ignore/remove, heck concatenate if they wish, the modular content but I wouldn't maintain two versions.

Part of the goal of Genesis Sample is to teach, so teach rather than try to accommodate every need.

4. Will this change alienate a core Genesis demographic? (I am thinking of users who have expressed a desire for Genesis Sample to stay simple; those who were vocal about the change made with the configuration API where code was pulled out of functions.php into the config folder, for example.) If so, what can we do to reduce the impact?

Per above, invest more energy in teaching them how to tweak sample (and not just for this).

We still run across sites built by others where the theme NAME is "Genesis Sample"... In some cases people using sample don't even know how to rename a theme!

5. Should we continue to load CSS as one stylesheet, or split it via a modular loading API or block styles?

100% Modular loading.

I think Tadlock's article is the best (in terms of discussing the topic, not necessary in advocating the best solution), but Yoast (Jono) did some writing on the topic of modular css

How far to go with that I don't have an answer to though. ie. main.css, sidebar.css, footer.css... or all the way to individual blocks like some advocate. I will say @billerickson turned me onto having a single blocks.css file that could be loaded back (same for editor-style.css) and front end and that's been awesome.

6. Should stylesheets live in their own styles directory, or does it make sense for any of them to live in the config directory? (Since basic font and color styling is really configuration.)
   Config would confusing the heck out of me... and I definitely would not add them to the theme root directly.

We usually do:
theme_name/src/scss
compiled to:
theme_name/css

We've organized it lotsof different ways though, I guess the next most often is:
theme_name/assets/scss
compiled to:
theme_name/assets/css

That's kind of nice if you're pulling assets (npm/bower/composer) into your destination directory and not processing them. More likely JS than CSS, but same idea.

7. What is our strategy to sync block styling on the front and back end?

See above... Load the exact same CSS file on the front end and block editor.

[jonschr]

This is the main reason I have a custom starter theme based on sample rather than just using sample directly – I'm not willing to reorganize the css and spit it into more manageable files every time I spin up a new site. I'm doing this to better use sass, not because I want to load more files for load speed. I'd love to see scss/sass used, ideally with a build process in place for it.

There are three types of css files that need to be loaded:

• Frontend only (includes everything outside the .entry-content area)
• Frontend AND backend (block styles, typographical styles, etc., which can be automatically prepended, and for which we're just using the same components on the frontend and on the backend). This should be mostly contained in individual files for each block that's being styled, and named for that block.
• Backend only (styles that apply on specific content types which can't be automatically prepended with the editor wrapper class, since they apply only on certain parts of the site). I think there are a few styles like this in Genesis, but this is a much smaller group than the other two.

Really, though, those three categories only apply to the component files. The compiled files should generally either be loaded on the frontend or the backend, not on both (some component files can be @included into both the frontend and backend files).

I'd also love to see different organization of css: I think the media-queries file/chunk of code isn't the ideal way to handle media queries. I'd rather see that done inline, so that if you're looking at how the sidebar should style on mobile, you'd look to _sidebar.scss and not to media-queries, since that's a more logical place to look.

Will this change alienate a core Genesis demographic?

As long as it compiles down to css (and not postCSS or something like that), I don't know why it would affect the average user at all in that way.

An important question becomes, do you use style.css at all?

In my own themes, style.css is blank, and I compile everything else into a frontend and into a backend file. I don't know why I do it that way, though. I have a global.scss file that's the first thing to load in all of the individual scss files so that color variables, media query includes, etc. are being loaded consistently in both the frontend and backend files.

Anyway, just saw this and got excited about it and thought I'd share some of my own practices in case they spark any useful ideas.

[ghost]

definitely Sass

the current theme has a lot of bugs in the CSS

[timothyjensen]

I'd like to add my opinion in response to @nickcernis points above:

1. Use SASS. SASS is the preferred choice of many devs, including several commenters in this issue.
2. Maintain a single "flavor" of Genesis Sample. The theme can be released with compiled style sheets so that developers can continue to edit *.css files as usual. However, the theme will also have SCSS files to give developers the choice of editing the partials versus CSS files directly.
3. Same as above.
4. I think this change will actually encourage more developers to use Genesis Sample; developers who are accustomed editing CSS can still do so, and developers who have been waiting for SCSS partials will now have what they have been asking for.
5. I don't have a strong opinion here.
6. I don't have a strong opinion here, but I normally put my style sheets in /assets/css/.
7. Syncing block styles should be far easier when the styles are broken into partials.