✏️🔡 Type talk

[emmaorhun]

In our ongoing Type explorations there has been discussion around revamping Polaris's text components.
Those current components are Caption, DisplayText, Heading, Subheading, VisuallyHidden, TextStyle and TextContainer.
In the past there have been explorations regarding removing some or even just having one Text/Typography component, like in MaterialUI, that would handle the logic of all of the above.

Few things to keep in mind:

• Code readability
• Themability
• Level of flexibility
• Solutions from other design systems

Any opinions/gut feelings/preferences on how we implement consistent, clean and easily understandable type on the code side of things?

[alex-page]

I actually like the current Polaris approach. I feel there is too many options and it is not clear when to use each one. The components I could imagine:

• Heading
• SubHeading
• BodyText
• Caption

I would like to remove or consolidate these:

• DisplayText
• TextStyle
• TextContainer

[alex-page]

I think an opinionated set of HTML like you suggest above 🎉

[aaronccasanova]

I honestly don’t think individual type components adds value to the system and is border line problematic. I can't think of why we would want to tie type styles to semantic elements. There are many applications of typography usage that extend beyond Heading, Body, and Text.

I really think we should be thinking about type styles independent of the semantic html layer and provide a single Text or Typography component that promotes that distinction. As a developer, the ideal workflow is pulling the composite type from the designs and choosing the element that is the most appropriate for the given context. This is very scalable and can be accompanied with simple recipes on how to wrap the Text or Typography component to create new variants within the system.

[alex-page]

I think there is also something in-between @aaronccasanova. We definitely want to give flexibility but the components when constructed above can help guide folks to use sensible defaults easily. I would love to see prototypes of both.

[tjonx]

Heading and BodyText (why not Paragraph?) makes sense. However, SubHeading doesn't mean much, what's your definition of a SubHeading? Traditional definition is a piece of text that follows a heading, but that could also be covered by BodyText with a stylistic override.

I'd also argue about Caption. Captions are just paragraphs positioned under an image, a table, a chart, or any complex graphic. For this reason, Caption should just be an applicable font style.

There's not a lot of tags related to type in html; h1-6, p and ul ol li are basically it, and everything else like em strong q etc. live inside those tags. I think for the sake of readability, we need to avoid reinventing the HTML wheel by changing the naming pattern of our components and keep them as close as possible to what they are rendering.

If we want flexibility and theme-ability, then the styling has to be completely decoupled from the component. Font ≠ Function.

'Sensible defaults' would look something like this:

Font	Tag/Component
Body Major Body Body Minor Caption Footnote	p Paragraph
Title 1 Title 2 Title 3 Title 4 Title 5 Title 6	h1–6 Heading
Display 1 Display 2 Display 3	h1–6 Heading

But we should allow any font to be used in any Tag/Component to future-proof the system as much as possible. HTML offers a very stiff and strict vision of how type is used; and though the hierarchy works to some extent, it's not how typography has been working historically. Sure, there are some common rules that exist in typesetting for books and other materials where font hierarchy aids the reader, but in general, type should flex around its use-case and not the other way around.

[aaronccasanova]

I would love to see prototypes of both.

Absolutely, me too. Also, with considerations beyond the web.

The previous system I was building was heavily influenced by the Material Guidelines Type System, being platform agnostic, and all considering the best product developer workflow. Whether the app was built using React, Vue, Vanilla CSS, or UIs within the C++ game engine the constant shared language was the composite type styles. Some application don't even have the concept of a semantic layer so it's hard for me to make the connection. Demos, prototypes, etc. would help!

[aaronccasanova]

In the spirit of decoupling type styles from semantic elements perhaps we should simply generate CSS classes for each composite type. This would promote composite types being the shared language between design and development and allow implementation details to be platform/framework agnostic e.g.

.heading1 {…}
.heading2 {…}
.heading3 {…}
.body1 {…}
.body2 {…}
.caption {…}
.overline {…}
.blockquote {…}
.code {…}
.my-fancy-type {…}
// etc.

Regardless of the component architecture we land on we would be able to consume these classes. Additionally, other applications would be able to generate these composite types from our tokens based on their platform and project constraints.

[sarahill]

Heading and BodyText (why not Paragraph?) makes sense. However, SubHeading doesn't mean much, what's your definition of a SubHeading? Traditional definition is a piece of text that follows a heading, but that could also be covered by BodyText with a stylistic override.

I'd also argue about Caption. Captions are just paragraphs positioned under an image, a table, a chart, or any complex graphic. For this reason, Caption should just be an applicable font style.

@tjonx I feel like text falls into two groups: body (paragraph) and headings. I like the idea of grouping in those categories and then using t-shirt sizing. I've been playing around with this idea (this is still rough but gets the concept across):

Heading and BodyText (why not Paragraph?)

I'm kind of splitting hairs but I prefer body in this context because within the admin, I think it's rare we write paragraphs of text. That being said I get that it maps to html.

I honestly don’t think individual type components adds value to the system and is border line problematic

@aaronccasanova I actually think it's really nice for sensible defaults to have maybe a couple components like and . The thing I like about this is I could add and expect to get the default heading style and same with .

I agree though I'd like to see both of these prototyped. Feels like there's trade-offs of both.

[aaronccasanova]

@aaronccasanova I actually think it's really nice for sensible defaults to have maybe a couple components

I'm confused, do designers need to account for a given platforms implementation details? Is the idea designer would have Heading, Body, etc. components in Figma that map to Polaris components? From past experience as a product engineer, the only shared language was the composite type styles (the design file hand off never included anything about components, but rather a reference to a named composite token).

[sarahill]

Is the idea designer would have Heading, Body, etc. components in Figma that map to Polaris components?

Type styles in Figma only go so far. Figma components allow you to put multiple styles together. So this is something I wanted to try out. It's not necessarily the direction we need to or should go but they are easier to override while still having the ability to revert back to Polaris defaults and keeps the connection to the component.

I've got the same thing set up with text styles to test out both approaches. With that screenshot I was more illustrating how I was thinking about grouping and naming more than implementation in a given tool.

[aaronccasanova]

With that screenshot I was more illustrating how I was thinking about grouping and naming more than implementation in a given tool.

Yes, this exactly! I like that the screenshot is intentionally platform agnostic. To me, these are the composite type styles and thus the shared language between design and development.

As mentioned above, the composite types in the above screenshot would ideally be composed into CSS classes or SCSS mixins to ensure this shared language is accessible to all teams and platforms (in addition to our recommendations while using Polaris react).

e.g.

.heading-sm {…}
.heading-md {…}
.heading-lg {…}
.body-sm {…}
.body-md {…}
.body-lg {…}
// etc.