Skeleton v3 Beta 🎉

[endigo9740]

Quick update - we've now moved to the release candidate! View this for the most up to date information.

• Skeleton v3 - Release Candidate 1 🎉 #3062

---

Hey everyone, Chris here from the Skeleton team. I am thrilled to announce the release of the new Skeleton v3 Beta, the latest milestone in our journey to create both the best design system for the web. This of course follows our recent roadmap, which details our plans leading up to the full launch later this year. Let's dive in and review what the v3 Beta means for you and your projects.

• v3 Documentation: https://next.skeleton.dev/
• v3 Theme Generator: https://themes.skeleton.dev/

News & Announcements

You can find progress updates and announcements for the duration of the v3 development cycle here:

• View the latest GitHub Announcements
• View the latest YouTube Announcements

Getting Started

Installation Guide

• React (NextJS)
• Svelte 5 (SvelteKit)
• (more coming soon...)

Migration Guide

• Skeleton v3 Migration Guide #2921
• Watch the Migration Video Tutorial

What's New in v3

Modular Packages

• @skeletonlabs/skeleton - this contains the core design system features as provided by the Tailwind Plugin
• @skeletonlabs/skeleton-react - a library of React components built using the Skeleton design system.
• @skeletonlabs/skeleton-svelte - a library of Svelte components built using the Skeleton design system.
• As well as integration for third party libraries, such as Floating UI and Shiki.

Design System

• A professional-grade Figma UI Kit and accompanying theme import plugin.
• A completely revamped Tailwind plugin
• New and improved Theme system and Theme Generator with nearly 3x the custom CSS properties
• Expanded color palette and utility classes
• Overhauled Presets system
• Overhauled Typography system
• A brand new Spacing system, for dynamic spacing based on a scaling factor
• An opinionated Iconography integration.

Tailwind Plugin

• Focuses on expanding Tailwind's standard utility classes, while also providing a number of unique utilities.
• Now features 20+ themes out of the box, including updates to our legacy themes.
• Tailwind Elements (ex: buttons, cards, etc) are much easier to implement and style.

Components

• All components have been rewritten from the ground up, including new names, features, and properties.
• Full support for React and Svelte 5, with more planned for the future.
• All components now use Zag.js as their foundation to maintain cross-framework parity.

Documentation

• Simpler onboarding and support for a number of new meta-frameworks.
• A deep dive into the fundamentals of using Skeleton.
• Complete code examples showcasing the entire process for implementing each feature.
• Numerous integration guides for implementing third party libraries such as Floating UI and Shiki.
• A new Cookbook recipe section illustrating how to mix Skeleton and Tailwind primitives to generate complex UI.
• Streamlined navigation, UX, and search to help you find what you're looking for.

FAQs

What does "Beta" mean?

For us, this means the Skeleton next branch is now feature complete. Essentially the minimum threshold of features we plan to ship for the final v3.x release are now in place in either our core or component packages. This does not, however, mean Skeleton v3 is complete, bug free, or stable.

Is Skeleton v3 ready for production?

Not quite. While we consider the v3 Beta to be feature complete, there's still a number of remaining issues to address. However, we continue to move at a steady pace.

Why so many changes?

If you review the original proposal, you'll understand the motivation. It comes down to a single question: "If we were going to build Skeleton today, what would we do differently?". Turns out the answer is: a lot! Though we think these changes are healthy for life and longevity of the project. The update to Svelte 5 serves as a prime example of this.

Is it possible to migrate from a Skeleton v2 project?

Yes, we've provided a migration guide for this process. Though please be aware it's an involved process. And that Skeleton v3 is not yet ready for production.

Should I begin testing the Skeleton v3 Beta?

Yes, please do! And make sure to submit feedback on what you think! We can only improve what you communicate to us!

Reporting Issues

Please report all issues via GitHub, Discord, or the comments section below.

[bhuynhdev]

Comment about V3 preset naming scheme: May I ask why are there two shades? It is not easily understandable what each shade is responsible for, and in all presets, both the shade always add up to 1000, so why use two shades at all?

[endigo9740]

Hey @bhuynhdev are you referring to color pairings?
https://next.skeleton.dev/docs/design/colors#pairings

