You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. 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.
The text was updated successfully, but these errors were encountered:
Discussed in #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. But what and how much you style via JSON is entirely opt in.
This topic proposes:
theme.json
, global styles, block styles, etc.) and rely on CSS/SCSS instead.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.
The text was updated successfully, but these errors were encountered: