Re: [community-group] Color first draft (updated) (#266)

> I see the challenges of “just accept any Color() CSS string”, but it appears color.js solved to a satisfactory level. Advantage: No need to create another format using JSON object notation.

If you’ve dealt with parsing, you’d know that parsing/lexing requires breaking down a very complex string into an abstract syntax tree (AST), many of which are JSON-serializable or a generic enough format to be universal. Taking a universal, JSON-serializable AST format and obfuscating it back into a [DSL](https://en.wikipedia.org/wiki/Domain-specific_language) has no advantages and only downsides. Also, in regards to “no need to create another format,” that’s the entire purpose of the w3c design tokens spec—to outline and create another format. That is the overarching goal of this project. We are defining that format here.

Further, culor.js has NOT solved it to an adequate level. It is still alpha software, does not support the spec fully yet, and has performance problems. Not to say it can’t improve! But we also do not want to prop up this specification on the back of a single open-source alpha project.

> I'm not certain I've encountered a case where other languages are unable to RegExp as easily as JS, but I haven't used every language. Indeed, I'm struggling to imagine what language aside from JS would be used.

Swift, Kotlin, and Java are three common consumers of the DTCG format, building iOS, Android, and macOS apps. Go and Rust are second-tier languages also within scope, being 2 languages that frequently overlap with JS/TS and web. It is directly the DTCG format’s concern to outline a non-web, non-JS centric universal format, to which CSS would be a significant technical barrier. One example worth looking into is Rust’s [serde](https://serde.rs/), which deals with serialization/deserialization between JSON and data structures in Rust, and can automatically handle memory assignment. Adding CSS parsing to, say, a Rust library’s plate for consuming DTCG is a step backwards. JSON is AST-compatible, universal, and there are myriad utilities in every programming language to deal with it as a universal language. Few other languages apart from JS have an adequate CSS parser… because they don’t need one.

---

Again, appreciate the input, but for this specific proposal CSS strings are out of the question at this stage. Please feel free to give specific feedback on the proposed JSON!

Worth pointing out that this PR wasn’t meant to “slip in” changes quietly to the color proposal. It’s been in the works for a couple years and has gotten input from many talented individuals, even authors on the CSS Color Module 4 spec. But even after this PR merges, it’s not a “feedback closed; everything is finalized” situation. Please just see this as _preparation_ for final input/review and we’ll tag you for more input, within the boundaries of the current structure/format.

-- 
GitHub Notification of comment by drwpow
Please view or discuss this issue at https://github.com/design-tokens/community-group/pull/266#issuecomment-2766598411 using your GitHub account


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

Received on Monday, 31 March 2025 15:28:19 UTC