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

Explore options for standardizing and extending theme.json design tokens for typography #39370

Open
glendaviesnz opened this issue Mar 11, 2022 · 3 comments
Labels
Developer Experience Ideas about improving block and theme developer experience [Feature] Themes Questions or issues with incorporating or styling blocks in a theme. [Type] Enhancement A suggestion for improvement.

Comments

@glendaviesnz
Copy link
Contributor

glendaviesnz commented Mar 11, 2022

What problem does this address?

Background discussion.

On the above issue, there was some consensus that there would be value in exploring the options for standardizing and extending theme.json design tokens in relation to typography.

This blog post provides a good introduction to some of the reasons for this.

This is intended to be a top-level issue for some of the initial discussions, with a number of smaller issues likely needed to prototype/progress the work.

@glendaviesnz glendaviesnz added [Feature] Themes Questions or issues with incorporating or styling blocks in a theme. Developer Experience Ideas about improving block and theme developer experience labels Mar 11, 2022
@richtabor
Copy link
Member

I'm not 100% sure, but what if core applied slugs autonomously for font sizes — instead of the theme providing unique slugs (i.e. small, medium, etc)?

Core's "slugs" could be integers, 1, 2, etc — so when a theme registers font sizes, it would register 1 as the smallest, and as many as they'd prefer (or there's a standardization cap, where if you go over it's unlikely to map to another theme's typography?).

And if I switch a theme, the 1 slugs (i.e. the smallest font size) should map as the smallest preset font size.

@glendaviesnz
Copy link
Contributor Author

Core's "slugs" could be integers, 1, 2

This would match better with what is being discussed for standardisation of spacing slugs, where a numeric slug seems to be the preferred approach. For spacing a 10,20,30 approach has been suggested for slugs to make it easier for themes to slot additional options between any core defaults.

@mrwweb
Copy link

mrwweb commented Jun 15, 2022

I think the other question around this is how do you set the default font size? It seems like the default should come first and then smaller and larger sizes on the scale go out from there.

My concern about 10/20/30 is that this might encourage themes to include too many values or think of the numbers as pixel sizes. --font-size--24 (or whatever) should almost never be set to 24px in this system. I think that's the big advantage of the single digit integer approach.

And I think @richtabor has a really interesting thought about normalizing font slugs. If we know the default, then everything else could just expand out from there in single steps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Developer Experience Ideas about improving block and theme developer experience [Feature] Themes Questions or issues with incorporating or styling blocks in a theme. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

4 participants