Twenty-Twenty Three Theme updates and Site Wide CSS Editor

The application of parent and child CSS takes advantage of cascading precedence. For equivalent rules, the one loaded last takes precedence. Parent styles are loaded before child, so child takes precedence.

What part of the CSS editor are you questioning? There are overall styles, block styles, and additional CSS. Access additional CSS through the 3 dot icon of the Styles sidebar. Actually, it may not matter, I think the answer is the same anyway. The part I’m sure about is additional CSS. AFAIK the others are handled the same way.

For additional CSS and likely other custom styles, they are saved under theme options, so are unique to the site and theme. They persist with the related theme through updates, even if you switch themes, then switch back. They do not migrate to a different theme though. Additional CSS is retrieved from theme options and output as inline CSS after the enqueued external files are referenced, so take precedence over any equivalent rules in external files.

That said, I don’t think additional CSS or the style book in general is intended for “complex CSS styles”. They are meant for minor end user overrides of default theme styling. If you need to apply complex CSS styling, you should probably be developing your own theme or child theme and not rely upon the style book to achieve complex styling. It is possible to specify quite complex styling, it’s just not the intention.

I’ve seen naive users who had copied their classic theme’s entire, very extensive style.css file contents into additional CSS, only to make minor changes. While redundant and unnecessary, it didn’t break anything. So adding complex styling this way which differs from the theme ought to work as well.

While not a completely authoritative answer, I hope this helps clarify things for you.

Thanks for the answer. It does help very much.
I see what you mean as far as child themes style sheet having precedence over parent theme styles when it is enqueued in parent functions.php file.
Enqueuing the Style.css in the parent themes functions.php is now typically done for classic themes that use functions.php file.

Twenty Twenty Three (TT3) doesn’t have a functions.php because it built on the methodology of block themes. TT3 uses the theme.json file to control the CSS for block themes..as far as I understand.

Yes there are additional CSS style attributes for almost every block, plus the Global Style editing in the Full Site Editor.
I think my overall objective as far as workflow is keeping my custom styles from being overridden by theme or WordPress Updates.

I’m working with Gutenberg Block themes to build the overall site design.
Should I continue to use the classic theme approach by creating a child theme the traditional way by enqueuing the Style.css file in a newly created function.php.
or Just add custom CSS to the Full Site Editor Style – additional CSS area?

The decision you need to make is just how complex will your desired CSS styles be? If not overly complex it’s reasonable to do it all in the style book and not bother with a child theme, unless there is other customization besides styling that you need to apply as well. Saved style book styles will persist through WP and theme updates.

If you have more complex styling needs, or other customization as well, then a child theme is probably the best way to preserve your custom work through updates. With a block child theme, there’s another decision to be made. Do you apply your styles through style.css or theme.json? Either choice is valid. You can even do both. Use whichever you’re more comfortable with. If for some reason you do both, you’ll need to investigate which takes precedence. I don’t know the answer.

While TT3 does not have a functions.php file, some other block themes do. If it exists, it’ll be processed just as it would be for a classic theme. You can enqueue your child theme’s style.css just as you would in a classic theme by placing the necessary PHP code in your child’s functions.php. Since TT3’s default style.css contains no CSS code, you needn’t be concerned in this case about enqueuing parent theme style.css.

Since the block theme style paradigm revolves around theme.json, all else being equal you should probably stay with theme.json instead of style.css. But it’s just a conceptual preference. The approach you’re most comfortable with is probably the best choice.

There is actually another styling possibility that persists through updates — a custom plugin. Since styling is supposed to be the realm of themes, this is sort of a deviant approach, but it will work. You can enqueue plugin CSS files from a plugin’s PHP file. The only advantage here is that custom plugins are usually a little easier to create than child themes. But if there’s a need to involve a theme’s style.css anyway, the advantage is negated. In the case of TT3 with an empty style.css, a child theme is just as easy and is in better keeping with where styles belong. I only mention plugin styling for the sake of completeness.

Thanks so much for clarifying this. The custom CSS I would like to implement is not too complex. It is primarily adding a hover card effect to Gutenberg gallery block. So what you’ve graciously explained is that CSS added to Style book editor will not be overridden with theme updates. This is correct?
Thanks for the help.

Yes, not overridden! I did misspeak earlier though when I said styles are saved with theme mods. They are not, though some other persistent theme settings are saved there. Styles are saved in a special post type wp-global-styles. The theme’s name is part of the post’s title, this is how the theme can find its specific global styles settings in the DB.

Regardless of where in the DB, it is persistent through updates. You could even fully delete the theme, then reinstall it later and your styles will still be applied (as long as the related post remains in the DB).

@bcworkz Thanks. I think I understand. Apologize for late response.
Theme mods would be specific for to different themes as thus get overridden when that theme updates?

No they don’t. Theme mods, being saved in the DB, persist through updates. Your data, including theme mods, in the DB is supposed to remain unchanged through updates. WP asks us to make backups before major updates, but it’s just for the sake of safety, it doesn’t try to change or remove any data there. At the most WP might modify the DB’s overall structure, but your data should remain unchanged.