Add a style utility API

How does this integrate (or not) with asset loading?

I've been trying to get rid of as much of the system/base library as possible, and this has exposed various more or less undocumented 'utility classes' in core that have been around for years - clearfix, container-inline etc. that are loaded on every page despite in some cases only being used on a single or handful of admin pages in core.

Would the styles plugins also come with a .css file, or something else?

Hi,

@catch, this is something I have been thinking about too to avoid loading unused CSS on all pages.

- ✨ Add Bootswatch themes Active
- 📌 Starterkit: split Bootstrap CSS per component Active

Like with UI Icons or UI Skins, adding a "library" key to a style declaration could be possible. Then is a style of this declaration is used, the library could be automatically attached.

Problem would be in some "free" areas not connected to UI Styles like WYSIWYG, or link class attributes, (same problem regarding components BTW), to detect automatically that a class is used then search for matching style and so library... This can quickly become tricky. Especially if sometimes the same CSS class is declared in multiple style declarations.

Funny that you mention "clearfix, container-inline", those classes are also in Bootstrap, and in UI Suite Bootstrap I have removed them:

libraries-override:
  ...
  system/base:
    css:
      component:
        css/components/clearfix.module.css: false
        css/components/container-inline.module.css: false
        ...

And the case you mentioned, would this mean that Core should have declared libraries with one small CSS file only and properly attach only when needed?

@grimreaper I've been slowly doing that in ✨ Refactor system/base library Needs work although mostly for larger files used in less places. However pretty much all the use cases even for these tiny utility declarations are on admin pages so overall I think we should be doing the same.

We're approaching the point where the standard profile + stark loads about 1kb of CSS on a page instead of 7kb a year ago, this could be zero if we keep going. It opens up possibilities like inlining CSS for anonymous users without massive customisation etc. But ofc the last 1kb is the hardest - although stable9 means it's not a BC break for themes using that as a base.

Thanks, this looks very nice to go down to this few CSS by default!

Let's start with a MR inspired from UI Styles (as a first POC, we are still open to other projects point-of-views).

Proposed scope:

• Plugin definition (more flexible, to cover exotic notations)
• PluginManager with YAML discovery
• #styles "universal" render property (available on any renderable with and #attributes render property)
• Something to replace the "drilling" because we have now access to the RenderAPI
• A minimal form element with select & checkboxes)

Out of scope:

• Style library pages
• StylesheetController, StyleSheetGenerator with Saberworm dependency
• The full FormElement with Widget/Source Plugins
• Metadata in plugin definition related to library pages (preview_with, icon....)
• Integration with Drupal API (ckeditor, layouts, blocks...)

Current Style definition in UI Styles:

  protected array $definition = [
    'id' => '',
    'enabled' => TRUE,
    'label' => '',
    'description' => '',
    'links' => [],
    'category' => '',
    'options' => [],
    'empty_option' => '- None -',
    'previewed_with' => [],
    'previewed_as' => 'inside',
    'icon' => '',
    'weight' => 0,
    'additional' => [],
    'provider' => '',
  ];

Style definition proposal:

  protected array $definition = [
    'id' => '',
    'enabled' => TRUE,
    'label' => '',
    'description' => '',
    'links' => [],
    'category' => '',
    'options' => [],
    'weight' => 0, // to keep?
    'library' => '',
    'class' => '', // for 
            
              
              
              ✨
              Add HTML class property for styles?
                Active
              
            
    'additional' => [],
    'provider' => '',
  ];

Need to address: ✨ Support styles which are not HTML classes Active :

'target' => 'body'/'attributes'/'foo',
'key' => 'class',

like in https://git.drupalcode.org/project/ui_skins/-/blob/1.1.x/src/Definition/... ?

✨ Support styles which are not HTML classes Active can be covered (and ✨ Add HTML class property for styles? Active can be cancelled) by this proposal: https://www.drupal.org/project/ui_styles/issues/3517009#comment-16138133 ✨ Support styles which are not HTML classes Active

The contrib modules studied in the description have been reached:

• style_options: 📌 About the Core's Style API proposal Active
• block_style_plugins: 📌 About the Core's Style API proposal Active

Because our proposal is also covering theme/mode switching, let's also support of prefers-color-scheme or light-dark()

So, we are heading to a "Style API" covering both style utilities and theme/mode switching, in order to:

• Implement those 2 parts of design system with a single API, because it appears they share the exact same definition format
• Allow local application of a theme/mode, useful when a design system allow dark mode or specific branding yo be applied in a specific part of the page
• ✨ Support styles which are not HTML classes Active

So, we need to think about the way of applying a style globally. What do we do? We extend #attached render property with a styles keyword? We extends our own #styles render property? We add an other universal render property?

Let's check what is decided on ✨ Add a CSS variables API Active to be consistent.