- 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