[PLAN] Drupal CSS Modernization Initiative

I'm very excited about this initiative!

When working on the new CSS Modernization Initiative, I suggest we use design-tokens.

Introduction to Design Tokens - https://specifyapp.com/blog/introduction-to-design-tokens

Here are some additional ideas regarding design tokens:
We can use a system like Style Dictionary - https://amzn.github.io/style-dictionary/#/README
And a Figma plugin https://github.com/lukasoppermann/design-tokens

I second tokens. Especially global tokens for color, spacing, and typography.

Huge +1 on this.

However, because themes will become reliant on these custom properties, we have to be very intentional about the implementation, as we may not get a second chance.

This is the crucial point. As we're currently refactoring a lot of CSS/JS code in Gin I can totally relate to this 😉😅 As almost everything will be CSS3 variables for example (a lot already is) to have typography, colors, spacings, shadows, sizes etc. easily overwritten with CSS3 vars.

There are several things coming in CSS that are extremely exciting but make me nervous to do a CSS modernization right now.

1. Cascade Layers
2. Container Queries
3. When/If logic
4. Native CSS Nesting

If we really view this as a one-shot-to-get-it-right, I would consider waiting until we have some of these major architectural changes available to us. For those who may not be aware of each of these:

Cascade Layers
Cascade Layers is a proposal to allow CSS writers to define new layers of CSS, effectively creating a specificity boundary within the code. This would pair perfectly with the way Drupal's libraries are already set up using SMACSS-style base/layout/component/state/theme categorization. In a system using the new @layer setup, no rule in base - regardless of specificity - would override a rule in any of the lower layers.

Container Queries
Most CSS authors are already familiar with @media queries to change property values based on the with of the viewport, but container queries will allow us to change property values based on the width of an element's container. Using these rules, one could change the layout of regions (header/content/sidebar) based on the width of of the viewport, and change the layout of content & blocks based on the width of their region containers.

When/If logic
Right now, it's not possible to set mutually-exclusive media queries. For example:

@media (min-width: 600px) {
  /* ... */ 
}
@media (max-width: 599px) {
  /* ... */
}

In the above, it is possible to write conflicting CSS that gets resolved using specificity and the location of the ruleset. It's also a scenario in which we have one break point written twice. If we want to update the breakpoint we need to remember to update both 600px and 599px. With the new proposal, we can write this like a traditional if/else block:

@when media(min-width: 600px) {
  /* ... */ 
}
@else {
  /* ... */ 
}

Native CSS Nesting
This should be fairly straightforward from where we are now thanks to the way core's PostCSS is setup

@mherchel, could we add a link to the recording of your Design4Drupal presentation?
You covered a lot of upcoming CSS modernization that we'll be able to leverage.

"We need to get this right the first time" will probably be true again when Drupal 11 is released (~ 2 years after Drupal 10).

Drupal 10's major refactoring will be to modernize CSS, which will bring so many new features, and to take advantage of CSS variables (hopefully structured with design tokens).

In time, more CSS features will be available, allowing us to make our code more efficient. Once we get our modernized-CSS foot in the door, we'll be able to improve the code in smaller steps.

When thinking about modernising the overall CSS in core I highly recommend to build a design operation (DesignOps) strategy beforehand and secondly talk about possible new CSS features to incorporate.

This is the most missing thing I would line out in the design for Drupal space, as with a good designops strategy, changes later become really easy to decide and to do in most cases.

For this strategy to succeed properly and long-term, it's best to have an orientation and inspiration on existing tools like style dictionary or some Figma plugin tooling as well as best practices around frontend dev, but do not rely on something too far away of "the drupal space".

At best, we should not have an extra burden of maintaining the needed improvements, as they feel simply as the new normal or replace the old counterparts.

In my opinion this strategy would focus on which parts of the CSS is relatively easy to replace and therefore a "quick win" with a high outcome (e.g. logical properties) rather then which things are hard and make barely a difference (grid in all possible cases).
Furthermore, as already mentioned, we should talk about the lifecycle of custom properties/design tokens and how to integrate/maintain/deprecate them.
And last but not least, documentation will be key here, the more documented for beginners/themers/module builder, the better.

A few points that come to mind, maybe to add some to the issue summary:

• how to document custom variables (comment in the CSS file? which format?), do we have a separate css file with only the variables?
• where should custom variables names and purpose be exposed (api.drupal.org?),
• how do we document their scope since we can't assume all variables will be global all the time.
• do IDE offer autocompletion/documentation hints of some kind?

I'd like to propose utilizing https://open-props.style for Drupal 10 usage of CSS Variables.
1 hour video that covers the Open-Props project and its benefits - https://youtu.be/Z-kD-EhwKlA

Hello Sir, My name is Shivank Mishra currently Pursuing Computer Science Engineering (India). I would like to work in the Modification of Drupal Front-end page by using CSS, JavaScript, React and UI/UX to build a attractive and a reponsive website. I would like to have this opportunity to Contribute to this Organisation as its one of the growing Organization as Open Source. Sir I would love to make the Proposal Regarding it would you Please assign this task to me will try to work approx (4 to 6hr) to complete this task under great Mentorship.
Thank You

Email: mishrashivank2001@gmail.com
Contact no: 8382836059
Linkdin: https://www.linkedin.com/in/shivank-mishra-2bb4b1224/

Should we have an issue to replace use of float with modern layout techniques?

Sound huge change and most of usage in LTR/RTL

$ git grep 'float: left'|wc -l
200
$ git grep 'float: right'|wc -l
182

Hello everyone
my name is mohammad khan pursuing computer science engineering, i am a frontend developer and have nice grip on languages like HTML,CSS,CSS(Bootstrap),Javascript and React , I would like to contribute this project through GSOC'23 it will be great experience to contribute to this community and work along with mentors
I am want guide from the mentor and requesting mentor to assign this project to me
thankyou

Hello everyone
I have created the first draft of proposal for this project it will great help if mentors will review my proposal and advice me to make it more better

https://drive.google.com/file/d/1r2BZNbQMndiNVeP88TtI1fzgcfRQmPT0/view?u...

Thank you

Fixed broken link

Firefox ESR supports CSS nesting as of 128 which was released in July: https://www.brycewray.com/posts/2024/07/firefox-esr-native-css-nesting/ so that should be fully unblocked now afaik. Next release it could go out in is 11.1 in December.

Also I don't know if/how much we rely on it, but SASS is changing how it handles declarations and nested rules https://sass-lang.com/documentation/breaking-changes/mixed-decls/

Should we open a spin-off issue to switch to native nesting everywhere? Seems like something that can be done in its own right separate from any other changes.

Might we consider also introducing the use of @layer to help tame some of ridiculous specificity that both Sass and native nesting cause?

Using @layer would change a lot of how things work, but probably something we need to adopt eventually.

Declaring CSS in a @layer makes it process before any unlayered CSS. Since Drupal libraries don't use @layer, any existing library could override your theme.

Maybe I don't have the right strategy in mind for using @layer. But it seems like having everything in one layer using SMACSS is incompatible with using @layer in a theme.

The cascade works differently with @layer. A generic selector in a higher priority layer will override a more specific selector in a lower layer. I can see putting base styles in a low layer, and utilities in a high one.

Maybe if core converts the SMACSS layers, and provides a way to customize the names and order, that would work.