- From: Travis Spomer via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Nov 2022 21:59:35 +0000
- To: public-design-tokens-log@w3.org
Whether the format allows custom `$type` values or use the primitive types plus an `$extension` enables *roughly* the same set of scenarios. Pros of using JSON primitive types and `$extension`: * Allows a v2 of the token format to define custom composite token `$types` right in the token file * The list of valid `$type` values stays small *(though it's not clear if that matters since tools should probably ignore types they don't explode when reading files in v2 of the format)* Pros of using a custom `$type` value: * Easier to understand what's going on * Less typing * We probably *could* remove the confusing basic JSON types from the spec at that point The way I see it, the better of the two solutions thus depends on how important that "custom composite token types right in the token file" scenario is to you. I'm not sold on the importance of that—I'm struggling to come up with a scenario where you'd want to be able to store a composite token in the JSON but wouldn't need your tools to understand anything about those tokens other than their schema. In all of those cases, it seems like a custom `$type` would be a somewhat better solution anyway. If we can say that custom `$type`s would cover all of those scenarios that people are thinking they'd need custom composite types for, then that seems superior to me. But we'd still need the "basic data plus extra stuff in `$extensions`" pattern for other types of data, so eliminating the pattern for this one case might not matter that much. -- GitHub Notification of comment by TravisSpomer Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/120#issuecomment-1299279992 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 November 2022 21:59:37 UTC