WordPress / developer-blog-content

In this GitHub space, WordPress team coordinate content to be published on the Developer Blog. Discussion and montly meetings (first Thu) in WP Slack #core-dev-blog
40 stars 5 forks source link

How to style block themes without using JSON #332

Open bph opened 2 weeks ago

bph commented 2 weeks ago

Discussed in https://github.com/WordPress/developer-blog-content/discussions/327

Originally posted by **justintadlock** October 30, 2024 There's a lot of confusion around the theming community that I've observed about the necessity of using JSON for styling block themes. There are many good reasons to utilize JSON methods of styling, as described in [Mastering theme.json: You might not need CSS](https://developer.wordpress.org/news/2024/10/17/mastering-theme-json-you-might-not-need-css/). But what and how much you style via JSON is entirely opt in. This topic proposes: - Discussing reasons why developers may opt out of JSON (`theme.json`, global styles, block styles, etc.) and rely on CSS/SCSS instead. - It will cover the methods for doing this that work best with the block editor (e.g., specificity, selectors in CSS and enqueuing). - Best practices for performance (e.g., enqueueing block styles vs. giant stylesheets). There are developers out there who much prefer their own styling systems, and that's an audience that we're not talking too enough when discussing block themes. The goal is still to get them to opt into using the standard tools, but there is _more than one way to crack an egg_ (so to speak). The primary audience for this article would be developers building bespoke sites where they are not using the Site Editor or giving their clients access to it. For those cases, there are no absolute needs for JSON integration. And, frankly, the JSON method is not everyone's cup of tea, especially when you're almost always doing both JSON and CSS in a theming project (it can be tough to track where things are styled when they're split). It is worth noting that this is specifically talking about styles rather than settings, which can both be handled via JSON. But the topics are related because the folks most likely to do this would also want to lock down specific design tools in the interface and rely much more heavily on classes (e.g., block style variations). Something to mull over anyway. Regardless, the primary pain point that I've seen is around styles in JSON and not settings.