We still need to flush out the docs for this a bit more, but this was a feature we also supported in past versions:
https://www.skeleton.dev/docs/tokens#color-pairing-chart

In Tailwind light and dark mode colors are assigned like this:

<!-- green in light mode, overwritten as red in dark mode -->
<div class="bg-green-500 dark:bg-red-500">

In Skeleton we pair certain combinations of shades like 50 and 950 to ensure an even balance when flipped between light/dark mode. So imagine something like for your <body> element:

<div class="bg-surface-50 dark:bg-surface-950">

You might end up writing these "paired" classes over and over, so Skeleton offers a shorthand for this:

<!-- Shade 50 for light mode, shade 950 for dark mode -->
<div class="bg-surface-50-950">

This actually works very similar to the official CSS syntax that's only recently be standardized in browsers.

[bhuynhdev]

Ah I see, that does very make sense. Then I hope that the docs in https://next.skeleton.dev/docs/design/presets could say .preset-filled-{color}-{lightModeShade}-{darkModeShade} instead of the current .preset-filled-{color}-{shade}-{shade}

[endigo9740]

Agreed! Now that we have the core features in place, a lot of our focus between now and launch will be updating and improving the documentation exactly like that. It's a process though, so we appreciate your patience in the meantime!

[atollk]

I just tried out v3 on my old v2 project and I have to say, I didn't get far during the migration before stopping and reverting. Mostly, the presets just seem like a huge downgrade over variants.

First, it's just more work on my side to get something decent. Second, even if I put in the work, it looks worse than before.

In v2, I can just do class="card" and have something decent looking. And if that's not enough, just adding a simple variant gives me a good looking result.

In v3, a pure "card" is unstyled, so I have to add a preset. I don't get why the light mode shade and dark mode shade are both part of the preset if they are always balanced; this seems like unnecessary clutter, exactly opposite to the principles of Tailwind. Some variants, like "ghost" apparently were removed entirely? Even after playing around with all possible presets, all looked way to saturated and cartoony (I compared the v2 "skeleton" theme with v3 "legacy").

Either I am completely missing something, in which case I hope the documentation will be improved. Or the presets are really this bad (in my opinion) compared to previous variants, in which case I hope their general concept will be changed before v3 is considered stable.

[endigo9740]

Hey @atollk thanks for testing and the feedback.

Mostly, the presets just seem like a huge downgrade over variants.

The majority of Presets are functionally identical to Variants, just with a change in class name. That said, we did greatly expand the number of options due to the expanded color contrast values opening the use of color pairings. To be specific here:

v2:

variant-filled-primary

v3

preset-filled-primary-500 <-- matches v2
preset-filled-primary-50-950 <-- new in v3

First, it's just more work on my side to get something decent. Second, even if I put in the work, it looks worse than before.

Would you mind sharing some specific code samples for which variant/presets you've used and screenshots to compare the results? We need specific examples to compare if you want us to act on this feedback. What you may be seeing is new color balance changes to the updated v2 themes in v3 rather than anything related to presets themselves.

In v2, I can just do class="card" and have something decent looking. And if that's not enough, just adding a simple variant gives me a good looking result.
In v3, a pure "card" is unstyled, so I have to add a preset.

There's two reasons for this change to cards:

1. None of our other comparable feature implemented built in background/text styling (buttons, badges, etc) so this brings expectations in line for new users
2. Tailwind really struggles with precedence issues if you have multiple classes setting the same values (bg, text, etc). So stripping the defaults means we guarantee your defined styles will come through.

FYI we are working on a migration CLI that will implement the following in your global stylesheet as a temporary solution until folks can update each card individually:

.card { @apply bg-surface-100-900; }

But again, the expectation is each implementation of card should be updated, similar to buttons, chips, etc.

I don't get why the light mode shade and dark mode shade are both part of the preset if they are always balanced; this seems like unnecessary clutter, exactly opposite to the principles of Tailwind.

I think there may be some misunderstanding of color pairings here. We've heard this feedback a lot (even in v2) and will have more documentation around this in v3 soon, but pairings can help ensure a uniform visual hierarchy when toggling between light/dark mode. If you don't want the colors to have uniformity then you may want to implement your own base/dark mode classes. That choice is completely your own. You're not forced to use variants or presets.

