Feature: Add utility classes to Olivero to be used by site-builders

Not sure about the proposal but, by sheer coincidence, I am looking at that very shed to buy!! 🤣

Copy-paste my reply to mherchel on twitter:

No thanks. I think it would only encourage the re-use of aesthetics. Instead a design system should encourage the consistent use of structure and meaning. I wholeheartedly agree with https://dev.to/brianboyko/tailwindcss-adds-complexity-does-nothing-3hpn and https://dev.to/jaredcwhite/why-tailwind-isn-t-for-me-5c90.

Okay, I do have one thought:

Whilst I am all for proper separation of style and content, as typified by systems like BEM, that can only reasonably apply when designing a site from scratch, including a custom theme.

What we are talking about here, I believe, is adding a few “helper classes” so that someone can pick up the default theme in Drupal and adjust any views they add in a way that looks acceptable for their simple (blog, etc?) website. We are not talking about making the next nasa.gov. There is a difference.

I get it and approve of the idea. My only concern is that we might let people think that is also the right way to build nasa.gov. So long as we make it clear we don’t necessarily think so, all is good!

(And, to be honest, what principle people use in their own themes is their business. I don’t tell a plasterer what make of tin bath to use)

I'd have loved this when I was a site builder or working on sites that I couldn't do deployments to 👍.

I know the proposal mentions that the utilities will be manually maintained but if that gets difficult with time then there are tools like https://www.npmjs.com/package/@postcss-plugins/token-utility (as well as Tailwind itself) that could be used to generate the utilities automatically based on a configuration file of CSS properties and theme values.

I think it would be great to have classes like for the Bootstrap theme (margin, color, ...). Easy to use in the Drupal interface and in code.

I like the idea of adding the ability for site builders to add helper classes, but should that be the responsibility of the core theme to maintain? And wouldn't it add unnecessary bloat since the theme wouldn't use it out of the box?

The first thing that came to my mind was why not have a theme setting where site builders could load any or an approved list of frameworks from a CDN? Then, they could choose to load Tailwind, Bootstrap, Foundation, or whatever comes next.

I like the idea of adding the ability for site builders to add helper classes, but should that be the responsibility of the core theme to maintain?

I agree with Jim on this one.

The CSS library would not be loaded by default. It would be enabled by via theme setting. My thought is if the user can do simple site-building tasks, they can also enable that setting pretty easily.

Can libraries be generated on the fly? Could we create a theme setting to just pull in tailwind via CDN? Or add some fields where users could add external CSS/JS files? I think its great to have these types of classes in the default theme and that it'll play well with the EOOTB initiative, but I don't think Olivero needs to re-invent the wheel when tailwind and other CSS frameworks already exist.

Personally, I avoid CDN which often pose performance and privacy issues. It will be necessary to think of a local library.

The Tailwind CDN version is only meant for development/prototyping usage (e.g. sticking in a Codepen). It's MASSIVE in terms of file size as it's not been run through the build process that removes unused classes, and it uses the default Tailwind colours, font families, spacing scales, font sizes etc.

That's why it does make sense for the theme to provide these sort of classes - some of the classes use theme specific values.

Summarizing what I learned from my conversation with mherchel on Twitter:

1. The theme already aims to offer a consistent and semantic UI. For a basic user-friendly admin UI, it should not be necessary for module developers to add any classes. I think it's important that this is the starting point.
2. The proposed classes are currently just presentational. "There are many use cases where a site-builder just wants their view to output a pretty list of cards." I understand the desire to add some prettiness that does not come by default.
3. Personally, I am not sure if this use case is worth adding more code and the responsibility of maintainership. Those classes will be like an API. Users will depend on it in ways we don't know. A year later, we might be caught between the desire to update code and the responsibility to not break implementations. IMHO there is a real risk of creating a problem that is larger than the one it aims to solve.

3. Personally, I am not sure if this use case is worth adding more code and the responsibility of maintainership. Those classes will be like an API. Users will depend on it in ways we don't know. A year later, we might be caught between the desire to update code and the responsibility to not break implementations. IMHO there is a real risk of creating a problem that is larger than the one it aims to solve.

-- this seems like a big deal and one that had not occurred to me so far. Suddenly, I'm going off the idea.

utility classes are good for site builders as well as developers. Recently I worked on a Joomla CMS site and They have bootstrap 5 utility classes built into Joomla. This is a really helpful feature.

One thing to consider on the discussions around maintainability, avoiding breaking changes, and users using the CSS classes in a way that we might not know about:

