- From: Jerome Farnum via GitHub <sysbot+gh@w3.org>
- Date: Sat, 01 Apr 2023 18:49:43 +0000
- To: public-design-tokens-log@w3.org
> #### Could modes have additional metadata? > For example `$description`? I could imagine this might be useful for tools that have the ability to list out all declared modes to the user. > #### Should modes have `$extensions`? > Sort of related to the previous point, maybe permitting `$extensions` on mode declarations could be useful too. The use-case would be extensions that relate to a mode itself rather than a token or group. > > This kind of thing could perhaps enable tools to add some additional semantics per mode, as @TravisSpomer was [suggesting](https://github.com/design-tokens/community-group/issues/210#issuecomment-1481615300) in response to @romainmenke. Both of these suggestions seem like sensible considerations to add, as both fit with existing patterns within the spec. Additionally, the use of `$extensions` to handle generator considerations seems like a particularly appropriate approach, as how tokens are output may have different solutions even within a particular platform or framework. Consider how one might handle modes and themes in CSS, there are several strategies one could employ. Just off the top of my head, one could: - Generate a single CSS file containing all permutations; each permutation wrapped within an appropriate media query - Generate a single CSS file containing all permutations; each wrapped within a rule and use some `matchMedia` logic to toggle rules as needed - Generate CSS files for each permutation and use the `media` attribute of the `link` or `style` elements to responsively load files - Some combination of all of the above Moreso, one might desire to optimize the token output any number of ways, perhaps choosing to output a set of default/base tokens that are stable across all permutations paired with streamlined sets per permutation that only contain the unique tokes for that permutation OR simply render all tokens per permutation. This choice may even be different per targeted platform, technology, or framework. It seems prudent to me, that the DTCG spec should aim to provide the means for a designer/team to model the relationship of the tokens to modes, but leave the business of how tokens are translated to generator tools. Leveraging the `$extensions` field to provide instructions for generator tools accomplishes that very well. -- GitHub Notification of comment by jeromefarnum Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/210#issuecomment-1493074188 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 1 April 2023 18:49:45 UTC