Re: [community-group] Dimension type expanded unit types (#245)

> This is a nice idea but it does have very sharp edges.
> 
>     * browsers regularly ship buggy implementations
> 
>     * browsers regularly ship things too early
> 
> 
> Each time they get it wrong it requires shipping use counters to analyse what the impact would be of breaking changes. Each time they have to cross their fingers and hope that developers haven't used a feature too eagerly.

That's not the case with feature flags, which is how most new features are prototyped. Because enabling the feature flag requires an end user to change their browser's settings, developers have no way of guaranteeing they'll be supported in for any user (even those that are using whatever browser has implemented the prototype). Because of this, developers don't ship those features in production, with the exception of small features that only serve as progressive enhancements or those that can be polyfilled by the developer shipping additional code.

<hr />

> A major issue on the web is that most websites aren't actively maintained.
> They were created some time ago and are expected to keep working in future browser versions.
> Those who created the website aren't the same persons as those using it.
> Those experiencing issues with a broken websites are unable to fix those issues.

I agree that "unmaintained but still in use" will probably be a less common problem for token collections than it is for the web, but I wouldn't be surprised if it still happens. Open source projects where a maintainer becomes disinterested and corporate environments where resources get shuffled away from something that's "working fine" to something more pressing both spring to mind as ways this could happen.

<hr />

> the token file schema can have versioning

It could, but I'd caution going down that route. Versioning the spec (as opposed to it being a backwards compatible living document) could cause a lot of churn for users. Two ways this manifests:

1. **Support gaps.** Various tools will roll out support for new versions of the spec at a different pace. That'll be the case no matter what, but versioning usually implies breaking changes. Breaking changes would force tools to choose between supporting different versions simultaneously or passing the burden of cross tool/verison compatibility onto users. 

I realize breaking changes are already happening with things like `value` -> `$value` and changing some string values to objects. But I'm hoping that's only necessary because the spec is still currently in draft format and that once it stabilizes it will be backwards compatible.

2. **Confusion around the version numbers themselves.** As you mentioned:

> token files can have versioning
> tools can have versioning

The latter is definitely already the case, and while the spec doesn't currently have a canonical method for the former, you could easily just use the file name to version them. The more things with versions numbers that are coupled, the harder it gets to have conversations without causing confusion. I believe that's one of the reasons docker has moved away from versioning the compose file format.

I'm starting to feel like maybe I'm getting a little bit off in the weeds now though as this is probably tangential to the original issue. I'll try to reign it back in,

<hr />

> I am also not particularly in favor of a `vendor` field.
> 
> However I do think these things are important:
> 
>     * the list of allowed units must be defined, all other units are invalid
> 
>     * more units can be specified in the spec as the need arises
> 
>     * tools must not squat common names for future units
> 
> 
> I think that a `vendor` field is an effective solution for token files. If a better solution exists, then obviously we should pick the better solution :)

Totally agree with the mentality. I think all three of these goals can be achieved with option 2 from the original post: 

> Expand the list one-by-one. Every unit added must be reviewed and approved, and standardized.

I think the key with that approach will be spec authors being receptive to various platform needs in a timely and cooperative manner.

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


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

Received on Monday, 26 August 2024 18:27:29 UTC