Replies: 1 comment 2 replies
-
|
This isn’t a bad suggestion. I’m open to a more generic format!
The current implementation is 1 file, 66 lines. That’s not that bad IMO, but it’s good to compare apples to apples and see if CSSOM both reduces lines of code and complexity. One main difference between the Terrazzo CSS plugin and CSSOM is the latter cares deeply about specific syntax. For example there are specific types for individual CSS transforms. The current implementation doesn’t bother with any CSS syntax whatsoever. Individual token types mash together a CSS string on their own. And the code you’re pointing to only takes some key–value string objects and builds them into selector scopes. The inner workings of CSS are opaque to the plugin, and this is only a means of generating scopes. But maybe we will start to care more about actual CSS syntax; it just hasn’t presented itself. So I think it’s a good approach, but let’s evaluate it based on the goal of whether or not this simplifies things. And if it does, great! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I've been poking around and noticed the way we're generating CSS output is using a lot of custom logic to translate the design tokens into CSS (here).
The main issues I see with this are:
Replacing this logic with CSS Object Model(CSSOM) entities to build up the generated CSS might allow us to improve the code quality and ensure correctness of the output.
Since CSSOM is a Web API it's not available in Node out of the box, however, there appears to be a community-maintained Node implementation here we could use: https://github.com/jsdom/cssstyle
Open Questions
Beta Was this translation helpful? Give feedback.
All reactions