- From: Jens Tangermann via GitHub <sysbot+gh@w3.org>
- Date: Sat, 24 Feb 2024 12:51:55 +0000
- To: public-css-archive@w3.org
I would like to contribute a critical perspective to the whole design-system aliasing topic in css vars. Sorry if this is a bit off topic. In my experience this causes more problems than it solves, and may encourage dark patterns, at least at the moment. For example: 1. When you do the semantic aliasing through css vars, you can't mark the not semantic aliased css vars as private. So in a context of a widly distributed design system, you can't make sure that the design tokens are used in the correct way. Could this be handled by the proposal? 2. Another much bigger problem, at least from a performance perspective, is the size of the css files, if you do semantic aliasing through css vars. As part of a bigger performance optimisation strategy, we switched a few design systems partially back from css vars to a server side abstraction like sass, were possible. (Keeping the semantic color css vars for dark theme support, not the color aliasing). This resultet in significant smaller css files and a much faster first paint. In one project we reduced the size by more then 50%, by moving stuff (several hundred var definitions) you don't neccessarily need in the browser, back to the server. I know each design system is different, and there maybe usecases, where it makes sense to do more in the browser. But i don't think the general advice to do everything in the browser now, should come without a disclaimer about the disadvantages and that server side css tooling will never go away completely, at least for large projects. In this regard, this proposal seems like it will also help reducing the file size aliasing can contribute to. (But i would still advice anyone not to do it completely in the browser, if not neccessary) I think a good combination of both is they key here, depending on the usecase. So the proposals that focus on extending css with design system focussed capabilities, are very welcome (like this and css functions)! Don't get me wrong. Just trying to support with input, on what can go wrong. -- GitHub Notification of comment by jens-struct Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9992#issuecomment-1962356463 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 24 February 2024 12:51:57 UTC