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

Thanks for drafting up such an elaborate proposal @jjcm , I quite like it. 

My main concern is also what @nesquarx  mentioned, about scalability. If I'm adding a theme with only a small bit of overrides, after the fact.. it might be easier to have this in a separate file, so I can easily see what a theme overrides on the core.

@connorjsmith 's comment addresses my concern in that regard:

> Depends on the heuristic we'd want to use for what constitutes an "extension" of the base theme (either via some sort of $extends, or just via name matching), but I'd think that defining more modes would be something like this

I also think that is very closely related to [my proposal of an $extends property](https://github.com/design-tokens/community-group/issues/116), some sort of simple metadata that defines a contract between token files or token groups even.

I share @romainmenke 's sentiment (to a small extent) that we should consider how the token format is processed and then translated to various platforms. For example, for Web (CSS), there's multiple ways you might prefer your output.

```css
:root {
  --some-color: #FF0000;
  --some-unthemed-color: #000000;
}

:root[mode="green"] {
  --some-color: #00FF00;
}
```

But, you could also have them as separate stylesheet files, and import/use the right one based on the current mode.
You could even decide that you want your core tokens, even if the current theme has no override for it (so you're using the fallback then), included in the themed file:

`default.css`:
```css
:root {
  --some-color: #FF0000;
  --some-unthemed-color: #000000;
}
```

`green.css`:
```css
:root {
  --some-color: #00FF00;
  --some-unthemed-color: #000000;
}
```
So above here, even though there is no specification for mode green for the unthemed token, we still get all the tokens in the output.

I think the choice between single-file, multi-file, and also the choice between full output vs overrides only, is always going to depend on (among others):
- the platform (web, ios, android, etc.)
- the stack (JS-in-CSS, less, CSS, sass, stylus, css modules)
- the translation tool (e.g. style-dictionary) and its capabilities for exporting to various outputs

Overall, I think the specification is definitely in the right direction if scalability and flexibility are considered, which @connorjsmith  definitely eased my mind a bit on with the $extends idea.

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


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

Received on Friday, 21 April 2023 15:42:20 UTC