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

I think I'm aligned with @ddamato's feedback here, but I'm wondering if there's some assumptions being made about the token authoring process that are influencing these proposals. I don't want to derail this thread, but I think it's useful to do some context setting. 

# Should a tokens file be _easily_ edited/maintained by a human in a text editor?
#149 is still sitting open...and @romainmenke has posed some follow up questions we've yet to respond to there.

## A. If yes - a tokens file should be _easily_ edited/maintained by a human in a text editor
Then I see the issues of interleaved modes/themes within a tokens file as hugely problematic. I believe token authors will be most interested in maintaining how different tokens interact **within the same theme**, rather than focusing on a **single token's value across themes**.

## B. If no - tokens files will _almost never_ be edited/maintained by a human in a text editor
Then a design tool like Figma or Sketch, or some other token management tool could easily parse the file, and allow me to filter my tokens file down to the context of a single theme, regardless of the underlying structure within the tokens source file.

I think this is an important distinction, and I sense most of the proposals here are assuming `B`, but I'd love clarification on that from @jjcm @gossi @c1rrus and others.

## Multi-file approach
I think @dbanksdesign's explorations and conclusion in [this article](https://dbanks.design/blog/dark-mode-with-style-dictionary/#Conclusion) and @ddamato's examples above are worth considering here.

I could imagine something like this, where the responsibility for naming themes, defining fallbacks, etc is something a token tool handles, but not something that requires that complexity to be added to the token files themselves. To me, the benefit is simpler (and smaller) token files to maintain, organized by context. If a token editor needed to check the different values for a single token across files, a token tool could aid that use case, but I'm assuming that's needed less often than working across tokens _within a context_.

![image](https://user-images.githubusercontent.com/979463/231795352-043d5351-9c26-4043-a5e1-543abd70de95.png)

## Feedback
I'm interested to hear arguments against the multi-file approach and what the drawbacks might be. I haven't seen this method discussed in detail in this thread yet.

And great discussion everyone! Really appreciate the community involvement here.



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


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

Received on Thursday, 13 April 2023 14:45:33 UTC