One of the joys of simple, single-property utility classes is that they should never change what they do. The previous comments are right about introducing an API contract that would have to be stable between releases, but a class like .pl-1 is only ever going to add one unit of spacing using the padding-left CSS property. It's very unlikely that a future release of the theme would want to change .pl-1 to say, add 2 units of margin and also a red border. It's also unlikely that a user would use a class like .pl-1 if they didn't want one unit of padding on the left of an element, so I think we would always have a reasonable idea of how the classes were likely being used.

With this in mind, I think providing a public-facing CSS API that uses utility classes is much safer in terms of avoiding breaking changes than any CSS API that would use classes like .card, where there is a lot more scope for opinions changing on what that class should do, changes needing to happen, and then us introducing a BC issue.

I'd like it if utility classes are included and have often wanted them in completely unrelated projects to bring up here like admin themes. Quite often you're just after a small bit of modification where creating a subtheme isn't really feasible and you just want something done quick. Or for some reason a button or link in some small custom area you've made is way off, or your row spacing or padding is all wrong, and now you've got to jump through hoops to keep it consistent with the rest of the site. It happens.

If you're worried about semantics or trying to keep up with whatever best practice of the day you subscribe to, you're probably not using a core theme so you can code it up however you like. I wouldn't imagine people are using this for client work. But if you want to get something done quickly and easily and move on when you're not implementing a custom design, utility classes that can be entered in the UI are a big help.

While this would be a default theme for Drupal, arguments about what's best practice are best left to individuals. Some would consider utility classes best practice, others wouldn't. They're certainly quite common in very popular frameworks so wouldn't be out of place to me in a core theme. Your mileage may vary, and doing something useful for end users instead of forcing philosophy of code might be nice for the kinds of people this is ultimately meant for. This is odd for me to say, too, usually I'm very much in the "We don't need this because Drupal is a developers system" camp.

Adding in utility classes might make me actually want to use a core theme since it would be easy to add in those small modifications when necessary, especially in views. Even in the simplest, quickest, personal project that you might want to just throw online, there's a good chance you'll want to create something custom at some point and easily keep the layout and design in sync with the rest of the site without adding a subtheme. Or at the very least, not worry about adding something custom because you know you can enable the utility classes and sort it out quick if it goes wrong.

I believe adding more options to base themes is optimal if we are looking at having something that is widely usable and not just something that falls in line for demoing.

I think one of the big challenges for me when it comes to leveraging things out of the box when it comes to contributed themes is always the limitations of things like colors/fonts/layout choices/etc. There are often times where things have just been overlooked when addressing something. So having the ability to add utility classes with a simple theme setting could be useful in making a theme more useable to a wider audience.

Along these lines having something akin to Elementor in a contrib theme for Drupal would give a lot of weight and usability to Drupal.. Traditionally this sort of page building was accomplished by something like Layouts/Panels/Paragraphs. All of which are heavy handed and are database expensive if you start getting into complex layouts. Additionally, all of those solutions usually require a developer intervention to get the initial things looking usable.

A pet project I had a while ago, https://github.com/cmcintosh/dragon used a third party js library called GrapeJS to allow site builders to build out pages and entity displays, and then save/export those designs into code. So that instead of keeping all of the layout configurations in the database or in a config file you would end up with a updated theme with the changes applied.

This may be a bit out of scope for Olivero, but i think its something valid to consider as a part of the other customization options we are looking at adding into the new theme.

Agree. That being said, a granular utility class API will be very straightforward to maintain. I don't foresee it being much more work within the context of the theme.

If it doesn't break anything in the current theme, then I am all in the support of it. In my opinion, adding utility classes will give site builders more control over the styles for their own site and make the theme more usable, which sounds like a good idea.

I am not sure, how much the developers are going to use/like it, it would be quick to just write their own styles than adding the utility classes.

If we finally decide to add it, then it would be good to have structured documentation where the utility classes could be listed down, sometimes the site builders might not know all the CSS utility classes/property names :)

I think it would actually be good to have the additional utility classes.

@mherchel, I remember you telling me the whole idea of Olivero was to have as little as possible new theme settings...
Bet if you put a setting there many people will "just-in-case tick it" even if they won't really use it...
I wonder if this won't cost in terms of file sizes, didn't go through your patch so I wonder what you really already included in it and what might come needed/requested (to be mantained) in future. 23kb is anyway already something if not loaded async/deferred

Would't be (maybe) better to write a custom module to take care of it?
Wouldn't make it also simpler to separate documentation and help extending with might-be-(not)-so-useful extra classes and snippets?
Also, keeping it separate now, won't mean it could not be assimilated later on if it becomes extra useful/requested.

(Just thinking out loud)

2) It won't be able to easily take advantage of the current CSS variables until Drupal 10.

