- From: Jacob Miller via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Mar 2023 20:29:50 +0000
- To: public-design-tokens-log@w3.org
> Since modes are user provided content translation tools can not generate code based on modes. > > All possible modes must be defined by the specification for translation tools to work. I heavily disagree with this. Any list that we come up with of valid modes will never satisfy the demands of end users. Let's say for example we have these modes as valid ones: - Light - Dark But now a user wants to add midnight mode (i.e. similar to dark, but all near-blacks are set to black to preserve battery life on OLED mobile devices, a fairly common pattern). Are we saying that midnight modes are an invalid use case for tokens? Maybe we add it, so now our list is: - Light - Dark - Midnight But now a user wants to add high contrast. Another user wants to add colorblind mode. Lets say somehow we hypothetically come up with a list of modes that encapsulate all possible visual modes (which personally I don't believe is possible, but lets say hypothetically we did) and we ended up with something like, - Light - Dark - Midnight - Deuteranopia - Protanopia - Tritanopia - High Contrast - Low Contrast - ...etc But a large organization wants different themes per product brand, one of which has a light appearance with a red brand color, and another of which has a dark appearance with a green brand color. Are we saying that's an invalid use of tokens? Modes need to be user defined, not an enum. -- GitHub Notification of comment by jjcm Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/210#issuecomment-1481853876 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 23 March 2023 20:29:52 UTC