Styling
Principle
Section titled “Principle”One stylesheet system. The front end and the editor apply the same rules. Every path the theme loads is a file the production build emits.
Hand-written CSS against theme.json presets covers layout, type, and focus. The file stays in the tens of kilobytes. The front end enqueues it. add_editor_style() receives that same path. This holds only while the file contains no @layer.
add_action( 'after_setup_theme', static function () { add_theme_support( 'editor-styles' ); add_editor_style( 'assets/css/theme.css' );} );
add_action( 'wp_enqueue_scripts', static function () { wp_enqueue_style( 'theme', get_theme_file_uri( 'assets/css/theme.css' ), array(), wp_get_theme()->get( 'Version' ) );} );A utility framework earns its place when most of the design is utility classes in PHP templates.
The build scans those templates so unused utilities drop out. There is no safelist kept in reserve. The front-end build and the editor build are separate. The editor build can skip the framework’s reset.
The editor file loads with enqueue_block_assets while is_admin() is true, not with add_editor_style(). TinyMCE, including rich-text fields from a fields plugin, receives the same URL on the mce_css filter.
add_editor_style() loads at most one extra file: small, unlayered, for rules that must survive selector rewriting. The production build writes that file. A theme that does not need the extra file does not reference it.
Production CSS is minified. One feature does not add a second library beside the system already in use.