Skeleton v3 Release Candidate 2 🎉

[endigo9740]

Hey everyone, Chris here from the Skeleton team. Today we're thrilled to share the newest release candidate for Skeleton v3. This represents what we hope to be the final stage of development leading up to our official full release.

Release Candidate Naming

We're using the follow semantics to refer to each Release Candidate version:

• RC1 (Release Candidate 1) - the older version of Skeleton v3 that only supported Tailwind v3 and Zag pre-release
• RC2 (Release Candidate 2) - the new version of Skeleton v3 that now supports Tailwind v4 and Zag 1.0

Useful Links

• v3 Documentation: https://next.skeleton.dev/
• v3 Theme Generator: https://themes.skeleton.dev/
• v3 RC1 Announcement: Skeleton v3 - Release Candidate 1 🎉 #3062

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

• Create a new Skeleton v3 project

Migration Guides

• Migrate from Skeleton v2
• Migrate from Skeleton v3 RC1

Skeleton v2 End of Life

Warning

Please be aware that the full launch of Skeleton v3 will result in Skeleton v2 reaching end of life:

• Notice of End of Life for Skeleton v2 #3063

What's New in the RC2

Tailwind v4 Support

We recently delayed Skeleton v3 to add full compatibility with Tailwind v4. Below we'll highlight a few of the most notable changes.

• Full support for Tailwind's v4.
• Removed Skeleton's Tailwind plugin in favor of Tailwind's new CSS-base configuration.
• All Skeleton core API feature are now authored using native CSS + Tailwind directives (no more @apply)
• Skeleton now supports Color Scheme, for isolated toggling of light or dark interfaces at any scope.
• Skeleton Presets are now optional (but still recommended for new users)
• Skeleton themes have been overhauled with a number of improvements:
  • Converted from a Javascript-based format, to a native .css file format and CSS custom properties
  • The Typographic Scale is now applied to Tailwind's text-* classes; all type-scale-* properties were removed
  • Now support any valid CSS color format; though we're aiming to standarize on OKLCH.
  • Modifed some theme properties to follow Tailwind's built-in namespaces and enable new features
• The theme importer plugin the Figma UI Kit has been updated to support the new format.
• Replaced Skeleton's custom spacing feature with Tailwind's v4 equivilant feature.
• Color Pairings now utilize CSS native light-dark() functions to enable Color Scheme support
• Color Pairings now support transprancy (ex: bg-primary-50-950/60)
• And more!

Please refer to our onboarding guides or migration links (listed above) if you wish to get started.

Zag 1.0 Support

Warning

The initial RC2 release will only include Tailwind v4 updates, but will be followed shortly by the upcoming Zag 1.0 updates.

Skeleton v3 uses Zag.js as the foundation for all Skeleton cross-frameworks component features and APIs. Zag 1.0 has recently launched with a major performance boost, so we'll be updating to include this before the full launch of Skeleton v3. This is not a breaking change for most use cases, however for Svelte users, we plan to use this opportunity to move away from $bindable() to a new cross-framework friendly standard for data input/output. Here's a quick example:

<Example bind:value="{someState}" />

<Example value="{someState}" onValueChange="{onValueChangeHandler}" />

What's New in the RC1

Please refer to this post for the specific list of changes provided in RC1.

What's New in Skeleton 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.
• New and improved Theme system and Theme Generator with nearly 3x the custom CSS properties
• Greatly improved color system, including Color Scheme support for color pairings.
• Overhauled Presets system
• Overhauled Typography system
• A brand new Spacing system, for dynamic spacing based on a scaling factor
• An opinionated Iconography integration guide.

Skeleton Core Features

• Full support for Tailwind v4
• 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 frameworks 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 a "Release Candidate" mean?

For us, this means the Skeleton next branch is both feature complete and near production-ready. In the following week's we'll continue refine and improve both the library and documentation until we feel it's ready for the full release.

Is the v3 RC2 ready for production?

Not quite. While we consider the v3 RC to be feature complete, a small allotment of issues to address. Aside from the Zag 1.0 changes mentioned above, we're not aware of any other major breaking changes coming between now and release. Though always reserve the right to.

Why does Skeleton v3 have 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 updates to support Svelte 5 and Tailwind v4 serve as a prime examples of this.

Is it possible to migrate from a Skeleton v2 project?

Yes, we've provided a migration guide for this process.

Should I begin testing the Skeleton v3 RC2?

Yes, please do! And make sure to submit feedback on what you think! We can only improve what you communicate to us! We can't promise every request will make it before launch, but we will continue to publish maintenance release at our usual cadence post-release.

When will Skeleton v3 Launch?

With the launch of the Tailwind v4 and Zag 1.0 features, we're going to be listening to community feedback from early adopters. As well as implementing some last minute bug fixes and stability improvements. Once we feel these are adaquately resolved, we will begin the launch process. Likely before the end of March 2025.

Reporting Issues

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

[rChaoz]

Awesome work, all of this looks great! 🚀

There's a few things I noticed on the website. The hover styles for presets seem to be gone, buttons no longer do anything on hover, I think this is because of the presets rewrite, but I believe it was not intended, The light/dark mode switcher breaks after any navigation (need a hard refresh to fix it again). Also, I think it color parings could be written as background-color: #light-color; background-color: light-dark(...), so if the feature is not supported, at least the light mode color is displayed.

however for Svelte users, we plan to use this opportunity to move away from $bindable() to a new cross-framework friendly standard for data input/output

This, I really don't like. Reverse (child -> parent) data flow is one of the big reasons I moved away from React (and I'm sure I'm not alone). There's so many advantages to bindings that I really wouldn't want to lose (optional, less boilerplate). I totally understand why you'd want similarity between the implementations, but the whole point of Svelte is that it's not similar to React. Please don't make Svelte feel like React!

