Re: [community-group] Native modes and theming support (#210)

Thanks so much for sharing the resolver proposal, @SorsOps. It's super interesting. I also had a brief play with the online tool you shared and it looks pretty sweet.

As you say, this moves the problem of how to handle tokens with variable values (for brands, themes, color schemes, information densities, etc. etc.) out of the scope of the DTCG format, which could help keep the spec simple for now. (aside: I do think there are some concepts within that resolver spec that might be nice to absorb into the spec in the future though)

However, it does raise at least one requirement for the DTCG format:

* A single DTCG file needs must be allowed to contain references that cannot be resolved within that file

Otherwise, the files used as modifiers would not be able to contain aliases to tokens provided by the sets.

Currently the DTCG spec does not forbid this, but it doesn't explicitly allow it either. If we were to agree that we wanted to allow this, then I think we should explicitly state that in the spec to avoid differing interpretations (e.g. one tool assuming references must be resolvable within the same file and therefore rejecting files where that's not true).

(Btw, I think this current ambiguity in the spec was highlighted before in another issue, but I can't find it right now)

Thing is, do we _want_ to allow that?

Personally, I quite like the idea that every DTCG file is self-contained. I think that can make them easier for humans to reason about. It could also make them more portable - e.g. the use-case mentioned above about referencing tokens from another DS's tokens. If you can cherry pick any `.tokens.json` file safe in the knowledge that it's not going to contain references that might not resolve, then I think that becomes easier.

What this thread is making clear is that there is a strong demand for being able to organise tokens into separate files. Forgetting about modes/themes/whatever for  moment, that's desirable even if it's just to divide up a large collection of design tokens into more readable and manageable chunks.

I've got some ideas for how we could add that facility within the DTCG spec. However, I'll write it up as a separate issue and link to it here once I have.

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


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

Received on Wednesday, 28 June 2023 08:25:49 UTC