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

> How do you define a commonly needed unit? Are the spec authors open to standardizing platform specific units? My understanding was that there was a desire to keep the spec mostly platform agnostic.

This is difficult to talk about in the abstract.

If you have a specific unit in mind, maybe better to open an issue for that?

I think that most units will have a common idea that exists in each platform.
Something like `vh` isn't platform specific. `vh` as a CSS unit is platform specific, but the core idea, `height of the viewport` is something that makes sense in each context, even print.

-----------

> Keep the unit types restricted, but allow an escape hatch.

> > Additionally, this explanation makes it sound like option 3 in @drwpow's original post is not so much its own distinct option, rather its an additional detail that could be paired with option 1 or 2. It might be helpful to update that list for clarity.

This only means that the list is well defined and that undefined units are invalid.
It doesn't mean that the list must be kept small.

-------

> I think a similar approach would be a better way to address prototype/pre-spec implementations. The spec can allow parsers/transformers to ignore invalid tokens. If a vendor wants to add a unit that isn't in the spec yet, they just use it in the unit property as if it was valid and then end users can use a plugin or custom transform (perhaps written by the vendor) in the parser to handle it.

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 to eagerly.

The only browser that can effectively do this analysis is Chrome because of their oversized market share.

You can't have tools shipping support for a unit `x` and then standardize a differently defined unit `x` later without causing some breakage.

You have to measure how much you will break and have some allowed margin that is deemed acceptable.

A good example of this is : https://developer.chrome.com/blog/smooshgate

-------

I am not saying that vendor prefixes are a good solution.
And I am well aware of their history on the web :)

I think that token files are slightly different.

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.

So a removal of a vendor prefixed CSS property is extremely risky.
It will break websites and it will affect many people who are unable to resolve the resulting issues on their own.

This is not true for token files.

- the token file schema can have versioning
- token files can have versioning
- tools can have versioning
- we can assume that token file creators and token file consumers can easily reach each other

In other words removing a tool specific unit can be handled much more easily and with much less dramatic impact that a property removal on the web.

------

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


-- 
GitHub Notification of comment by romainmenke
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/245#issuecomment-2309407384 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 06:15:21 UTC