A lot Skeleton utilities don't actually exist

[rChaoz]

Current Behavior

For example, base-font-color, base-font-size etc., they are documented, and the migration script will use them (e.g. text-token becomes base-font-color), but they don't actually exist. They only exist as CSS variables.

This seems to apply to all of these:

https://github.com/skeletonlabs/skeleton/blob/c7cdd2a10ee28bb5037ac52655b69862204af732/packages/skeleton/src/base/theme.scss#L17-L44

Tailwind is supposed to generate utility classes for everything in @theme, but I'm guessing because they're all inherit it can't tell what they are (colors, dimensions etc.)

Workaround

Use the variables directly, e.g. text-(--base-font-color).

[endigo9740]

Tailwind is supposed to generate utility classes for everything in @theme, but I'm guessing because they're all inherit it can't tell what they are (colors, dimensions etc.)

That sounds like a bug on Tailwind's end. I might suggest asking upstream on Tailwind's support to see if they can confirm the expected behavior here. Like you I'd expect if these are in @theme the class would exist.

Per their docs I don't see any exceptions for this unless I'm missing something:

https://tailwindcss.com/docs/theme#what-are-theme-variables

Setting values other than inherit would actually be detrimental, so I wouldn't consider that a solution here.

[rChaoz]

I agree, but I also believe this is an issue on Skeleton's part. Should Tailwind generate the classes directly, then it would be text-base-font-color, not base-font-color, as the docs suggest. Other classes like bg-base-font-color or even rounded-base-font-color would exist as well (since it can't know it's a color). I doubt that would be the intended behaviour.

I'm siding with Tailwind on this one. I think utilities should be added manually for these variables, to match the Skeleton docs.

However, maybe if the variables were declared with @property instead, Tailwind would generate classes.

[endigo9740]

Quick follow up - here's a demo on the Tailwind Playground

https://play.tailwindcss.com/lYrbCM9OJF

It looks like Tailwind's @theme convention only works with their very specific namespaces. Unfortunately it does mean a lot these custom theme properties for Skeleton will not have auto-generated classes. To correct these we would have to adapt Tailwind's conventions like this:

• before: --base-font-color
• after: --color-base-font

This is a breaking change, so not possible without a major point release.

So we have a couple follow up options here:

1. Implement custom design token classes that consume the raw theme values - an unfortunate short term solution
2. Convert our theme properties to follow their conventions - will have to wait for a major release

Unfortunately this is the kind of thing that occurs when our hand is forced to rush and support things last minute. So we'll learn, implement the proposed fix above asap, then rework this in a v4 release in the future - or as time allows.

There's really no other option here.

[rChaoz]

It seems like it does in fact use namespaces, and that this is documented here: https://tailwindcss.com/docs/theme#theme-variable-namespaces

[rChaoz]

As for

then rework this in a v4 release in the future

it would be great if this could be done now, as SemVer is intended to be used (TL;DR it sucks that major version became a marketing number rather than a breaking change number), but regardless either solution is fine.

[endigo9740]

I'm aware, I spent three weeks rewriting everything from scratch. But I think it's a very easy mistake to make to assume custom namespaces were possible too. So that's why we've landed here.

For now if folks need to use the properties - I'd advise creating local classes to consume the properties for now:

.base-font-color { color: var(--base-font-color); }

With the understanding we'll fill in this gap in an update asap, and the more proper fix in the next major version.

[endigo9740]

it would be great if this could be done now, as SemVer is intended to be used, but regardless either solution is fine.

I'm not pushing out another major breaking change and migration to our users this soon. There's a limit and we're already riding that with everything v3 changed. I will, however, make a post this week to inform folks of this and a few other issues we've been made aware of with the TW4 update, like this gem:

https://github.com/tailwindlabs/tailwindcss/pull/16631

[rChaoz]

I'm aware, I spent three weeks rewriting everything from scratch. But I think it's a very easy mistake to make to assume custom namespaces were possible too. So that's why we've landed here.

I totally agree, I didn't mean that to sound like it's something you shouldn't have missed, sorry if it came out that way. I just found out about it now myself, that's why I linked it.

[endigo9740]

Nah nah, all good, I'm annoyed at Tailwind. We've seen a LOT of instances where it seems v4 was pushed out undercooked. Their two month beta and like 1 day release candidate really missed the mark for such a substantial change.

[rChaoz]

Personally I'm annoyed that their intellisense/language server seems to barely support v4, the documentation still mostly referencing tailwind.config.js. And that I've spent like 3 hours debugging why intellisense simply wasn't working at all.

[endigo9740]

Yeah I'd recommend a quick browse through their issue and discussions section on GitHub. There's a been a LOT pop up since launch.

Just the things I'm aware of that's affected Skeleton or our users so far:

• The Vite plugin kinda works without @source, but it's a false-positive due to caching. It'll eventually stop working.
• The @source path can be the NPM module itself, but has to be the /dist directly to work around a bug
• The Vite issue I mentioned above means we might have to bring back the PurgeCSS plugin to remove undesired classes
• OS Preference for dark mode doesn't work in Safari, but only in a dev server, in production it's fine
• The docs can be really spotty, sometimes flipping between multiple implementations, ex: @layer components vs @utility

And that's all without me misinterpreting how @theme works.

I think it will eventually settle into a really good release, most changes are worthwhile and will be better in the long run. But some of the issues are real head scratchers.

As always, we will try to keep ahead of this stuff and fix what we can as we can to help users. But a few of these may breaking changes to fix, so I think Skeleton v4 may become a Tailwind v4 bugfix update at this rate.

[endigo9740]

Note that the short term fix to auto-generate these classes for end users is now in place per #3442 from @rChaoz

We will revisit this leading up to the "next" release (such as v4) to modify the theme properties so they are auto-generated by Tailwind's @theme directive. This should likely be considered alongside the Theme Generator rewrite. As such I'm moving this ticket to the v4.0 milestone.

[endigo9740]

Quick update: we've opted to focus on components for v4, but we plan to focus on the Design System and Theme Generation in v5. This will carry over to that.