Re: [community-group] Prototype composite type in translation tools to ensure it is useful (#126)

> However, I think your proposed typed group syntax is a little problematic. Since tokens without an explicit $type inherit from their parent group, all the tokens in your example - except for the "font-family" one - would have a type of "typography". Sure, we could change the rules so that that inheritance behaviour doesn't apply for composite types, but I'd worry that would make the format more difficult for people to understand as it would be more rules to remember.

Inheriting `$type` in groups would not be possible in this proposal, that is true.
It would be the tradeoff.

This is related to : https://github.com/design-tokens/community-group/issues/149
Is inheriting `$type` in groups syntactic sugar or is there a specific use case for end users that is only possible with inherited `$type` properties?

-------------

> so a tool can "know" that the fontFamily sub-value must have a fontFamily value

That is the core of the issue :)
Any issue can be waved away by saying that the ecosystem **can** implement things correctly and that the ecosystem **can** be up to date with the latest specification, but that isn't how things work in reality.

In my opinion it is best to design a data format that is resilient and has desirable forwards and backwards compatible properties.

Adding in escape hatches for end users is critical to the long term success of a format.

-------------

>  You raise some valid concerns and I think our spec does perhaps need to be more explicit about expected fallback behaviours for tools that can't or don't want to process composite tokens as a single unit.

If I understand it correctly the current spec text doesn't cover the intended behaviour.
Especially with this statement :

> Tools MAY provide specialised functionality for composite tokens. For example, a [design tool](https://tr.designtokens.org/format/#dfn-design-tool) may let the user pick from a list of all available shadow tokens when applying a drop shadow effect to an element.

The intention might have been for all tools and implementations to always have support for all specified composite types in a generic way:

- **must** be able to parse and serialise composite types
- **may** expose component values as regular tokens

These things are important to specify.
If you leave it up to implementers to invent workarounds for gaps in the specs we will end up with so many interop issues :/

-- 
GitHub Notification of comment by romainmenke
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/126#issuecomment-1206107388 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 5 August 2022 06:52:52 UTC