Opt-In Typography Styles

[endigo9740]

Describe what feature you'd like. Pseudo-code, mockups, or screenshots of similar solutions are encouraged!

We've had a lot of folks struggling with Typography styles overrides, either locally or globally. Let's look into a means make it easier to opt-in. We found a lot of success with inputs, so let's follow the lead there.

What type of pull request would this be?

Enhancement

Any links to similar examples or other references we should review?

No response

[endigo9740]

Noting Tailwind v3.3 feature for review:

• https://tailwindcss.com/blog/tailwindcss-v3-3#new-line-height-shorthand-for-font-size-utilities
• https://tailwindcss.com/blog/tailwindcss-v3-3#configure-font-variation-settings-for-custom-font-families
• https://tailwindcss.com/blog/tailwindcss-v3-3#new-hyphens-utilities

[endigo9740]

Note: font sizes should be built into theme settings, design tokens added

[endigo9740]

FYI I've started a new PR here: #1374

I've made a few modifications so far:

1. I fixed some HTML elements within the "Explore" drop down in the app bar (unrelated)
2. Implemented the Tailwind Typography plugin for use within our blog
3. Update our blog to utilize the .prose class by default instead of custom styles
4. Reimplemented the way we use .prose styles in typography.css. This was all setup incorrectly before.
5. Documented overriding .prose settings in the Tailwind > Typography section of our docs (bottom of page)
6. Simplified many of the existing typography selectors

Per number 5, here's a before and after:

h1:not(.unstyled):is(:not(.prose *)) { ... }

h1:not(.unstyled) { ... }

Note that current updates do not address the primary issue yet - typography is not yet opt in. One of the challenges we're going to face is even when the default styles are used, folks still need to an escape hatch. So for now .unstyled will most likely remain.

But I'll return to this tomorrow. I'm testing several ideas, with the goal minimizing regressions for existing users. If there's a migration process, I'll keep it as simple as possible.

[endigo9740]

The new opt-in typography system is now available in the PR. This is a work in progress so not all changes have been fully implemented into our documentation yet. However, please read below to learn how this will work.

Stylesheet Updates

A number of updates have been made to stylesheets:

• A lot of loose partial stylesheets have (ex: tailwind.css, core.css, etc) have been moved to src/styles/partials/*.css
• The all.css stylesheet remains, but now imports skeleton.css - it's new successor
• A new skeleton-next.css stylesheet has been introduced, this mirrors skeleton.css but uses the opt-in typography
• A new skeleton-minimal.css stylesheet has been introduced which excludes core.css and typography-x.css

In short, all.css is not a very flexible name for what we're trying to do, so we will replace it with skeleton.css long term. Alongside this change, I've introduced two variations that allow you to quickly swap out the set of stylesheet imports. The skeleton-next.css allows folks to proactively migrate over time by toggling on/off -next in the path. While skeleton-minimal.css allows folks to bypass all core and typography styles, which are very opinionated. This is for power users who wish to have more control over their design system. It will most likely implement the opt-in typography when available though.

Note @niktek the CLI will need to be updated to use skeleton-next.css by default for v1.3 until v2.x. When v2.x drops we'll revert to skeleton.css, which will only allow the opt-in approach.

Opt-In Typography and Migration

To notify and prepare users for the upcoming change, I've updated the documentation to assume the opt-in option as the default. Additionally I've introduced a detailed explanation in the warning box at the top of the Typography docs:

https://skeleton-docs-git-feat-opt-in-typography-skeleton-labs.vercel.app/elements/typography

This explains what is happening, what the benefit is, as well as how to actually migrate. From v1.3+ we should assume new users are using the opt-in approach, while legacy users should be encourage to migrate asap. When v2.x drops the opt-in option will be the only available, which represents a breaking change. So updating sooner is in everyone's best interest.

Updating the Skeleton Docs

For now I've opted to wait until users can provide feedback on this change. We're using the skeleton.css stylesheet temporarily while we gather feedback on this change. But once ready, we'll switch to skeleton-next.css and begin implementing the utility classes per each typographic element. This will be a LARGE change as we have a ton of elements to update. However, find/replace should be able to handle many of the use cases. A full manual QA regression test will be advised before this goes to production though.

[endigo9740]

@SebasF1349 made a great suggestion on Discord, we'll leave the legacy all.css as the interim solution, but rename skeleton-next.css -> skeleton.css. The end result means one jump instead of two. Much simpler. It also makes it a bit easier to explain in the documentation.

I'll aim to implement this change tomorrow. Thanks Sebas!

UPDATE This change has bee implemented into the PR

[endigo9740]

FYI I've completed and merged this change. We'll provide a full announcement and recommendation for this in the next release notes. For now I'm going to create another PR that begins the process of updating our documentation site to utilize the new opt-in styles. This may be an on-going effort given the scale and scope of our doc site.

You can preview the upcoming changes here:
https://skeleton-docs-git-feat-opt-in-typography-skeleton-labs.vercel.app/elements/typography