Re: [community-group] Define how to handle different versions of the specification (#162)

> It could be nice to have a kind of manifest.json as we can see in several tools like Figma. 

> For identifying which version of the spec a file is following, the top-level $schema property could be useful—there's a short discussion on that topic over in https://github.com/design-tokens/community-group/issues/107.

This helps for a single person with a single file and a single tool.
Then you simple open it and the tool can display a warning or the person can compare the versions.

It is however not really the point of my question here :)

Either the specification embraces backwards/forwards compatibility principles or it doesn't.
This requires careful thought with each part of the specification.

CSS for examples has very nice compatibility features:
- You can open a very modern CSS file in IE8 and IE8 won't crash. It will even be able to handle a lot of the contents.
- A CSS file created for IE8 will also work just fine in latest Chrome today.

But the downside is that mistakes in the specification are there forever.
So you can't just wave concerns away with "we will fix it in a next version of the specification"

Compared to the web design tokens will also have the downside of being mostly private files.
You can not scrape 10 million sites and analyse them with Big Query to check if a spec change would be breaking.

Defining upfront how the spec will evolve is important because it will have such a big impact on the ecosystem around the spec.

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


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

Received on Wednesday, 31 August 2022 06:12:12 UTC