What's this?
(I'm learning)

If we're not using any CDN and disabling the file by default, then this will be great to add utility classes for site builders. The main issue is with CDN's, they disturb the performance of the site. Disabled files will also not impact the performance. In my personal opinion, we should provide utility classes.
The naming of the utility classes should not disturb the present theme. Otherwise, it's good to go.

I think it would need to be very well documented though, not only the CSS elements, but which modules to use to implement.

Andy suggested: Probably could add a help page or help_topics pages here

We've also been creating style guide style pages in our builds recently using a custom route and custom template.

I think this is a fantastic idea!

We already create these types of classes now for site builders in themes I've worked on. I appreciate the value this adds to the theme and I also think this will help attribute to be utilized more as a theme. The item to optionally turn it on is a fantastic idea so it is limited in performance concerns or unneeded styles.

I think documentation is key for these as well, both in what they do and their use cases or where they should be applied. Perhaps something like a table with where they should work or be applied for easy consumption or compatibility table for Views, Layout Builder, etc.

I still think this is something that should not be implemented on a default theme.
As clearly stated it is specific for "site builders", not "everyone".

Though, as a proof of concept, I made a patch to clearly show there is the advantage of an external module to implement it.
Also made and tested the module from a sandbox. Very basic with the classes by @mherchel added to every page.
In this way it would be possible to implement different choices, eg why Tailwind and not Bootstrap or one of many others. I don't understand much of it but I think it is a point to discuss on.
Also why not split the BIG css to different libraries. I don't know you guys but when I'm developing (/building) most of the times the libraries are NOT compressed. @mherchel one becomes over 180kb....
The external module I believe would become better also to manage the whole thing. Not alone having a dedicated page for it's own issues rather than filtering those in core.

I still don't get @mherchel point 2 on comment #27, what's the difference of having the variables in a module rather than in a theme?

I repeat myself with a quote just to make plain clear my (personal) opinion :)

I still think this is something that should not be implemented on a default theme.
As clearly stated it is specific for "site builders", not "everyone".

what's the difference of having the variables in a module rather than in a theme?

If we're adding utility classes to a site using olivero, we want them to make use of the variables we've defined in olivero. But because Drupal core supports IE 11 and IE 11 doesn't support css custom properties (css variables), all the variables we've defined are translated into hard coded values during the Post-CSS task.

If you open up olivero on any browser, you won't see css variables, you'll see the compiled values. Because of this, utility classes making use of olivero-defined variables, must be part of the olivero theme.

@Andy,

this is (not really my job) hard... :)

Till now I used the @import statement in my pcss to compile the css. I tried @import "../../../../../core/themes/olivero/css/base/variables.pcss.css"; in my module and I still get Olivero variables.
(wonder if something like active_theme_path() is possible and will make recursion better)

One more thing, being in a module wouldn't make them accessible to any other theme too? (eg layout libraries)

Guys, sorry if keep making questions that might look dull, again this is not my job and it's hard to keep pace learning all these "new things" coming out every day....

@mherchel
I think (in this case) my questions were (with a bit of rambling) quite related to the issue, worth it or not to add css utilities to Olivero, "The Core Theme", itself.
So, to better formulate my question, can anyone easily explain why is not better to make a module for it? I don't understand that.
Initially it might well go into the core-experimental group with Olivero if you feel like it.
Or maybe yes, put it in Olivero but DO NOT make it even visible from the theme itself. Modules in need can cherry pick whatever part they need. (Overthinking maybe a bit? Just yesterday I found this issue #1308152: Add stream wrappers to access .json files in extensions which gave me some funny ideas)

Maybe I am a bit lost with the language, but I make a difference between the words theme and framework, I match the word utilities to framework, and I don't see why users will prefer this one to any another (more complete) of their choice.
For which reasons didn't Bootstrap made it to core? Why did not Google Material? (Just to say if I had to pick a full fledged framework today I would go with the last)

- Besides, you need an invitation for the Drupal Slack -

@viappidu you can request access to the drupal slack

https://drupal.slack.com/signup

Till now I used the @import statement in my pcss to compile the css. I tried @import "../../../../../core/themes/olivero/css/base/variables.pcss.css"; in my module and I still get Olivero variables.
(wonder if something like active_theme_path() is possible and will make recursion better)

This is just a lot of extra abstraction for something that's only intended to be used with this theme, and even then, only by sitebuilders that aren't doing a lot of complex setup or code work. Your suggestion is technically feasible, but I don't think it's work we want to try to squeeze in before olivero goes stable.

Thanks @andy-blum
You pointed me in the right direction for slack, been at the page before but was accepting only a @drupalassociation email.
Found the proper place to sign up is https://www.drupal.org/join-slack

I'll try to behave better here :)