- From: Matthew Ström via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Jan 2022 23:30:04 +0000
- To: public-design-tokens-log@w3.org
As you mentioned in your initial proposal, using the CSS keywords alone would require the parser to have an opinion of how color keywords map to each other between platforms. Say, for instance, I write a parser and I think that the keyword 'ButtonText` should be interpreted as the keyword `controlTextColor` when used in a MacOS context. This is pretty logical, but someone writing the design token would have to know about and agree with my mapping; they couldn't decide "I think it would be more consistent for this token to be `ButtonText` on the web and `textColor` on MacOS. The stack approach wouldn't necessarily require the user to write out every platform's keyword, just the ones they're writing for; if you wanted to just indicate `env(Highlight)`, and only parsed your tokens into a web context, it'd probably be fine. But `env(Highlight, SystemColorHighlightColor, highlightColor, #00ffff)` would allow a user to indicate which keyword they'd like the parser to use depending on what makes sense for each given platform. As to the name collision issue, I agree that it's a potential problem; kind of like how with CSS I can indicate that I want text to be set in "Times New Roman." If the user installed some bootleg font on their computer that calls itself "Times New Roman" but is actually Papyrus, they'll be seeing something that I didn't intend. The same is true generally with color keywords; if multiple platforms use the same keyword to mean entirely different things, it makes it hard to accurately target that keyword. I don't know the solution to that one, but I imagine it's a problem no matter how you parse keywords. -- GitHub Notification of comment by ilikescience Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/91#issuecomment-1010460355 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 11 January 2022 23:30:06 UTC