Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using target platforms to guide the specification #190

Open
ilikescience opened this issue Dec 1, 2022 · 3 comments
Open

Using target platforms to guide the specification #190

ilikescience opened this issue Dec 1, 2022 · 3 comments

Comments

@ilikescience
Copy link

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:

  • Web platform/DOM: cover 95%
    • 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.

@c1rrus
Copy link
Member

c1rrus commented Dec 1, 2022

Great idea!

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?

@ilikescience
Copy link
Author

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.

@c1rrus c1rrus added this to the Next Draft Priority milestone Jan 9, 2023
@o-t-w
Copy link

o-t-w commented Jun 14, 2023

Was anybody from the Swift UI team or the Android team invited to comment on the specification?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants