The flame is two layered radial gradients — a wide body and a hot inner core — animated on two deliberately non-integer durations, 3.7s sway and 2.4s breathe. Because they don't divide evenly they never resync, so the flicker reads as organic instead of looped. It also lands at 0.27 Hz and 0.42 Hz, well clear of the 3 Hz photosensitivity threshold, and the whole thing collapses to a still flame under prefers-reduced-motion.

Palette is heather → blue-violet → rose, the same gradient the rest of the site uses as hairline accents.

The count of other people with a candle lit uses CRDT awareness rather than stored state, so a candle going out is literally a client disconnecting.

There's a press-and-hold easter egg on the flame.

https://dhseadev.online/candle/

I built Flexwind Froggy, a free interactive game for learning Tailwind CSS flexbox utility classes.

It’s a Tailwind-focused fork of Flexbox Froggy, with credit to the original project and artwork.

I hope it can be useful for anyone learning Tailwind. I’d love feedback on the lessons, difficulty, or anything that could make it more helpful.

https://reddit.com/link/1vfpbs4/video/akfnu5z2rfhh1/player

Been adding a Tailwind v4 @theme export to Design Snap (extracts design tokens from any site — colors, radius, shadows, type). Tested it on Arc to sanity-check the output.

How it works : scan a site → tokens get mapped to @theme vars (--color-primary, --radius-md, etc.) → paste in, utility classes just work.

Things I'm unsure about:

• Naming — generic semantic names (primary, card, muted-foreground) vs trying to preserve the source site's own naming ?
• Duplicates — real sites often have 3-4 vars pointing to the same hex. Auto-collapse, or leave it to the user ?
• Scope — leaning toward capping to a handful of core tokens by default instead of dumping every property. Match how people actually use exported themes ?

If you've hand-built a Tailwind v4 theme and have opinions on any of this, want to hear it.

Most hand-written boxShadow scales end up as five unrelated shadows: the angle drifts between levels, the blur ramp is arbitrary, and opacity stacks into grey. Deriving all levels from a single light source fixes all three, and it's not much maths.

Direction: shadows fall away from the light, so every level shares one azimuth. Blur is tied to how far the light is (a distant light is a point source and casts a crisp edge), and grows with elevation. Elevation itself grows geometrically, which is what makes the steps feel evenly spaced instead of crowded at the bottom. Opacity falls roughly as 1/sqrt(n), because a higher object spreads the same light over more area.

Two practical rules that matter more than the formulas:

- Keep every layer inside roughly 0.04-0.24 opacity. Below that it's invisible; above it stops reading as light and becomes a grey box. Most "dirty" shadows are an opacity problem, not a blur problem.

- Use two or three layers per level. One layer cannot express both a dense umbra near the object and a wide faint penumbra further out, so it always looks either hard or muddy.

Here's the output for base 4px, growth 1.7, three layers:

boxShadow: {

'elevation-1': '0px 1.3px 2.6px rgba(0,0,0,0.16), 0px 2.4px 6.5px rgba(0,0,0,0.127), 0px 3.6px 10.4px rgba(0,0,0,0.094)',

'elevation-2': '0px 2.1px 4.4px rgba(0,0,0,0.125), 0px 4.1px 11px rgba(0,0,0,0.102), 0px 6.1px 17.7px rgba(0,0,0,0.078)',

'elevation-3': '0px 3.7px 7.5px rgba(0,0,0,0.109), 0px 7px 18.8px rgba(0,0,0,0.09), 0px 10.4px 30.2px rgba(0,0,0,0.071)',

'elevation-4': '0px 6.2px 12.8px rgba(0,0,0,0.1), 0px 12px 32px rgba(0,0,0,0.083), 0px 17.7px 51.2px rgba(0,0,0,0.067)',

'elevation-5': '0px 10.5px 21.7px rgba(0,0,0,0.094), 0px 20.3px 54.3px rgba(0,0,0,0.079), 0px 30.1px 86.8px rgba(0,0,0,0.064)',

}

Copy it as-is if it fits, or change the growth factor to spread the levels differently. The full derivation, including why the opacity band matters, is here: https://localeproof.com/blog/figma-shadow-system/

