- 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