Re: [community-group] [RFC] Format specification (#1)

I like this direction generally, though we need to be careful about how we build on top of CSS if we want to be able to evolve along with it. If we build on CSS syntax naively, we're likely to cause conflicts down the road (as has happened with every CSS pre-processor). 

In some ways what we're talking about is exactly custom properties – but stored in a "selector" structure that is type-based rather than DOM-based. I'd expect that we need both established types that every tool understands (colors, fonts, etc) and the ability to create custom groupings per-project. That could potentially be handled with different selector types (eg IDs, classes, elements) – or some type of new `@` blocks (`@colors { ... }`). 

I like thinking that direction, but:

- We need to think carefully about how tokens should cascade within these structures, so we achieve the ability to establish patterns and then override them for particular themes/media, but do it in ways that aren't surprisingly un-CSS
- As soon as we add new syntax e.g. `@colors`, we're inviting a conflict if CSS ever decides to do something similar. Existing id/class/type selectors are less risky for that sort of conflict, but more risky in terms of confusing what they do.
- In my mind, the main feature missing from CSS properties (including variables) is the ability to adjust _from the current/inherited value_. CSSWG has various proposals on the table, but nothing fleshed out. Even the color-adjustment syntax doesn't address this. 

@Martin-Pitt I'm curious what you mean by variables being "a bit late"? I don't follow that.

-- 
GitHub Notification of comment by mirisuzanne
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/1#issuecomment-659542449 using your GitHub account

Received on Thursday, 16 July 2020 16:59:11 UTC