Allow developers to opt out of !important CSS rules generated from theme.json

[MarieComet]

What problem does this address?

Currently, CSS rules generated from theme.json settings get !important automatically added.
It's fine for theme authors who need to ensure that their CSS rules are not overridden by plugins or so.
But as a theme developer, working at web agency, I don't need those !important. I control the scope of custom plugins.

What is your proposed solution?

My solution is to add a filter, to opt out of adding those !important to CSS, in the compute_preset_classes function.
eg : add_filter( 'compute_preset_classes_important', '__return_false' );

[MarieComet]

/**
 * Given a settings array, it returns the generated rulesets
 * for the preset classes.
 *
 * @since 5.8.0
 * @since 5.9.0 Added the `$origins` parameter.
 *
 * @param array  $settings Settings to process.
 * @param string $selector Selector wrapping the classes.
 * @param array  $origins  List of origins to process.
 * @return string The result of processing the presets.
 */
private static function compute_preset_classes( $settings, $selector, $origins ) {
	if ( self::ROOT_BLOCK_SELECTOR === $selector ) {
		// Classes at the global level do not need any CSS prefixed,
		// and we don't want to increase its specificity.
		$selector = '';
	}

	$important_rule = apply_filters( 'compute_preset_classes_important', true );
	$important = $important_rule ? ' !important' : '';

	$stylesheet = '';
	foreach ( self::PRESETS_METADATA as $preset_metadata ) {
		$slugs = self::get_settings_slugs( $settings, $preset_metadata, $origins );
		foreach ( $preset_metadata['classes'] as $class => $property ) {
			foreach ( $slugs as $slug ) {
				$css_var     = self::replace_slug_in_string( $preset_metadata['css_vars'], $slug );
				$class_name  = self::replace_slug_in_string( $class, $slug );
				$stylesheet .= self::to_ruleset(
					self::append_to_selector( $selector, $class_name ),
					array(
						array(
							'name'  => $property,
							'value' => 'var(' . $css_var . ')' . $important,
						),
					)
				);
			}
		}
	}

	return $stylesheet;
}

[overclokk]

I think that the right place is to have a field in the theme.json itself instead of adding a filter.

[MarieComet]

I think it's fine in theme.json, but I don't know how to propose this change (code) :)

[MarieComet]

Just thinking : a field in theme.json can't make possible to disable !important from child theme or plugin.
PHP filter, yes.

[overclokk]

Yes, not yet but a theme.json is a better place for users, not only for developers.

[oandregal]

Hi Marie, I'd be interested in learning what issues does this causes for you so we can provide help.

I also want to share the rationale for why we use this technique: we need to respect user choices at all times. There're blocks whose specificity is higher than 010, hence the presets classes attached by the user won't be applied if we don't use !important. See this thread for a longer review. If there's an alternative that fixes that issue and doesn't use !important I'd love to investigate it.

[glendaviesnz]

I'd be interested in learning what issues does this causes for you so we can provide help

@jonschr, @webmandesign, @cbirdsong would any of you have a public theme in a repo, or be able to set one up, that demonstrates the issues around this - a classic theme, and a theme.json one if possible/applicable - and some reproduction steps for how to add content to a site running the theme to replicate the issues if needed. While exploring solutions it would be helpful to have some real-world scenarios to test against.

[webmandesign]

@glendaviesnz

You can test with my Michelle theme (https://wordpress.org/themes/michelle/):

• the older version Michelle 1.2.0 experiences issues with font sizes that are overridden with WordPress' !important styles.
• new version Michelle 1.3.5 fixes the issue by removing WP !important styles applying the fix from my GitHub comment.

---

Steps to reproduce the issue:

1. With WordPress 5.9.2 install Michelle 1.2.0.
2. Create a page and add a content from my gist.
3. Publish the page and check how it looks like on front end. The font size in both columns should be equal. This is OK in WordPress 5.9.1 (unlike WP5.9). But for my theme the issue persist on smaller screens. (So you guys have technically fixed the issue probably for most cases in WP5.9.1. But the main issue we have is with !important styles.)
4. Now update the theme to version 1.3.5 and check the page again. You'll see both columns have the same font size on all screen sizes.

---

Results:

I can only speak for myself. The issue was relatively fixed in WordPress 5.9.1 - meaning the font size is OK on large screens. But the real issue for me persist: WordPress still applies !important styles here.

The theme is set with responsive typography and you can still see the issue when resizing the screen (with Michelle 1.2.0 and WordPress 5.9.1+).

The only way around this is to remove !important rules applied by WordPress via the theme, or update the theme CSS code to use WordPress CSS variables naming.

In my opinion, though, there should be no !important styles applied by WordPress. That's the main issue here and without it everything would be fine.

If !important resolves some issue with theme.json themes, maybe go ahead there if that's really the only solution (although I still feel there must be a better way). But why messing up existing themes? Especially themes that promote using block editor?

---

Finally, I think we should also make more distinction in "classic themes" terminology. Among "classic themes" there are themes that don't support Gutenberg editor and the ones that do. So, I suggest using this terminology:

• Classic theme is a theme that does not include theme.json file and has no support for block editor. Meaning it was created for/around "Classic Editor". These themes seem not to be affected with the WP5.9 issue and that's why it is hard to trace - there is vast majority of this type of themes.
• Block editor theme has no theme.json but declares support for block editor (such as font sizes, color palettes, wide alignment). These themes are affected with WP5.9 issue.
• theme.json theme - for the lack of my knowledge, I use this term here as I don't know whether this means FSE theme yet or the theme can contain theme.json but not being FSE.

This whole issue seems to be affecting block editor themes only.

[cbirdsong]

I can set up a sample theme later this week, but for now I can describe some issues.

For font sizes, responsive typography is a big one. Even in theme.json themes you can only accomplish it through a clamp() value, which is much less straightforward than media queries and has other issues. (see below)

For block editor themes, another issue is that you can only supply pixel units for fonts in add_theme_support( 'editor-font-sizes'). Since I always use em or rem units and adjust them responsively , I would usually just pick a pixel value that looked correct-ish in the editor at common laptop resolutions, and then do the real thing with rem/em and clamp()/media queries in my CSS. The value I supplied was never intended to be used on the front end, and 5.9 overrode all my styles with it.

However…

This whole issue seems to be affecting block editor themes only.

This is untrue! There are plenty of reasons you might want to override a value, even within a theme.json theme. For instance, this is a common pattern I use when declaring any value with min(), max(), or clamp():

.has-large-font-size {
    font-size: 1.25rem;
    font-size: clamp(1.25rem, 1.25rem + 0.5vw, 1.8rem);
}

min(), max(), or clamp() are supported pretty well (~90% worldwide), but 10% is a lot pf people, and declaring the static font-size value before the clamp() one ensures those visitors still get a reasonable version of your design. The fact that you can only declare a single !important value in theme.json makes it impossible to offer this straightforward bit of progressive enhancement.

This only gets into issues created for font sizing. This approach creates many similar problems in other areas (most notably colors), which like this leads me to agree here:

In my opinion, though, there should be no !important styles applied by WordPress. That's the main issue here and without it everything would be fine.

!important should be treated as a “break glass in case of emergency” tool. Using it correctly requires a CSS author to consider how it would affect the project as a whole, but this just slaps it on everything without judgement, resulting in the inability to use CSS as designed to handle responsive typography, dark mode and even changing link colors on hover/focus, which is as fundamental and basic as it gets.

It should absolutely not be applied retroactively to pre-5.9/theme.json v2 themes, and I'd strongly suggest it not be applied at all, no matter how much easier it makes the job of the editor authors.