NEXT: Tailwind Plugin

[endigo9740]

This will act as a hub to centralize for this information.

See Also

The following updates will likely need to be handled in coordination.

• NEXT: New Theme Generator #1142
• NEXT: Improved dark mode support #2359

Tailwind Directive Layers

• base - global styles, resets, etc
• components - for opt-in element styles, like .btn
• utilities - general purpose utility classes
• variants - to append new variants, like hover: and md:

Maintainer Requests

The following requests are coming straight from the Skeleton team. These are highly likely be implemented:

• Implement skeleton utility classes via theme.extend over standalone classes
• Explore using @apply directly in the tailwind plugin's CSS-in-JS objects (reference)
• Reorganize current styles; distribute to Tailwind directive layers
• Updated Tailwind > Blocks to something more akin to the OpenAI cookbook
• Update Chrome scrollbar styles to new spec
• Update theme type definitions to support all changes (removing properties_dark, etc)
• A fix for the OS dark mode setting. See the issue outlined here.
• Implement @AdrianGonz97 suggestion for a simpler theme import method
• @AdrianGonz97 please see @niktek question regarding exec scripts here
• Aim to make config.content simpler for core/svelte/react (reference) (wait until TW v4)

Design Tokens:

• Revisit the token prefix/suffix concept after implementing with theme.extend
• Design token background styles should follow Material Design's naming scheme (ex: Ghost -> Tonal)
• The concept of "Variants" should be revisited; consider folding these into design tokens
• We need to make the concept of "color pairings" more clear; lots of confusion around these

Tailwind Components (aka "Elements")

NOTE: expect many minor revisions to all element styles provided by Skeleton.

• Revisit Input-Groups; these have never quite worked as expected
• Revisit Button-Groups these have never quite worked as expected
• The table component will be retired in favor of the Table elements; consider making this more piecemeal

Cookbook (replaces "Blocks")

• Chat
• Gradient Headings
• Image Layouts
• Scroll Containers

Community Requests

The following requests have come from the community and are under consideration:

• Implement scrollbar gutter styles into base styles #2301
• Button sizing when in group #2003
• A new stroke-token? #2444
• Use :host instead of :root to declare theme color variables #2167 (will not implement)

Bugs and Issues

• Bug with select dropdown menus on Windows
• There's a display issue for App Headers + the lightmode Rose theme in the documentation
• Clicking edge of button doesn't work #1789

Feedback

If you have additional updates or requests for this feature, please do so in the comments section below.

[AdrianGonz97]

Follow-up after the discussion in this thread: https://discord.com/channels/1003691521280856084/1196891462302957608

A change we can do is to expose all of the preset themes in an ESM format (so that they are importable in the user's app) and change the plugin api that registers them.

So rather than doing this (current):

// tailwind.config.js

// user's custom themes
import { myCustomTheme1, myCustomTheme2 } from "./customThemes.js";

/** @type {import('tailwindcss').Config} */
export default {
	// ...
	plugins: [
		skeleton({
			themes: {
				custom: [
					myCustomTheme1,
					myCustomTheme2
				],
				preset: [
					{ name: 'crimson', enhancements: true },
					{ name: 'gold-nouveau', enhancements: true },
					{ name: 'hamlindigo', enhancements: true },
					{ name: 'modern', enhancements: true },
					{ name: 'rocket', enhancements: true },
					{ name: 'sahara', enhancements: true },
					{ name: 'seafoam', enhancements: true },
					{ name: 'skeleton', enhancements: true },
					{ name: 'vintage', enhancements: true },
					{ name: 'wintry', enhancements: true }
				]
			}
		})
	]
};

We can instead unify the api such that custom themes and presets are registered to the same interface (v3):

// tailwind.config.js

// they can all be imported via an import glob
import * as themes from "@skeletonlabs/skeleton/themes";
// or imported individually like so:
import { modern, rocket } from "@skeletonlabs/skeleton/themes";

// user's custom themes
import { myCustomTheme1, myCustomTheme2 } from "./customThemes.js";

/** @type {import('tailwindcss').Config} */
export default {
	// ...
	plugins: [
		skeleton({
			themes: [ 
				myCustomTheme1,
				myCustomTheme2,
				themes.crimson, 
				themes.goldNouveau, 
				themes.hamindigo,
				modern,
				rocket,
				// etc..
			]
		})
	]
};

[endigo9740]

@AdrianGonz97 I love it. Huge quality of life improvement there because it's one less thing to think about. Themes are just themes. I've added it to the list in the OP.

[niktek]

In regards to the darkMode issue - basically we need TW to generate different sets of classes depending on the darkMode strategy selected (also note that there has been an update https://tailwindcss.com/docs/dark-mode#toggling-dark-mode-manually to the names). As this is a build time artefact and will be static for our end-users, we can create two TW configs here for embedding into the package.

Then on end-user load of the skeleton plugin, we need to get the darkMode setting for their project and use that to determine which generated CSSinJS module we import to pass back to TW.

TW does not pass the full config settings to the plugins, either via withOptions or by destructuring the theme on plugin init.

Considering the myriad of project setups/frameworks/monorepos etc that could come into play to try and find the tailwind config file to then parse, the safest option I can see is to parse the callStack and get the calling file from there:

in packages/skeleton/src/plugin/core.ts

export function getSkeletonClasses() {
	// try/catch because it will throw when generated-classes.js isn't generated yet
	try {
		const error = new Error();
		// Extract stack trace from the Error object
		const stackTrace = error.stack ?? 'not found';
		const regex = /at registerPlugins \(([^()]+?)\/node_modules/g;
		const match = regex.exec(stackTrace);
		let path = '';
		if (match) {
			path = match[1];
		}
		const config = readFileSync(path + '/tailwind.config.ts', 'utf-8');
		writeFileSync('/Users/Shared/blah.txt', path, 'utf-8'); //purely for debug as console.log is trapped in the child process 

		const { components, base } = require('./generated/generated-classes.cjs');

This returns an absolute path to the folder containing the tailwind.config for me on macOS node and bun. It needs further testing on other platforms etc.

We should then be able to import/parse it and get the mode to then know which generated file to return from above.

Gut feeling says it would be bad to require() the users tailwind config in case of side effects. It is also not guaranteed to just be 'selector' | 'media' as can be seen here

[endigo9740]

@AdrianGonz97 @niktek we've completed pretty much everything slated for the Tailwind plugin in this ticket, minus the issues Nik brought up above. If you guys want to suss that out separately then please go for it. Feel free to create a standalone ticket.

To everyone -
We'll likely continue to tweak/adjust/add themes, CSS styles, etc., however I think we can consider the plugin to be in a solid place. As such I'm going to go ahead and close this ticket. This is a huge milestone towards v3, so thanks for all the help on this one!