Re: [csswg-drafts] [css-cascade] Custom Cascade Layers (formerly "custom origins") (#4470)

Here's my feedback to this proposal.

## Concerns

* At one level I am worried that this proposal **might make CSS harder to learn**. Next to learning about CSS specificity now you also have to learn about this new concept of cascade layers as well.
* Another worry I have is that I think this will have numerous outside consequences: **a bunch of devtools and frameworks will have to be retooled to support this**. (thinking about browser devtools like Chrome devtools and compiler-based frameworks like Svelte now)

## Positive: it might be easier to get started writing CSS (in a safer way)

On the more positive side, this could give newcomers a clearer placer where to “put their stuff”.

Currently libraries like Bootstrap in their SCSS variant already have ordered imports that more or less follow a logical specificity graph (from base to class level to utilities).

You can already choose to simply extend that system by adding a component between those imports. But it does take some expertise to know exactly how to split things up.

Over the years I've employed numerous strategies to work with the cascading aspect of CSS in a good way, in both the context of a non-namespaced framework (Bootstrap) or in specific contexts that require high degrees of CSS knowledge to execute well (BEM/ITCSS).

I find that newcomers have a hard time looking "through the framework" knowing where they can divide it into pieces and start extending it.

Let's say you have a Bootstrap-like system that is established that is set up like this:

```
@layer reset, objects, components, utilities;
```

Then the newcomer could be instructed to write their component in the components layer:

```
@layer components {
  .my-component {
    /* some style rule */
  }
}
```

When the CSS gets bigger, organising could be done as such:

```
@layer components {
   @import url(button.css); 
   @import url(panel.css); 
   @import url(tabs.css); 
}
```

(or rather with a preprocessor so that we don't have too much HTTP requests)

## Positive: clearer theming

With this proposal I can see some novel logic happening in the theming world. Imagine you have to add theming to the above code.

```
@layer reset, objects, components, theme, utilities
```

```
@layer components {
   @import url(button.css); 
   @import url(panel.css); 
   @import url(tabs.css); 
}

@layer theme {
   @import url(button-theme.css); 
   @import url(panel-theme.css); 
   @import url(tabs-theme.css); 
}
```

Your theme can now live on a clear layer where it will always override the components layer.

## A potential risk: misuse as an organisational tool

I see a lot of people who don't really get the cascade. One risk of this is that it will simply be used an an organizational method while it does have specificity side effects, creating new problems.

Imagine this:

```
@layer reset, objects, framework-components, custom-components, utilities
```

In this example the custom components will have a higher specificity than the framework components. The project team is using the layers for organisation purposes:

```
@layer framework-components {
   @import url(button.css); 
   @import url(panel.css); 
   @import url(tabs.css); 
}

@layer custom-components {
   @import url(reverse-tabs.css); 
   @import url(logo.css); 
}
```

But there's actually no reason they should. They should have a similar level of specificity. It would probably be better to write:

```
@layer reset, objects, components, utilities
```

```
@layer components {
   @import url(framework/button.css); 
   @import url(framework/panel.css); 
   @import url(framework/tabs.css); 
   @import url(custom/reverse-tabs.css); 
   @import url(custom/logo.css); 
}
```

### All in all... (conclusions)

I welcome the efforts to improve upon CSS. I really don't like the flat non-cascading solutions that people escape to nowadays (like Tailwind CSS). I think the cascade can be such a strong tool if used correctly. If we can put tools in people's hands to use it in smarter ways that would be cool. But I think getting people to use this might be a challenge in itself.

-- 
GitHub Notification of comment by Wolfr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4470#issuecomment-673066173 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 12 August 2020 19:29:02 UTC