- From: Romain Menke via GitHub <sysbot+gh@w3.org>
- Date: Mon, 17 Apr 2023 16:50:45 +0000
- To: public-design-tokens-log@w3.org
@ilikescience How is this different form regular groups or using multiple files? ---- > We can offload the complexity of specifying which theme goes with which context to the translator. > >Styledictionary, for example, separates out the tokens definition from the configuration for processing the tokens. Can you provide examples? --------------- As an implementer I am not very interested in providing complicated configuration knobs and dials so that users can teach my tool that `$theme.dark` should be rendered with `@media (prefers-color-scheme: dark)`. For us it is much more interesting to have pre-defined conditionals for cross platform features like native dark mode. And then having some syntax feature in the specification that connects a token value with that native feature. As I said before, these types of "native conditonals" are different from "theming" or "branding". I think native conditionals need to be part of the specification and must be fully described, no hand wavy "the translation tools will fix it", but strictly defined :) I think it is critical to not confuse native conditional features with theming or branding. From a designers point of view these might seem similar but they aren't the same. -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/210#issuecomment-1511734937 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 17 April 2023 16:50:47 UTC