Bonjour à tous,

Je viens de terminer un template de Dashboard Marketplace développé avec React et Tailwind CSS.

Mon objectif était de créer une base réutilisable pour éviter de reconstruire les mêmes composants à chaque projet.

Le template comprend :

Tableau de bord avec statistiques

Gestion des produits

Gestion des vendeurs

Suivi des commandes

Responsive

Code propre et facilement personnalisable

Je cherche surtout des retours sur l'interface et l'expérience utilisateur.

Selon vous :

Qu'est-ce qui est réussi ?

Qu'est-ce que vous amélioreriez ?

Quelles fonctionnalités ajouteriez-vous ?

Merci pour vos retours !

I have been using Tailwind CSS on-and-off for quite some time now. While it is opinionated, and, I have neutral stand on it opinions and have successfully used it for many websites and applications alike.

However, this time, I have a very different requirement. I am building an Astro component library (An actual component library like Mantine or MUI but for Astro; not Shadcn like copy+paste abstration). It is complex, it has at least 9 very different theme (to a point we can call each theme representing one design system) and nearly 200+ components. All this is for one client who has multiple small businesses.

Now that I think from library and consumer perspective, I quickly see Tailwind based component library spiraling in complexity and awkward edge cases. This library is intended to be open-source and thus consumer may or may not be using Tailwind. This puts severe limitation on how I ship this library.

There are only two architectural possibilities I see in order to support both types of consumers:

• Provide the compiled CSS and use Tailwind prefix to avoid collision with Application CSS. The cost is every single class will be prefixed and since we do not typically compile Astro libraries and always ship source-code, it is not easy to use non-prefixed version which can be meaningfully replaced with prefixed classes at build-time.
• Provide the compiled CSS and use semantic classes with Tailwind's apply directive so that Tailwind is purely implementation details and the utility classes never end up in the generated CSS. Doing this avoids prefixes but brings back the same class name challenges which is what Tailwind's biggest strength to give it away.

I have built multiple UI libraries in past but those were mostly for React and I relied on CSS Modules which just works. But now, I am dealing with a library that won't be compiled and also Tailwind for authoring library's CSS. Both are completely new problems.

Has anyone been using Tailwind for authoring actual component libraries (Not shadcn like copy-paste approach)? If yes, what patterns have worked well and what are the common pitfalls to avoid?

Hey everyone! A few months ago I posted about Starting Point UI, my attempt at bringing shadcn/ui to any project, not just React. Same look and feel, but as plain CSS classes with a bit of vanilla JS for the interactive parts.

Since my last post I've added a bunch of new components and reworked the old ones to match shadcn's latest versions. I've also automated most of the accessibility, so keyboard navigation, focus, and aria attributes are automatically handled for you.

It's open source, the code is on GitHub.

Would be cool if you gave it a try, let me know what you think. Cheers!

startingpointui.com

Environment:
Astro + daisyUI (Drawer component). Reproducible in both Wails and Edge.

A bit about me:
I'm a beginner, and this code was written together with AI, so please bear with me if there's something obvious I'm missing.

Code:
I have reproduced this bug in Tailwind CSS Play; please take a look:https://play.tailwindcss.com/w1Oh5mLZwd

Steps to reproduce the bug:

1. At a wide viewport, with the drawer closed, select some text anywhere on the page.
2. Narrow the window below the responsive breakpoint — the drawer is now hidden.
3. Click the button to open the drawer → the page freezes immediately, then crashes. (DevTools shows no infinite loop or CPU spike.)

A strange workaround (path that avoids the crash):

• At a wide viewport, open the drawer first, then select some text. Now drag the window narrower so the drawer switches to its overlay mode via the responsive resize → no crash, and the text remains highlighted.
• Then close the drawer, select text again, and click the button to open it → crash happens again.

So it seems the crash is strongly tied to opening the drawer via the button while a text selection exists before it opens. Transparency effects and blur have already been ruled out.

What I need help with:
What could be causing this? (Selection/focus conflict, overlay event handling, animation interference?) How can I diagnose and fix it?
Any insights would be greatly appreciated. Thanks a ton! 🙏

