Custom CSS: add option to disable in theme.json

[glendaviesnz]

What problem does this address?

As noted here, currently it is not possible to disable the global styles custom css via theme.json.

What is your proposed solution?

Add the option to set something like

{
    "styles": {
        "css": false
    }
}

and remove the option from the site editor if it is set to false.

In the mean time it is possible to disable it for some or all users with the following php:

add_filter( 'map_meta_cap', 'remove_edit_custom_css_cap', 10, 3 );

function remove_edit_custom_css_cap( $caps, $cap, $user_id ) {

	if ( 'edit_css' === $cap ) {
		$caps = array( 'do_not_allow' );
	}

	return $caps;
}

[carolinan]

Is there a use case for this, that can't be covered by user permissions? Wouldn't this turn it off for all users including admin?

[glendaviesnz]

Is there a use case for this, that can't be covered by user permissions? Wouldn't this turn it off for all users including admin?

I am not sure. I guess there could be instances in some more heavily locked down corporate sites, etc. where you don't want anyone adding additional custom CSS via the admin interface. Many of the other global styles can be disabled via theme.json, so allowing it for custom CSS makes sense in terms of consistency.

[spencerm]

Is there a use case for this, that can't be covered by user permissions? Wouldn't this turn it off for all users including admin?

Hi, I was the original commenter! :)

So yes I have admin users and want to block them from adding CSS to a block. Yes I could make a user role that's somewhere between editor & admin, but easier and more readable in my opinion to just disable in the theme.json.

I could also see a theme author with a very stylized, highly opinionated theme and they want to block users from adding CSS to say the heading block which would break precise block patterns in unexpected ways.

[colorful-tones]

I thought I would take a stab at some discovery here. I'm likely in over my head 😄

Some items worth discussing:

Location of the new setting in theme.json

Proposed entry:

{
    "styles": {
        "css": false
    }
}

Possible alternative:

{
    "settings": {
        "css": false
    }
}

Another possible alternative:

{
    "css": false
}

Considerations for nested overrides

Would it be possible for a single block to enable custom CSS even if the theme.json has styles.css: false?

An example:

{
    "settings": {
        "css": false,
        "blocks": {
            "block/button": {
                "css": true
            }
        }
    },
    "styles": {
        "blocks": {
            "core/button": {
                "css": "& :where(svg) {fill:currentColor;}"
            }
        }
    }
}

Or, perhaps the single block's override is implied. So, once the styles.blocks.core/button.css is added then the custom CSS for that block is enabled and recognized.

{
    "settings": {
        "css": false
    },
    "styles": {
        "blocks": {
            "core/button": {
                "css": "& :where(svg) {fill:currentColor;}"
            }
        }
    }
}

However, I feel like the first example with settings.blocks.core/button.css: true is likely a better implementation, because we're talking about enabling/disabling the Custom CSS in the site editor as well. This could potentially be a way for theme authors to disable Custom CSS, but re-enable it for specific blocks only. 🤔

Perhaps all of this is out of scope for this particular task and might even overlap with some of the items on #53326, and I just wanted to mention it as I started to explore some discoveries. Thanks

[colorful-tones]

I discussed this briefly with @Mamaduka and he provided me some areas to explore in the codebase that could possibly be extended or referenced for any of this work. He mentioned that he had worked on some of the user capabilities for Custom CSS implementation and pointed me to search for wp:action-edit-css in the codebase, or https://github.com/search?q=repo%3AWordPress%2Fgutenberg+%22wp%3Aaction-edit-css%22&type=code

Another possible consideration would be elevating the work to include a new set of capabilities for the site editor, which would then control parts of its UI. That is likely out of scope though for this particular ask.