Global Styles: an input for custom CSS

This issue stems from the recent FSE call for testing to create a custom 404 page. For my 404 page, I ended up adding several elements via the Customizer (accessible via Appearances > Themes > Customize), such as a site background image. I imagine that most of what I added will eventually be handled by Global Styles but as a designer, there’s always going to be something that could be tweaked a bit further.

There could be input form in the Global Styles panel for custom CSS:

This mockup includes some basic syntax validation, but it can be as little as what is being discussed here, and doesn't necessarily need the row highlight.

Note the details:

Full height panel
Fullscreen button to open in a modal
Ellipsis menu that if need be can contain a link to "read more about CSS"

Issue updated Jan 20.

Initial proposal

What if there was an input form in the Global Styles panel for “additional CSS”? I’ve shown it in these comps living alongside Global Styles top-level options for Color, Typography, and Layout (as proposed in #27473, comment) but it could be more subtle.

I expect there might be some passionate arguments on both sides of this issue, and possibly also some important context around the Customizer that I'm missing 😅 Let's discuss!

Tasks

I'd second this proposal. Not all third party blocks are supported by global styles, and if they were, there would still be unsupported properties.

My use case right now is overriding the default background colour of a third-party audio player block. There's no way to do this while using a block theme.

Custom CSS definitely needs to continue to function alongside global styles. Style settings should never expose all of the possibilities in CSS as user-facing options. There is a lot of additional background on the benefits of user-edited CSS in the original core ticket and Make/Core posts from WordPress 4.7. #30496 identifies this particular feature as needing parity and outlines three potential approaches to ultimately maintaining compatibility for all current customizer features.

If #30496 moves in the direction of providing a separate implementation of customizer features in the site editor, we should consider the pros and cons of the current interface. Custom CSS is one of the most successful features in the customizer. It offers instant live preview. The preview is fully contextual - the HTML exactly matches the frontend, so the CSS previewing can also reflect the frontend. And users can inspect the preview markup while customizing.

CSS probably wants to be implemented in a very customizer-like way if it is rebuilt in the global styles context. It almost needs to exist alongside a browse mode (#23328), or otherwise lock the editor canvas during CSS editing to provide the best possible frontend parity in markup. The literal iframe of the frontend works well for a live CSS editor.

It would also be great to see further progress on some things that were planned but not yet implemented for the customizer iteration. See https://core.trac.wordpress.org/ticket/38707 for background including design mockups. If CSS gets another redesign, there's certainly room to improve it further.

For those who can't wait :

At Ionos, we have developed a tiny plugin for the very same reason.

It simply replaces the input field with a tag-like-editor (similar to the @wordpress/components FormTokenField : https://developer.wordpress.org/block-editor/reference-guides/components/form-token-field/) to allow designers to apply a theme specific set of css classes.

Maybe this is solution to adapt for Gutenberg.

The plugin is about to be open sourced at github (https://github.com/IONOS-WordPress) within the next weeks.

The theme provides the set of css classes using a custom @wordpress/hooks filter :

addFilter(
  'gutenberg-customclassname-tag-input-extension-get-configuration',
  'wp-flausen',
  function (configuration, block) {
    return {
      ...configuration,
      items: [
        {
          label: `Funky effect`,
          value: 'theme-custom-effect-funky',
          description: 'Makes the block appear funky.',
        },
        {
          label: `Thick`,
          category: `Text`,
          value: 'theme-custom-text-thick',
          description: 'Makes the block font thick.',
        },
        {
          label: `Thin`,
          category: `Text`,
          value: 'theme-custom-text-thin',
          description: 'Makes the block font thin.',
        },
  ...

and the css classes in the theme's style.css :

...
.theme-custom-text-thick {
  font-weight: bold;
}

.theme-custom-text-thin {
  font-weight: lighter;
}

.theme-custom-spacing-small {
  padding: 1em;
}

.theme-custom-spacing-medium {
  padding: 2em;
}

.theme-custom-spacing-large {
  padding: 3em;
}
...

The applied css classes can be styled by the theme depending on their "category" in the configuration :

.gutenberg-customclassname-tag-input-extension-tag-category__text {
    background-color: #f0f8ff;
    color: #333;
  }

  .gutenberg-customclassname-tag-input-extension-tag-category__spacing {
    background-color: #789899;
    color: #fff;
  }

  .gutenberg-customclassname-tag-input-extension-tag-category__foreground {
    background-color: #69aade;
    color: white;
  }

I was trying to build a little site for myself with FSE today, and within 5 minutes I needed to make a custom CSS change, and immediately needed this. I think it's seriously problematic this wasn't made a higher priority. What are the next steps for this?

I love this idea and have already considered creating an issue for it. With customizer inevitably going away, I think this is a huge win for those who need to customize a few things via CSS.

IMO Custom CSS is essential for WP. There will always be situations that can't be addressed by global styles (plugins, theme styles held in stylesheets etc) and so I look forward to seeing a solution for this. Personally I would be happy for the customizer to be kept, and only show the Additional CSS box. It could even be rebranded as the CSS Customizer and have no panels.

Another thought: when this becomes part of Global Styles, perhaps CSS classes created here can be accurately reflected in the Editor when people use the Additional classes area on any block. That would really help as well.

Non-developers -- who are in excess of 90% of people managing WordPress websites -- absolutely need some way to enter CSS rules to tweak the appearance of their site. They will not create a child theme; it's beyond them. They shouldn't have to install a special plugin. This is core functionality that's needed in 100% of sites that aren't custom-developed by a developer, which is to say, 99%+ of sites.

I want ahead and added the "Needs Dev" label as I assume this issue is ready for a developer to work on.

@lgersman

@lgersman I like you modification! Looking forward to accessing the src.

@kauaicreative : I've actually already published the source code (2 todays after posting in this issue), but forgot to post it here 😅

react component for rendering the css classes : https://github.com/lgersman/wp-flausen/tree/develop/packages/react-tag-input

WordPress plugin providing the hook : https://github.com/lgersman/wp-flausen/tree/develop/packages/gutenberg-customclassname-tag-input-extension

example WordPress theme implementation : https://github.com/lgersman/wp-flausen/tree/develop/packages/gutenberg-customclassname-tag-input-extension-theme-example

I already extended the prototype to support CSS classes "per block type" (see https://github.com/lgersman/wp-flausen/blob/develop/packages/gutenberg-customclassname-tag-input-extension-theme-example/src/index.js).

If themes could also provide custom css classes via Global Styles (aka theme.json) instead of a JS hook like in the prototype - a designers dream come true. But that's another story.

Both plugin and theme work properly.

They are not published to the WordPress Plugin/Theme Directory. The intention was just spreading ideas and contributing sourcecode :-)

Here is another implementation in order to access tailwinds classes, https://wordpress.org/plugins/website-builder/

@critterverse

@critterverse can we try moving as a separate section below the "blocks" one?

@aristath

@aristath, Thank you, but I mean custom CSS in the post/page editor (not global styles). What are the plans for that?

@gyurmey2

@gyurmey2 What's being worked on is block level custom CSS. #44412 but that's still to be accessed via the Styles sidebar.

In the post editor, you find the "ADDITIONAL CSS CLASS(ES)" secion in the Advanced Tab, and now you can style the specific class name via the new Custom CSS via the Global Styles space.

@aristath

@aristath, Thank you, but I mean custom CSS in the post/page editor (not global styles). What are the plans for that?

I'm also wondering about any plans for Custom CSS for the entire post/page, but not global i.e. shouldn't be loaded anywhere else.

@gyurmey2

@gyurmey2 What's being worked on is block level custom CSS. #44412 but that's still to be accessed via the Styles sidebar.

In the post editor, you find the "ADDITIONAL CSS CLASS(ES)" secion in the Advanced Tab, and now you can style the specific class name via the new Custom CSS via the Global Styles space.

@bph Of course, thank you for the tips, but it doesn't solve two basic problems:

Ease of code management.
Performance, because global styles are loaded on every page, regardless of whether a given class has been used or not.

Anyway, in previous comments @Louis7777 and @Jabe64 presented arguments why it is so important.

The Blocks CSS plugin has over 4,000 active installs, so the demand is certainly there.

#47862

@glendaviesnz

Let's close the main issue and split the remaining tasks into smaller ones. @glendaviesnz, what do you think?

@bph

Closing this issue as the main feature is now in place and I have opened new issues for the remaining enhancements:

Global Styles Custom CSS: Add inline code completion and linting to input box similar to customizer #47945
Global Styles Custom CSS: Provide list of blocks that have had custom CSS applied at the block level #47946

@bph in relation to your suggestion "There might be a need for a better access to the Custom CSS", Design made a deliberate decision to not put the Global Styles custom CSS front and centre, so I have not added an enhancement issue for that, but feel free to comment in that existing issue.

@Mamaduka I can't remember what the final decision was on "Remove duplication of custom CSS in hybrid themes" - did we still want to look at merging the two?

@glendaviesnz

Thanks for your hard work on this and picking up on my suggestion @glendaviesnz I'll be happy to teach everyone where to find the most requested feature, now that's getting ready for 6.2. just have to travel a bit farther to get to it. 🙂

@glendaviesnz

@glendaviesnz, we're merging Customizer and Global Styles CSS before outputting them. I think we want to leave those in DB as is. Using both options should be a rare case, and we should recommend using the Global Styles.

Are we still looking to complete the tasks that have not been checked off, (see the list of tasks in the description) or are they not needed anymore?

Our websites are our creations, and we want them to look better than anything else! Developers, help us achieve the best results by adding a CSS field for every Gutenberg block!

Our websites are our creations, and we want them to look better than anything else! Developers, help us achieve the best results by adding a CSS field for every Gutenberg block!

Yes. Even better, add a page/post CSS field to efficiently organize our styles. We can't have them all in a global styles place and it doesn't make sense to load them where they don't get used. Part of making beautiful creations is good organization, working in a modular way and not getting lost in the code.

@carolinan

Are we still looking to complete the tasks that have not been checked off, (see the list of tasks in the description) or are they not needed anymore?

@carolinan The issues that are being followed up have been moved to separate issues - I have updated the description.

Navigation Menu

Repository navigation

Global Styles: an input for custom CSS #30142

Tasks

83 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Global Styles: an input for custom CSS #30142

Description

Tasks

Activity

lukecarbis commented on Apr 13, 2021

celloexpressions commented on Aug 17, 2021

lgersman commented on Jan 23, 2022

aurooba commented on Jan 23, 2022

bgardner commented on Jan 23, 2022

BinaryMoon commented on Jan 24, 2022

aurooba commented on Jan 25, 2022

MethylBromide commented on Feb 7, 2022

paaljoachim commented on Apr 1, 2022

lgersman commented on May 22, 2022

mtias commented on May 27, 2022

83 remaining items

gyurmey2 commented on Jan 31, 2023

bph commented on Jan 31, 2023

Louis7777 commented on Jan 31, 2023

gyurmey2 commented on Feb 1, 2023

Mamaduka commented on Feb 9, 2023

glendaviesnz commented on Feb 9, 2023

bph commented on Feb 10, 2023

Mamaduka commented on Feb 10, 2023

carolinan commented on Mar 28, 2023

dan-zakirov commented on Mar 28, 2023

Louis7777 commented on Mar 28, 2023

glendaviesnz commented on Mar 28, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions