- From: Ryan Johnson via GitHub <sysbot+gh@w3.org>
- Date: Fri, 18 Nov 2022 00:08:39 +0000
- To: public-design-tokens-log@w3.org
Recently, I was thinking about how HTML remains forward compatible with attribute and element names, and I wonder if it would be helpful to take a page from their book and do something like the following. ## Specific to $type * all DTCG supported types will have `camelCase` spelling * all compliant tooling should support built-in types anyway, so there's no additional responsibility requirements on downstream tools * _custom_ types MUST be hyphenated * similar to HTML custom element naming requirements (e.g., `<my-input>`, `<some-button>`, `<our-fancy-thing>`) * the DTCG spec should provide a means of defining document-level metadata (maybe `#/$types`) that would allow token authors to register a custom type via a `{ "$types": { "<type>": "<schema>" } }` configuration * when a tool loads a `tokens.json` file, it should fetch the custom type schemas such that it would augment the base set of built-in token types * after registering the custom types internally, the tool can then use that information to validate, create, and modify custom token types ## Related * Similar to HTML `data-*` attributes, I believe `$extensions` fulfills the role of defining syntactically-inert data for custom functionality. -- GitHub Notification of comment by CITguy Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/120#issuecomment-1319373614 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 18 November 2022 00:08:41 UTC