Anyway, sorry for all the yapping. Everything related to v3 looks amazing, especially the customizability/themes, switching through the variants really feels like you're going between different websites, rather than different colors. I'll definitely try to migrate ASAP!

[endigo9740]

@rChaoz I started an internal thread with the team to get their feedback on the hover state change for buttons. Everyone is in different time zones so it may take a bit for replies to trickle in. But I'm still thinking about it myself.

I know the know we all kind of default to "add more options", but options have a cost. Both in terms of maintenance, education, and end user experience. I'd rather we buy into this being built in or not.

Personally I'm trying to decide if there's a happy medium here. Like we keep things as is, but introduce an additional section on the Button and Chip docs that explain how to handle this. Which if you want to replicate the RC1 styles would literally be drop this in your global stylesheet:

.btn, .chip {
   filter: brightness(90%);
   @variant hover { filter: brightness(110%); }
}

If you're on RC2 this should work right now. Feel free to try it and see what you think.

That doesn't seem like a huge ask of folks, and it leaves the door open for users to diverge and handle handle hover states in any other way they wish.

[stalkerg]

It doesn't follow the traditional data down, events up pattern shared across frameworks, this makes implementation challenging as we are framework agnostic.

As I remember, there was at least one promise not to provide compromises for Svelte users (at least significant).

You can't spread them, so {...attributes} is impossible, since you need to do bind: explicitely (very important for component library authors)

I think it's totally fine for input-like components.

It's an async update, meaning that you'll receive the update in the next tick rather than directly when using a event handler.

If I am using bind, I have reactivity to react to this, I am not too worry about events and ticks.

Svelte themselves recommend against it: "This isn’t something you should do often, but it can simplify your code if used sparingly and carefully."

Exactly! For many custom component cases, it's the wrong choice, BUT if your component replaces input or select, it's totally fine to use bind. The current design is very unnatural for Svelte.
I can agree that for some abstract values, a new approach can be better, but for any input it's odd. Example:

// I  can do next
<input bind:value={myValue} />
// but for some reason, I can't do it for
<Rating bind:value={myValue} />

It's very confuse, if component have value it should be bindeble, other parameters can be set by events.

Also:

<Rating value={myValue} onChangeValue={(e) => (myValue = e.value)} />

It means after myValue is changed, we will send a signal and will try to update the Rating value again! I suppose it's in efficient.

I am a big fan of Skeleton and Svelte, and I feel it's going in the wrong direction now. I hope my feedback will be valuable for you.

[stalkerg]

The only thing users will have to change is change bind: to onValueChange.

It's working differently, and you need to write 10 extra characters. Yeah, technical arguments exist, but they're weak, I understand. At the same time, semantically, it's odd. By the way, I started using Svelte from 1.0, and binds was one of the reasons. Recently, people started migrating from other frameworks and doing critics. Now, I think we have three parties in Svelte: old users, new users, and libs developers. bind: it's really liked by old users mostly. :(

[endigo9740]

@stalkerg you've now posted in three places sharing your feelings on this change:

• Feature: Zag 1.0 #3257 (comment)
• Zag 1.0 Support #3258 (comment)
• (and here)

I've already made this request to view our explanation of the change, and begin a conversation here:

• Zag 1.0 Support #3258 (comment)

You've now chosen to ignore my invitation and respond in a thread that doesn't have this context, and instead chose to dogpile on the subject over here.

I'm sorry, but this feels like a bad faith argument. The team and I are happy to engage in a discussion with anyone that would like to bring forth constructive criticism. We always encourage such. But if you're going to ignore our half of the conversation and throw out phrases like this:

Yeah, technical arguments exist, but they're weak,

Then I'm not sure we can do much to help you.

If the change is not to your liking, we've heard you. If you would like to engage in a real conversation on the subject, the open invitation above still stands. If you would like to educate yourself on the significant reasons (plural) for the change, the other thread is available. And if this is a dealbreaker for you in Skeleton, then we're sorry and hope you find a great alternative that suites your needs.

[stalkerg]

You've now chosen to ignore my invitation and respond in a thread that doesn't have this context, and instead chose to dogpile on the subject over here.

Sorry, it's because @Hugos68 point me this thread and I supposed it's the main thread about this issue, especial if some arguments already here. Also, seems like timing is wrong, and I read messages in the wrong order. My apologize.

[codercms]

Hey, awesome work!
Just want to ask, is it intended change that the different controls have different placeholder colors?

My app.css:

@import 'tailwindcss';
@plugin '@tailwindcss/forms';

@source '../node_modules/@skeletonlabs/skeleton-svelte/dist';

@import '@skeletonlabs/skeleton';
@import '@skeletonlabs/skeleton/optional/presets';
@import '@skeletonlabs/skeleton/themes/cerberus';

@custom-variant dark (&:where(.dark, .dark *));

app.html:

<!doctype html>
<html lang="%paraglide.lang%" dir="%paraglide.textDirection%" data-theme="cerberus" class="dark">

And +page.svelte:

<div class="max-w-96 space-y-4">
	<input type="text" class="input" placeholder="Input placeholder..." />
	<Combobox data={[{label: "Hey", value: "hey"}]} placeholder="Combobox placeholder..." />
</div>

CSS for input:

CSS for ComboBox input:

Package versions:

"@skeletonlabs/skeleton": "^3.0.0-next.12",
"@skeletonlabs/skeleton-svelte": "^1.0.0-next.21",
"tailwindcss": "^4.0.9",
"@tailwindcss/forms": "^0.5.10",
"@tailwindcss/vite": "^4.0.9",

[endigo9740]

No, it's a known issue that will be addressed here: #3294