Some variants, like "ghost" apparently were removed entirely?

Quick note, "ghost" was a misnomer for the styles it represents. Ghost should be the absence of styles (like a btn without a preset).

That said, the goal with Presets is to provide primitive utility classes, but still allow you to mix and match to reach your desired visual style. You can pair the tonal + outlined or tonal + border styles to replicate the v2 look. This is how utility classes are intended to work - you mix and match multiple small primitives to make something more complex. Tailwind covers some of this here.

Even after playing around with all possible presets, all looked way to saturated and cartoony (I compared the v2 "skeleton" theme with v3 "legacy").

Once more, this is likely the change in balance to the theme rather than the features utilizing the colors. Again I'd recommend you shared what specific presets/theme combos you used and/or screenshots if possible. We've heard similar feedback from users switching from soft -> tonal. Was this what you were trying?

Either I am completely missing something, in which case I hope the documentation will be improved. Or the presets are really this bad (in my opinion) compared to previous variants, in which case I hope their general concept will be changed before v3 is considered stable.

I'll just remind you this is a beta. We're intentionally putting it out to request folks to test and provide constructive criticism and feedback. As I've stated a couple times above, if you can provide us more specifics, we're happy to look into this.

Since there may need to be some back and forth conversation, I'd suggest filing this as a new issue here on GitHub please. Those are more actionable for us.

[atollk]

Regarding the colors: As you said, partially I was comparing soft to tonal. Also, I noticed that subconsciously I was influenced by the change of the text font used in buttons (everywhere?). Is that an intended change?

Also, regarding cards, I often use "unstyled" cards, i.e. without variants, in my project. I tried your suggestion with bg-surface-100-900 and it brought the v3 result closer to v2 but it's still not there:

This is v2 "skeleton" vs v3 "legacy". I think everything seems darker in v3? I suppose that's one of those color balances changes you mean? But also, the variant-less card in v2 has a thin border added to it, which is not covered by your snippet.

If you don't want the colors to have uniformity then you may want to implement your own base/dark mode classes. That choice is completely your own.

Sure, but assuming I want to use the Skeleton presets: Why is preset-filled-primary-50-950 not called preset-filled-primary-50?

All in all, I kinda get that the idea is that everything will be more customizable in v3 but this has the cost of introducing complexity and losing convenience. This seems more like a different library to me with a different target audience than a version upgrade

I'd suggest filing this as a new issue here on GitHub please. Those are more actionable for us.

I wouldn't mind to do that, but the "feedback" category when creating an issue directs me to the discussions :)

[endigo9740]

Regarding the colors: As you said, partially I was comparing soft to tonal. Also, I noticed that subconsciously I was influenced by the change of the text font used in buttons (everywhere?). Is that an intended change?

Thanks for the clarification. Soft and tonal represent a similar style, but are not 100% identical. This is intentional. To provide a quick summary:

• soft: this takes the shade 500 value (the main "brand" color) and lowers the opacity to provide a faded look
• tonal: this uses color pairings around 100/900 for light/dark mode respectively and do not have transparency.

This change brings two main benefits

1. It ensures more consistent results since the background color/imagery doesn't bleed through.
2. It uses our new expanded color contrast values (now available for EVERY shade in v3) to help ensure color contrast a11y

It's a safer way to approach this aesthetic if accessibility is important to you - which it is to us. That said, if the soft approach is desired, we may bring it back. Just note the risk here.

Also, regarding cards, I often use "unstyled" cards, i.e. without variants, in my project. I tried your suggestion with bg-surface-100-900 and it brought the v3 result closer to v2 but it's still not there:
This is v2 "skeleton" vs v3 "legacy". I think everything seems darker in v3? I suppose that's one of those color balances changes you mean? But also, the variant-less card in v2 has a thin border added to it, which is not covered by your snippet.

