- From: Anderson Entwistle via GitHub <sysbot+gh@w3.org>
- Date: Thu, 10 Nov 2022 16:01:14 +0000
- To: public-css-archive@w3.org
> why not CSS
Well, because there could be huge performance implications.
I am also curious about this and so have landed here. As mentioned above, the main use case is *flexible, non-semantic naming schemes*.
For example, preprocessors have ways to generate many CSS rules programmatically. Regular expressions *with* capturing group support could handle this natively (although this is not equivalent, as explained below). Whether it is in-scope is debatable and probably comes down to implementation feasibility.
Example use case:
```css
[class*="line-clamp"] {
display: -webkit-box;
-webkit-box-orient: vertical;
overflow: hidden;
}
/* New attribute selector with regex support on the RHS only since the main use-case is based on classes - not attributes */
[class=/line-clamp-(\d+)/] {
-webkit-line-clamp: $1;
}
```
#### vs. Preprocessor Programmatic Generation
###### Pros
- More flexible: match values described by a regex instead of using values from a predefined list
- Ship significantly less code: especially, *flexible, non-semantic frameworks* (faster CSS load speed, no difference in maintainability)
###### Cons
- No advantages when not using a *flexible, non-semantic naming scheme*
- Decreasing CSS size is not an efficient optimization for page speed
- In the modern web the size has nothing on JavaScript
- CSS does not present challenges this way as-is
- Potential for poor selector performance
- Almost becomes a shortcut for using `style`, which goes against separation of concerns
--
GitHub Notification of comment by aentwist
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1010#issuecomment-1310519353 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 10 November 2022 16:01:16 UTC