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.