This is in part due to the theme. In v3 we've now followed Tailwind's lead and moved from palettes containing shades 50 to 900, to now using 50 to 950. From 10 to 11 shades total. Due to the extra shade the balance works a bit different. But IMO will be better overall. You now have an even amount of light and dark shades with 500 perfectly balanced in the middle to act as the brand-specific tone. The result will be a slightly offset contrast in dark mode though.

Sure, but assuming I want to use the Skeleton presets: Why is preset-filled-primary-50-950 not called preset-filled-primary-50?

The short answer: color pairings. They are preset mixes of base/dark mode colors, or light/dark mode as you may understand it. Imagine writing color classes like this:

bg-primary-100 dark:bg-primary-900

The "pairing" for this would be:

bg-primary-100-900

It's not just shorthand, it also ensures you're always using the same pair of tones in light and dark mode to ensure the hierarchy matches. Think of this hierarchy like layers, so in dark mode this might be:

800 <- input backgrounds
900 <- card backgrounds
950 <- app background (bottom layer)

But in light mode it would be:

200 <- input backgrounds
100 <- card backgrounds
50 <- app background (bottom layer)

To to ensure we don't accidently go "off" a step, we make well defined pairs of colors, like 50-950 would be your desired pairing for your app background. Again pairings are optional, but VERY useful if used properly. So this is the kind of info we want to explain better and visualize for folks and will be doing so in the docs asap.

All in all, I kinda get that the idea is that everything will be more customizable in v3 but this has the cost of introducing complexity and losing convenience. This seems more like a different library to me with a different target audience than a version upgrade

I can empathize with that thought if you're coming into v3 expecting an incremental update. But v3 represents nearly a year of progress, a ground up rewrite, and rethinking a lot of the core concepts to ensure we're establishing a foundation we can build off of for the next few years. Change can be painful, but sometimes it's necessary. Hopefully you and others will give it a chance!

I wouldn't mind to do that, but the "feedback" category when creating an issue directs me to the discussions :)

Just FYI, I'm the core maintainer, so if I'm asking folks to move something, I typically have a good reason to. In this case, I'd rather our beta announcement not become a troubleshooting session for a single user. A new Discussion thread would also suffice. Make sense?

[codercms]

I've found documentation inconsistency, doc states that the Popover, Modal and Tooltip components could have custom trigger element such as button

But actually there's already hard-coded button provided with no way to override it:

skeleton/packages/skeleton-svelte/src/lib/components/Modal/Modal.svelte

Lines 69 to 72 in 67e6918

	{#if trigger}
	<button {...api.getTriggerProps()} class="{triggerBase} {triggerBackground} {triggerClasses}">
	{@render trigger()}
	</button>

skeleton/packages/skeleton-svelte/src/lib/components/Popover/Popover.svelte

Lines 60 to 63 in 67e6918

	<!-- Snippet: Trigger -->
	<button {...api.getTriggerProps()} class="{triggerBase} {triggerBackground} {triggerClasses}">
	{@render trigger?.()}
	</button>

skeleton/packages/skeleton-svelte/src/lib/components/Tooltip/Tooltip.svelte

Lines 55 to 58 in 67e6918

	<!-- Snippet: Trigger -->
	<button {...api.getTriggerProps()} class="{triggerBase} {triggerBackground} {triggerClasses}">
	{@render trigger?.()}
	</button>

[endigo9740]

@codercms thanks for the heads up, yeah I agree that should be changed. I'd ask that you submit similar issues in the more formal sense here on GItHub. Comments here are useful for discussion, but issues are actionable for us. I've handled this for you:

• NEXT Svelte Popover snippet has inaccurate description #3044

[codercms]

P.S. It would be nice if Menu component from zag will be supported by Skeleton

[endigo9740]

@codercms The allotment of components we have now are what we will launch v3 with, but we are keen to expand to include more components in the future. To set expectations though, we likely will not support the Menu, as we already have the Popover which is a generic take on this.

Additionally, we don't plan to support these single use components forever, but rather see them as a temporary solution until we can finalize the upcoming Floating UI Svelte library, as stated in the warning on our Svelte Popover documentation.

At that point, users will then have a much more open ended solution for building popover interfaces of any form. Which of course will be a stand in until both the Popover API and CSS Anchor APIs become standardized across all browsers. At which point we will recommend those options as the de-facto solution.