Type: Text alignment

[jimmymorris]

I'm not sure if this belongs under the Typography composite type, but any thoughts on how to classify attributes like text alignment?

[TravisSpomer]

Text alignment doesn't quite feel like it "fits" in a design token to me. The line between formally named components of a design system (design tokens) and styles (CSS, etc.) is pretty fuzzy and definitely not something that we all agree on, but text alignment is something that really feels specific to the styling of a particular UI component, not something that you would declare at a design system level. So that leads me to believe that this spec shouldn't define a way to classify text alignment.

[jimmymorris]

The scenario that comes to mind here is the interface needs to support right-to-left languages. It does not seem like something that is overtly specific to particular UI components but something that should be addressed at least in typography composition tokens.

[TravisSpomer]

The way I'm imagining your proposal, you could have one token file named ltr.tokens.json that defines RegularTextAlignment to be left and another token file named rtl.tokens.json that defines RegularTextAlignment to be right. You'd still need some styling logic or code outside of the token files to decide which of those token files to get its definition for RegularTextAlignment from in one way or another. Having a design token for the concept of "regular text alignment" doesn't seem to really help us formalize any design decisions or save any time, because regular text alignment isn't much of a design decision: it's just how a language is written.

Maybe I'm misunderstanding. Can you give us a specific example of about how having text alignment tokens would make your life easier when dealing with RTL languages or help you formalize a design decision?

[mryechkin]

@TravisSpomer agreed, text alignment doesn't seem like something that would belong in a design token. That's component logic, IMO.

[c1rrus]

@jimmymorris Would you like to be able to express a default text alignment as a design token along the lines that @TravisSpomer outlined above? Or did you have something else in mind?

While my gut reaction is to agree with Travis & @mryechkin - text alignment doesn't feel like something that would be useful to codify as a design token - I suppose it's conceivable that folks might want text alignments like center or justify to be linked to certain styles or components and be something they can alter at the system level. Perhaps a multi-brand design system uses left-aligned text for pull quotes in one theme and right-alignment in another.

If there are any folks doing stuff like that, please share. If there are concrete use-cases, it may be worth considering adding a type for this after all. In that case, for i18n use-cases, I wonder whether having logical values like CSS's start and end rather than (or in addition to?) explicit left or right ones might make sense - those would resolve to left or right depending on the app's/user's locale settings.

Out of curiosity, I just checked Figma and text alignment is not something it includes as part of a typography style. So, it looks like they reached a similar conclusion to Travis & Mykhaylo. Haven't checked other tools, so if someone knows of ones that do let you store text alignment as part of something design-token-esque like a typography style or variable, then please do share.

[jimmymorris]

it's conceivable that folks might want text alignments like center or justify to be linked to certain styles or components and be something they can alter at the system level. Perhaps a multi-brand design system uses left-aligned text for pull quotes in one theme and right-alignment in another.

This is exactly why, it is beyond the considerations around i18n where it is generally set at a global level but also design decisions that we may want to capture at either a semantic or component level.

[equinusocio]

text-alignment doesn't make any sense as token for various reasons:

• the raw values are really different across platforms. You write "start" on web/css. But on iOS/Android need a different output. What you would put as raw token value?
• The raw value doesn't match the real text direction. You write "start" on web/css, but if direction is top to bottom, "start" means..start. so the example token text-align-start: "start" has a different meaning based on the context, and can't be part of the source of truth since is not predictable.

[ipaintcode]

Addressing whether text alignment should be included as a design token, it's clear that opinions vary widely. However, considering the practical aspects of design systems, especially in internationalization and thematic variations, there's a compelling argument for more adaptable design tokens.

Text alignment, while seemingly a detail suited for individual component styling, has broader implications when considering RTL languages and the need for consistency across different brands or themes within a single design system. For instance, switching text alignment based on language direction or brand theme could enhance a system's flexibility and usability.

Design tokens for text alignment could be handy in global settings like RTL languages or when aiming for thematic consistency across multiple platforms. While some argue that this adds complexity, the real-world application of such tokens. Especially if they adapt to context-like language settings, could simplify design decisions and implementation across diverse scenarios.

In conclusion, while keeping the discussion grounded and practical, there's value in exploring text alignment as part of design tokens. It's about finding the right balance between specificity and adaptability to effectively serve a wide range of use cases. Let's continue to share insights and examples from our experiences to understand better how to evolve design tokens to meet these needs.

[danosek]

If alignment vary across platforms, everyone could make group of design tokens just to suit their design's needs. I think there is now easy way to unite alignment.

{
  "left-align-token": {
    "$value": {
      "web": "start",
      "ios": "left",
      "android": "left",
      "foo": "bar",
      "lorem": "ipsum"
    }
  }
}

[drwpow]

{
  "left-align-token": {
    "$value": {
      "web": "start",
      "ios": "left",
      "android": "left",
      "foo": "bar",
      "lorem": "ipsum"
    }
  }
}

While I think this is a very practical solution (thank you!), I’m wary of any solutions that are platform-aware like this. If you have to provide multiple token values based on the platform I think you lose the whole design lift of declaring things once and letting the tool translate it automatically per-platform according to what’s best. This not only inverts the responsibility, it also introduces versioning noise where other platforms are getting version updates when nothing actually changed.

I think this illustrates what other comments in this issue have already pointed out—text alignment often may be very dependent on specific localization instances (in many cases localization can even affect the design itself!), and I don’t have any thoughts on whether or not that means this can’t be a token type or not; just agreeing that this specific type has some unique concerns that make it difficult for a simple solution to work. But if there is a good solution, ideally it’s a single value that works automatically for most platforms and most usecases.

[danosek]

I totally agree.

1. There would need to be an effort across all major platform to unite keywords for alignment (who? how? 😅)

2. Or use most popular keywords like left and let the tool to do the best

   Eg. if to tool generates CSS, it could provide option whether to use traditional keywords or logical ones

• text-align: left vs text-align: start
• margin-left: vs margin-inline-start:
• left: vs inset-inline-start:

[jimmymorris]

We have tooling today that translates values from one platform to another. Just look at color formats where the format module suggest sets the color with an 8-hex value, but we can often transform those to hsl/lab/hex/lch etc.

With CSS moving towards the idea of start/end value, Kotlin for Android has a pretty good alignment with many of the CSS values, with only SwiftUI/UIKit being the "weird" ones to where it may take a little extra logic.