- From: Brian Heston via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jun 2022 00:49:08 +0000
- To: public-design-tokens-log@w3.org
Something along the lines of what's being discussed here is critical to the work I'm doing right now as well. I'm working on [FAST](https://fast.design) (Microsoft's web components foundation) including a design system capability we call Adaptive UI. As mentioned in #81, design systems are really a description of relative choices. Unfortunately, a lot of the ways we've been able to express this in the past have lost track of that fact, for instance, stateful color swatches being expressed as fixed indexes on a manually created color palette without the logic of how we got there. The system we've built (and are now evaluating how to evolve to this common format) is algorithm centric. Keeping with color, in our case a palette is generated from code and passed in whole to color "recipes", which operate on the palette and other information like contrast requirements or palette offsets to produce a color or set of colors, like for use in rest, hover, and active states. You define the rules of your design, the system figures out the values. The "adaptive" portion of this is that you can change one of the inputs and in real-time see the outputs update, for instance, for custom theme colors, lighter or darker, increased contrast, etc. These recipe functions have been written to be general-purpose with configurations, but there's no way they could be replicated with a simple base library of included transformations. This will be the case for any complex design system that someone intends to implement and attempts to describe in a format that primarily supports only references / aliases. We extend the recipes model to other areas as well including typography, density (padding & margins), motion, etc. We were considering a structure using custom composite types to represent this, though that felt more like it was being forced into that structure than purpose-built for it. Linking to issue #54, which removed support for that citing ease of understanding and implementation. In the composite type model we considered defining a list of attributes that included both inputs and outputs, essentially flattening the structure of a function. We would later reference the output attributes in more specific tokens. See #148 for a related point to this. The `operations` examples suggested above mostly take only one parameter, and I believe they all are factored to produce a single value. This won't be a sufficient model for describing all extension points like generating a color palette or a set of stateful colors. **In the spirit of principle two, being "focused, yet extensible", my primary concern with this draft is making sure the scenarios described here are not precluded.** I share the concern in the original post that individual tools or products will work around this and will end up with models that can't universally be supported. It's likely the needs are going to be more complicated than can be expressed in simple terms that all tools can be built to support, but it seems preferable if we have a way to define the customizations we need without diverging from the standard format with the expectation that all tools won't be able to support all scenarios. This is going to be true with `extensions` anyway, though that model doesn't sufficiently describe the structure for the scenarios in this issue. I think it's probable we can describe any custom processing with the re-addition of the `typedef` structure and some way to describe that external logic may provide the values. --- Building on the above suggestions, I support the idea of being able to register a custom function that a processor knows how to evaluate. Perhaps someday there is a standard on how to load those functions or reference them in the tokens doc similar to how a CSS Paint API worklet is registered. A more general word like `function` might fit more scenarios better than `operation` or `transform`. In order to define this in a way that can be expressed and validated within the document, the format for the `typedef` for custom composite types seems like a good start. It would need to be extended to define input or output attributes, or more reusable, two separate types for input and output. We'd need to be able to individually reference output attributes in subsequent tokens, as I've described separately as #148. In my stateful recipe example, that would allow for binding the `rest` color, etc. --- I can work on some configuration samples if the base requirements make sense. I was going back and forth on how to express the token `$type` as either a `function`, a custom `typedef` representing the function return type, or some combination like `function: palette`. The issue is the token is _not_ a function, it's the value _from_ a function. I suspect the idea from `typedef` will be required to represent this, though I was looking for a lighter-touch approach. An alternative to this is we add language to the document to indicate that any tools must preserve anything they don't understand, allowing for custom definitions of types and functions in a non-standardized way, which may see some common patterns emerge. -- GitHub Notification of comment by bheston Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/88#issuecomment-1162502111 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 June 2022 00:49:10 UTC