You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In lots of conversations, we tend to use CSS as the default paradigm. #188 and #177 are just a few recent examples, and it's a common topic in the discussion of many definitions. This makes it hard to accomplish the stated goal of "expressing design decisions in a platform-agnostic way."
One way to counter this would be to define a clear list of target platforms, so everyone could familiarize themselves with which features are common to all platforms and which are not.
As inspiration, browserlist provides a clear/unambiguous way of identifying target browsers (including release/version numbers). This, in combination with data from caniuse, allows developers to confidently choose which features to support.
Some way of specifying which CSS DOM styling features to support
Some way of specifying which JS DOM styling features to support
Native platforms: (is there a browserlist equivalent for native platforms?)
Swift >4
Kotlin >1.4
Objective C (OSX and iOS) > ???
Java (Android) > ???
React Native > ???
I don't know enough about native platforms to accurately guess which versions of those languages and APIs make sense to cover a desired percentage of install base - maybe we should invite some folks with knowledge of those platforms to weigh in.
Overall, I think this would help guide the conversation and allow us to be more objective when making assessments of format specifications.
The text was updated successfully, but these errors were encountered:
A related question to ponder might be what should the focus or scope of the DTCG format be? Should it focus only supporting the kind of design properties that are supported by all platforms and design tools? Or should it strive to cover the union of all the platforms' and tools' capabilities? Or something inbetween?
The genesis of this question came from another question: how should we define the typography composite token (#102) ? It seems like there's general consensus around having an "open" definition, where we have a required set of properties, but accept any number of additional properties. I suggested that the required properties should be the "minimum amount of information necessary to render a given element."
My initial suggestion was that font family and font size were all that should be needed to render a piece of text. But, I realized that a lot more is needed, otherwise it's up to the platform to interpret/infer - color, weight, letter spacing, etc. So, I set out to figure out what set of properties is shared across all target platforms (in progress spreadsheet here) ... and realized we don't have a standard definition of a target platform 😬
To your question: the "open" format does all the above. If the format requires a property, it should be guaranteed to be supported by all platforms and design tools. Beyond that, the spec should allow (but not require) an author to cover any capability that their target platform has, now or in the future.
In lots of conversations, we tend to use CSS as the default paradigm. #188 and #177 are just a few recent examples, and it's a common topic in the discussion of many definitions. This makes it hard to accomplish the stated goal of "expressing design decisions in a platform-agnostic way."
One way to counter this would be to define a clear list of target platforms, so everyone could familiarize themselves with which features are common to all platforms and which are not.
As inspiration, browserlist provides a clear/unambiguous way of identifying target browsers (including release/version numbers). This, in combination with data from caniuse, allows developers to confidently choose which features to support.
A place to start would be something like:
I don't know enough about native platforms to accurately guess which versions of those languages and APIs make sense to cover a desired percentage of install base - maybe we should invite some folks with knowledge of those platforms to weigh in.
Overall, I think this would help guide the conversation and allow us to be more objective when making assessments of format specifications.
The text was updated successfully, but these errors were encountered: