- From: James Nash via GitHub <sysbot+gh@w3.org>
- Date: Sun, 05 Jun 2022 22:40:23 +0000
- To: public-design-tokens-log@w3.org
You're right, currently the draft spec doesn't have a type for things like assets. As you've noted, just falling back to a string type isn't helpful because there's no expectation for tools to do anything special with them (like guessing they could be file paths and trying to open them). In fact, [the spec forbids tools from trying to infer a type from a basic value](https://tr.designtokens.org/format/#types). Adding a type for referencing files has been on [our to-do list](https://tr.designtokens.org/format/#additional-types) for a while though, so perhaps it's time to finally to do it! :-) In my head I had always imagined to be along the lines of your first idea: the path type. I wonder though if "file" or "asset" would be a more appropriate name for the type. I think the token represents a _file_, the _path_ is just the technical means of locating that file. I don't have strong feelings about that though. In terms of the specifics, I prefer your first idea of just specifying a relative path. In fact, why not allow _any_ kind of relative path? For example: ```json { "icons": { "alert": { "$type": "file", "$value": "./path/to/file.svg" }, "bookmark": { "$type": "file", "$value": "../a/different/file.svg" } } } ``` The spec intentionally avoids requiring tokens or groups to have certain names, so in a similar vein, I don't think we should be mandating that people keep assets in directory with a specific name or location. -- GitHub Notification of comment by c1rrus Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/132#issuecomment-1146896157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 5 June 2022 22:40:24 UTC