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:

skeleton/packages/skeleton/src/base/theme.scss

Lines 17 to 44 in c7cdd2a

	--base-font-color: inherit;
	--base-font-color-dark: inherit;
	--base-font-family: inherit;
	--base-font-size: inherit;
	--base-line-height: inherit;
	--base-font-weight: inherit;
	--base-font-style: inherit;
	--base-letter-spacing: inherit;
	/* --- */
	--heading-font-color: inherit;
	--heading-font-color-dark: inherit;
	--heading-font-family: inherit;
	--heading-font-weight: inherit;
	--heading-font-style: inherit;
	--heading-letter-spacing: inherit;
	/* --- */
	--anchor-font-color: inherit;
	--anchor-font-color-dark: inherit;
	--anchor-font-family: inherit;
	--anchor-font-size: inherit;
	--anchor-line-height: inherit;
	--anchor-font-weight: inherit;
	--anchor-font-style: inherit;
	--anchor-letter-spacing: inherit;
	--anchor-text-decoration: inherit;
	--anchor-text-decoration-hover: underline;
	--anchor-text-decoration-active: inherit;
	--anchor-text-decoration-focus: inherit;

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:

tailwindlabs/tailwindcss#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.