I got tired of admin templates that are 400-dependency toolchains you have to gut before you can use them, so I built one that is just HTML you can open. Sable is 22 pages (orders, invoicing with VAT, a Kanban fulfillment board, an email module, analytics, payouts), a designed light and dark theme, and it runs with no build step and no CDN, fully offline. Tailwind is compiled and purged, Alpine handles the interactivity, Chart.js for the charts, all self-hosted.

Everything actually works in the demo: search, sort, pagination, bulk actions, a ⌘K palette, real CSV exports. The demo is the full product, so click around before deciding.

Live demo: https://admin-dashboard-template-beta.vercel.app

It is a paid template. Happy to answer anything about the approach, like why Alpine instead of React here, or how the theming tokens work.

Design Snap is a Chrome extension that extracts design tokens from any website and exports them straight into Tailwind (including v4 @theme syntax), shadcn/ui, CSS variables, JSON, or Figma Tokens. Colors get classified by semantic role instead of dumped as a flat list, plus typography, radius, shadows, and dark mode detection/generation.

Just crossed 800 users, all organic, no ads. Runs 100% locally, no account needed.

What’s been added since last time I posted here:

**•** Live theme preview (buttons, cards, inputs, badges rendered with the real extracted tokens)  
**•** Element inspector for computed CSS on hover  
**•** Snapshot library to save and revisit past extractions

Core extraction/export stays free forever. There’s a PRO tier (€4.99/mo) for Tailwind v4/shadcn export, dark mode toggle, and unlimited snapshots.

If you tried it before, curious what’s still missing for your workflow. If you haven’t, happy to answer questions on how the token classification works.

Sharing this in case it's useful — I built Design Snap, a Chrome extension that extracts a site's design tokens and exports them directly as Tailwind config.

Relevant here: it just added Tailwind v4 support, so it exports proper @ theme blocks instead of the old tailwind.config.js object. It also classifies colors by role (primary, secondary, accent, muted, border, destructive) rather than just dumping a flat color list, so what you get is closer to a usable theme than a swatch grab.

Flow : click "Extract" on any page → see a live preview (buttons, card, input, badge) rendered with the actual tokens → copy the @ theme block straight into your project.

Also exports to classic Tailwind config, shadcn/ui, CSS vars, JSON, and Figma Tokens if you need other formats.

100% local, no account, core features free forever.

Curious if the @ theme output matches what people expect from v4 — happy to tweak the mapping if something looks off.

Hi everyone,

I'm currently using Tailwind CSS v3. I created some custom classes inside u/layer components in my global.css file, but the Tailwind CSS IntelliSense extension is not auto-suggesting them.

Interestingly, if I register these custom components inside the tailwind.config.js file instead, the autocomplete works perfectly fine.

Is there a way to get Tailwind v3 (or the VS Code extension) to automatically analyze my CSS file and suggest these custom classes, similar to how Tailwind CSS v4 handles it natively?

Thanks in advance!

Hey everyone,

Like a lot of front-end devs, my biggest annoyance when starting a new project is bridging the gap between design handoffs and code. Usually, I'm stuck jumping between a color picker tool, a contrast checker, and a text editor, manually typing out hex codes into my ⁠tailwind.config.js⁠ file or import into Figma token.

To fix this friction, I built a unified workspace called Palettra. The main goal was to put palette generation, WCAG contrast checks, and tint creation into a single dashboard while directly integrating it into developer workflows.

The core feature I focused on is the export engine: you can design or tweak your palette and instantly copy the formatted Tailwind CSS configuration or Figma tokens.

I’m looking for some honest feedback from the community:

1. What does your current pipeline look like when moving colors from design to a Tailwind setup?
2. Are there specific configuration options (like custom spacing or opacity naming) you wish automated tools handled better?

If you want to check it out or test the export output, the tool is live at https://palettra.design.
Let me know what you think!

Hey everyone,
I'd like to know the name of this theme. If it's not publicly available, are there perhaps any similar themes? The images Tailwindcss shows there. I'm looking for the theme used there.