Coder Legion - Recent posts tagged css

A hash-based CSP has no room for a syntax highlighter

Tue, 27 Oct 2026 16:19:34 +0000

The Content Security Policy on this site allows scripts by SHA-256 hash. Not unsafe-inline, not a nonce, not a wildcard. A list of exact digests, and anything whose bytes don't match one of them does not run.

That is the strong version of the policy, and it is strong for a boring reason: a hash is a statement about content that nobody can forge. If an injection lands in my HTML, it does not matter that it sits in a <script> tag on my own origin. Its hash isn't on the list, so it's inert.

The cost of that arrived the first time I put a fenced code block in an article.

What a hash can and cannot cover

Astro computes these hashes during the build and writes them into a <meta http-equiv>. It knows the bytes of every script it bundles, so it can digest them and emit a policy that matches.

The limit is in that sentence. It hashes what it bundles. Anything that produces markup at render time, after the policy has been written, is invisible to it.

There is exactly one script on this site that Astro doesn't bundle, and it earns its exception. The anti-FOUC snippet that reads the stored theme has to run before first paint, so it is is:inline and Astro leaves it alone. Its hash is maintained by hand:

scriptDirective: {
  resources: ["'self'", 'https://challenges.cloudflare.com'],
  hashes: ['sha256-WV81hIAeXjEdgj/cFIXtOf53g8pIquCjmXQuCHOehlw='],
},

Which is fine for one script that changes twice a year. It stops being fine as a general strategy the moment something starts generating markup on every page.

Shiki was the first casualty

Astro ships Shiki for Markdown syntax highlighting and turns it on by default. It is genuinely good. It also colours code by wrapping every token in a  with an inline style attribute.

Under style-src 'self' with no unsafe-inline, every one of those attributes is blocked. Code blocks render as undifferentiated grey text.

The obvious repair is to allow them, and the way you allow a style= attribute specifically is 'unsafe-hashes'. I read the spec on that keyword twice, because the name is doing a lot of honest work. It permits hashed content in attribute position, and attribute position is where a large share of real-world injection lands. Adding it to make code look nice would mean weakening the exact property I built the policy for, on behalf of a feature nobody asked me for.

So I turned it off:

markdown: {
  syntaxHighlight: false,
},

Code blocks now emit plain <pre><code>, which the policy has no objection to. The colour lives in a stylesheet, keyed off classes, served from 'self', and no hash is involved because it is not inline anything.

I want to be precise about what I gave up, because "just disable it" is a suspiciously comfortable ending. I lost per-token semantic colour. What I have is monospace with sensible contrast, and I decided that a code block being legible matters more than a keyword being purple. If a piece ever genuinely needs highlighting, the way in is a build-time transform that emits classes instead of styles, not a relaxed policy.

The rule that fell out of it

The interesting part wasn't the config flag. It was noticing that Shiki is not a special case, it is the first instance of a class, and the class is "anything that writes style into an attribute".

My own code does this constantly if I let it. A one-line margin tweak in a component is easier to write as style="margin-left:8px" than as a class and a rule in a stylesheet. It also passes the build, looks correct in astro preview, and dies silently in production, because preview does not serve the real policy.

So that stopped being allowed, and the ban is written where the temptation is:

/* Qui e non come style= inline: un attributo style richiederebbe 'unsafe-hashes' nella CSP. */
#copy-email-btn{ margin-left:8px; }

Eight pixels of margin, with a comment explaining why it lives in a stylesheet. It looks like over-documentation until you picture the version of me who is in a hurry, sees a naked eight-pixel rule with no explanation, and decides it would read better inline.

The test is on the built output, not the source

None of that survives on discipline. It survives because a test reads the built HTML and fails on anything it finds.

For every page in dist/, it extracts the inline scripts, hashes each one, and asserts the digest appears in the policy. When it fails it hands you the fix:

Script inline senza hash nella CSP.
Aggiungi 'sha256-…' a security.csp.scriptDirective.hashes in astro.config.mjs.

Then two assertions for the class Shiki introduced me to. No style= attribute anywhere. No inline on…= handler anywhere. Both name the same reason in their failure message, that allowing them would require 'unsafe-hashes', so whoever hits it learns the policy instead of just learning that CI is angry.

A fourth one guards a different failure. My real policy lives in the meta tag, and a CSP in the headers would be applied as an intersection with it, so a plain script-src 'self' written there would cancel every hash and take the site offline. That test allows exactly one directive in the headers file, frame-ancestors, which is ignored inside a meta tag by specification and therefore has to live there.

Two more of them exist only to keep the suite honest. One asserts the build produced pages at all. The other asserts that somewhere in dist/ at least one inline script was found, because the day my regex stops matching, every per-page assertion starts passing on an empty list and the whole file goes green while checking nothing. A test that cannot fail is not a test, and the cheapest way to catch one is to assert that its input is non-empty.

There is a trap in this design worth naming. The tests read dist/, so running them without rebuilding grades yesterday's output. That is why the script is:

"test": "npm run build && npm run test:csp"

I have watched that suite pass on a stale build. It is very reassuring and completely meaningless.

Worth checking on yours

If you have a CSP, load your site and open the console rather than reading the policy. Blocked resources report themselves there, and a policy that is silently breaking one widget on one page looks identical to a working one from the config file.

If you are on unsafe-inline today, the useful question isn't how to reach a hash policy in one move. It's which dependency would break first if you did. For me it was the highlighter shipped by default in my own framework, and I would not have guessed that before it happened.

And if you already run a strict policy, go find where the exception is. There usually is one, it usually has a good reason, and the good reason is usually two years old.

Diagnose scroll snap failures: prerequisites, decision, result, limitation

Sun, 25 Oct 2026 22:09:27 +0000

Prerequisites

You should be comfortable with CSS basics (overflow, writing modes) and know where to edit the scrolling container and its children in your stylesheet. Familiarity with scroll-snap-type, scroll-snap-align, and the difference between physical (x/y) and logical (inline/block) axes is helpful.

Implementation decision

The diagnostic approach checks four things in order: container opt-in (scroll-snap-type), child snap alignments (scroll-snap-align), axis correspondence with actual scroll motion, and strictness (proximity vs mandatory). The helper returns a small report listing issues and concrete fixes so you can change only the declaration that matters.

Expected result

If the container never had scroll-snap-type, the helper tells you to add it.
If children lack scroll-snap-align, it tells you to add alignment to the snapping items.
If the axis does not match the motion, it suggests changing the container axis to x/y/inline/block.
If strictness is proximity, it suggests mandatory when you require guaranteed landings.

One limitation

This tool inspects declarations and relationships; it does not simulate the browser’s snapping physics. Logical axis changes, multi-value child alignments, and subtle input momentum can still cause behavior that the heuristic can’t predict. Use it to find the likely declaration to edit, then verify in-browser across viewports and input types.

The server will inject the verified implementation below as a fenced example.

Working example

export function diagnoseSnap(containerStyles = {}, childrenStyles = []) {
  const result = { ok: false, issues: [], fixes: [] };

  const rawType = String(containerStyles.scrollSnapType ?? 'none').trim();
  if (!rawType || rawType === 'none') {
    result.issues.push('container-not-opted-in');
    result.fixes.push('Add scroll-snap-type on the scroll container, for example: "scroll-snap-type: x mandatory".');
    return result;
  }

  const [axisToken = 'none', strictnessToken] = rawType.split(/\s+/);
  const axis = axisToken;
  const strictness = strictnessToken ?? 'proximity';

  const parsedChildren = childrenStyles
    .map((child) => {
      const rawAlign = String(child?.scrollSnapAlign ?? '').trim();
      if (!rawAlign) return null;
      const parts = rawAlign.split(/\s+/).filter(Boolean);
      return parts.length === 1
        ? { rawAlign, parts, block: parts[0], inline: parts[0] }
        : { rawAlign, parts, block: parts[0], inline: parts[1] };
    })
    .filter(Boolean);

  if (parsedChildren.length === 0) {
    result.issues.push('missing-snap-align');
    result.fixes.push('Add scroll-snap-align on the snapping children, for example: "scroll-snap-align: center;".');
  }

  const hasAxisMatch = parsedChildren.some((child) => {
    if (axis === 'both') return child.block !== 'auto' || child.inline !== 'auto';
    if (axis === 'x' || axis === 'inline') return child.parts.length === 1 && ['start', 'center', 'end'].includes(child.inline);
    if (axis === 'y' || axis === 'block') return ['start', 'center', 'end'].includes(child.block);
    return false;
  });

  if (parsedChildren.length > 0 && !hasAxisMatch) {
    result.issues.push('axis-mismatch');
    result.fixes.push(`Change the container axis to match the movement you want; the current value "${axis}" does not line up with the child alignments.`);
  }

  if (strictness === 'proximity') {
    result.issues.push('proximity-strictness');
    result.fixes.push('If you need a guaranteed landing, use "mandatory" instead of "proximity".');
  }

  if (result.issues.length === 0) {
    result.ok = true;
    result.message = 'snapping-should-work';
  }

  return result;
}

Read the full article: https://chriseugenerodriguez.com/blog/scroll-snap-axis-align-strictness-diagnose

Your Flex Child Won't Shrink, and overflow: hidden Isn't the Fix (It's min-width: 0)"

Thu, 22 Oct 2026 15:08:46 +0000

You build a dashboard. Sidebar on the left, content on the right, a table or a code block inside. It looks perfect with your sample data.

Then a user pastes a long URL into a field, and the whole page grows a horizontal scrollbar. The sidebar gets squeezed, the layout breaks, and you start adding overflow: hidden to everything until the symptoms go away.

There is a one-line fix, and it is not overflow: hidden.

The Layout That Breaks

<div class="layout">
  <aside class="sidebar">Menu</aside>
  <main class="content">
    <pre>https://example.com/a-very-long-url-with-no-break-points-in-it-at-all-1234567890</pre>
  </main>
</div>

.layout {
  display: flex;
}
.sidebar {
  width: 240px;
  flex-shrink: 0;
}
.content {
  flex: 1;
}

.content is told to take the remaining space with flex: 1. Nobody told it to stay inside that space, and that is the entire problem.

Why It Happens

Flex items and grid items have a default of min-width: auto. For a flex item, auto means:

Do not shrink narrower than the smallest size your content can be.

For a paragraph of normal words, the smallest size is the longest single word, because the line can wrap between words. For a long URL, a <pre> block, a wide table or an image, there is nowhere to wrap, so the smallest size is the full width of the content.

So the browser is not ignoring your layout. It is obeying a rule you never knew existed: the item refuses to shrink below its content, and the overflow spills into the page.

Why `overflow: hidden` Looks Like a Fix (Sometimes)

Setting overflow to anything other than visible changes how min-width: auto is calculated. The automatic minimum becomes 0 for that item. That is why overflow: hidden on the right element makes the bug vanish.

It works by accident, and it has a cost: it clips content, can cut off focus outlines and dropdowns, and does nothing useful if you put it on the wrong element. Fixing the cause is cleaner.

Fix 1: min-width: 0 on the Flex Child

.content {
  flex: 1;
  min-width: 0;
}

You are telling the item that it is allowed to shrink below its content. Now .content stays inside its space, and the long URL can be scrolled, wrapped or cut off by something you control:

.content pre {
  overflow-x: auto;
}

In Tailwind, the utility is min-w-0:

<main class="flex-1 min-w-0">
  <pre class="overflow-x-auto">...</pre>
</main>

Fix 2: Grid's 1fr Has the Same Trap

.layout {
  display: grid;
  grid-template-columns: 240px 1fr;
}

1fr is not "one equal share, and no more". It is shorthand for minmax(auto, 1fr), so the column cannot get narrower than its content. The same long URL stretches the column and the page.

.layout {
  display: grid;
  grid-template-columns: 240px minmax(0, 1fr);
}

minmax(0, 1fr) allows the column to shrink to nothing if it has to. A useful side note for Tailwind users: grid-cols-2 and its siblings already compile to repeat(2, minmax(0, 1fr)), which is why many people never meet this bug in the grid, and then meet it as soon as they write a custom template column.

Fix 3: Truncating Text With an Ellipsis Inside Flex

This one catches almost everybody:

.row {
  display: flex;
  gap: 8px;
}
.title {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

It does not truncate, because the flex item sizes itself to the text. Add min-width: 0 to .title and the ellipsis appears. In Tailwind, truncate min-w-0 on the same element does it.

Fix 4: Long Words Need the Right overflow-wrap

For user-generated text such as comments, names and pasted links, allow breaking inside a word:

.comment {
  overflow-wrap: anywhere;
}

overflow-wrap: break-word looks equivalent, but it does not change the item's minimum size calculation, so inside a flex or grid item it can still leave the layout stretched. anywhere does take the break points into account, and the item can shrink.

Which One When

Symptom	Fix
Flex child pushes the page wider	`min-width: 0` on that child
Grid column grows past its space	`minmax(0, 1fr)` instead of `1fr`
Ellipsis not appearing in a flex row	`min-width: 0` plus the truncation rules
Long pasted word or URL	`overflow-wrap: anywhere`
Wide table or code block	Own scroll container with `overflow-x: auto`

The Rule

Flex and grid items refuse to shrink below their content by default. If something inside a layout can be wider than the space it is given, tell the container it is allowed to shrink with min-width: 0 or minmax(0, 1fr), and decide where the overflow should scroll or wrap.

Quick audit: open your app and paste a 200-character string with no spaces into every input that is later displayed. Then widen a table to 40 columns. If the page grows a horizontal scrollbar, you have found a missing min-width: 0.

I test every layout in my Next.js and Tailwind templates against this kind of hostile content, because real users do paste long strings, and a dashboard has to survive it.

Get the templates: https://pixelanas.gumroad.com

What is the ugliest layout bug a single piece of user content has caused you? Drop it in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

min(), max(), and clamp() Will Replace 80% of Your Media Queries

Thu, 22 Oct 2026 06:52:00 +0000

Writing dozens of @media (min-width: ...) breakpoints creates rigid, fragmented CSS stylesheets. Modern CSS handles dynamic fluid typography and fluid spacing natively without media queries.

CSS
/ Old Way: Rigid breakpoint hopping /
h1 { font-size: 1.75rem; }
@media (min-width: 768px) { h1 { font-size: 2.5rem; } }
@media (min-width: 1200px) { h1 { font-size: 3.5rem; } }

/ Modern Way: Fluid typography in 1 line /
h1 {
font-size: clamp(1.75rem, 4vw + 1rem, 3.5rem);
}

/ Fluid layout container with max boundary and dynamic padding /
.container {
width: min(100% - 2rem, 1200px);
margin-inline: auto;
}
Why it changes your career: Fluid layout primitives produce far cleaner, more resilient user interfaces that adapt smoothly across any viewport without brittle media query hacks.

FSCSS layout helpers: stack, hstack, center, size, rounded, ratio-fit(), etc

Wed, 21 Oct 2026 09:20:38 +0000

FSCSS layout helpers: stack, hstack, center, size, rounded, ratio-fit(), and friends

From version 1.2.5 FSCSS added a set of property shorthands aimed at everyday layout and chrome—spacing axes, flex stacks, sizing, and aspect boxes—without inventing a new component system. They compile to ordinary CSS. Use them in .fscss (CLI, runtime, or IDE); production can ship the compiled sheet only.

Full list and expansions: fscss.devtem.org/shorthands · language: fscss@1.2.5 - 1.2.6+

Why these exist

A lot of UI CSS is the same four ideas:

Space along one axis (padding/margin x or y)
Stack children (column or row + gap)
Center content in a box
Size a box (square, both axes, or fit a ratio)

Native CSS can do all of that, but the typing is noisy (display: flex; flex-direction: column; gap: … every time). These helpers expand at compile time so the mental model stays short.

Spacing axes

Shorthand	Idea	Typical expansion
`mx` / `my`	margin on x / y	`margin-left` + `margin-right` / top + bottom
`px` / `py`	padding on x / y	same pattern for padding
`inset-x` / `inset-y`	positioned inset on one axis	without forcing the other axis to `0`

.card {
  px: 20px;
  py: 16px;
  mx: auto;
  max-w: 420px;
}

Use these when you only care about one axis. Prefer full margin / padding when all four sides share one value.

`stack` and `hstack`

Vertical and horizontal flex stacks with gap:

.panel {
  stack: 12px;   /* column + gap */
}

.toolbar {
  hstack: 8px;   /* row + gap */
  fwrap: wrap;   /* if you also use wrap helpers */
}

Roughly: display: flex, direction column or row, and gap from the value. Ideal for forms, toolbars, and card bodies where “children in a line with space between them” is the whole layout story.

`center`

Center children in the box (axis or both, depending on the form your build supports—commonly flex centering):

.hero {
  min-h: 40vh;
  center: both; /* or center: true — see docs */
}

Handy for empty states, icon wells, and hero blocks without repeating align-items / justify-content every time.

`size` and friends

Helper	Role
`size`	width and height (one value → square, or two values)
`max-size` / `min-size`	both axes’ max/min
`insert: ratio-fit();`	size a box to a ratio inside a container

.avatar {
  size: 48px;
  rounded: 999px;
}

.thumb {
  size: 100% 180px;
}

.media {
  inset: ratio-fit(16 / 9);
}

ratio-fit is for the common “keep 16:9 (or any ratio) without a padding-hack essay.” Exact expansion is in the shorthands reference—treat it as the declarative cousin of aspect-ratio + constrained width/height patterns.

`rounded` and surface chrome

.card {
  rounded: 16px;
  bg: #121a30;
  shadow: 0 10px 30px #0003;
}

rounded maps to border-radius. Together with color/spacing shorthands (bg, p, m, …) you can sketch a card shell in a few lines and still compile to standard properties.

Small composed example

.page {
  min-h: 100vh;
  p: 24px;
  bg: #0b1020;
  color: #e6edf7;
  ff: system-ui, sans-serif;
}

.wrap {
  max-w: 960px;
  mx: auto;
  stack: 20px;
}

.row {
  hstack: 16px;
  fwrap: wrap;
}

.card {
  flex: 1;
  min-w: 240px;
  p: 20px;
  rounded: 16px;
  bg: #121a30;
  border: 1px solid #22304f;
  stack: 12px;
}

.icon {
  size: 40px;
  rounded: 12px;
  center: true;
  bg: #1b2745;
}

Read it top to bottom: page padding → centered column → horizontal row of cards → each card is a vertical stack. No design-system runtime—only CSS the browser already understands after compile.

Runtime note: `fscss-props`

If you only need property shorthands in the browser (not full @arr / @define / pattern()), fscss-props expands a similar surface at runtime and exposes JS APIs (element.fscssProp, fscssPropText) for live updates. Full language features still go through the FSCSS compiler (CLI, runtime.js / esm.js, or the IDE).

When to use what

Goal	Prefer
One-off page / prototype	Shorthands in `.fscss` + CDN runtime or IDE
Design tokens + charts + modules	`@import` packs (`st-core@v2`, etc.) and shorthands for local layout
Production	Compile with CLI; ship the CSS file
JS-driven tweaks of padding/size only	`fscss-props` or set CSS variables / longhands from JS

Shorthands do not replace modules. They remove friction between modules—nav bars, card grids, toolbars—where flex + gap + radius is enough.

Try it

npm install fscss@latest

<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.6/runtime.min.js" defer></script>

Or open the FSCSS IDE, paste a .card { stack: 12px; rounded: 16px; p: 20px; } block, and hit compile.

A Declarative Naming Layer for the View Transition API

Tue, 13 Oct 2026 16:14:47 +0000

For a long time, I treated interface animation as mostly decorative. It could make a product feel more polished or visually impressive, but I rarely considered it functionally important. In fact, I usually preferred to disable animations wherever possible. A dropdown did not seem to need an animation. Smooth scrolling often felt slower than an immediate jump. Waiting for UI motion to finish could feel like unnecessary latency.

Working on more complex interfaces changed my view.

Transitions can be a form of user feedback. When an interaction causes a substantial change in the interface, the developer already knows exactly what happened: which component disappeared, which one replaced it, which panel expanded, and where the new state came from. A user who is still learning the interface does not have that internal model.

An abrupt state change can therefore be difficult to interpret. A transition can preserve visual continuity between the old and new states. When an element moves, expands, collapses, or transforms into another part of the interface, the motion gives the user additional information about the relationship between those states. It helps explain what their action changed and how the new layout relates to the previous one.

That makes transitions part of UX rather than merely visual styling. They can reduce the cognitive cost of navigating an unfamiliar interface and make its behavior easier to learn.

This is one of the reasons I became interested in the View Transition API. It gives the browser a native mechanism for creating complex transitions between DOM states without manually implementing every animation and coordinating the old and new layouts yourself. For me, this changed View Transitions from a visual extra into a useful part of interface architecture.

Once I started using them more extensively, however, a different problem appeared: managing view-transition-name across a large component hierarchy quickly became verbose and difficult to maintain.

That is the problem this article is about.

The View Transition API is one of the browser APIs I enjoy using most. For simple cases, it is remarkably compact: update the DOM inside document.startViewTransition(), assign a few view-transition-name values, and let the browser handle the snapshots and interpolation.

The complexity changes quickly once the interface contains many independently changing elements.

In a real application, the same element may participate in different transitions depending on the operation. A transition may involve elements distributed across several Vue components. Some elements should inherit a transition namespace from their ancestors, while others should start a new namespace or stop propagation. Multiple independent transition hierarchies may coexist in the same DOM tree.

I initially handled these cases individually, including with coding agents. The individual implementations worked, but the amount of imperative orchestration kept growing: find elements, assign names, coordinate old and new DOM states, wait for Vue updates, remove temporary state, handle dynamic instances, and repeat similar logic for the next transition.

The code was becoming substantially more verbose than the UI behavior it described.

I eventually moved the problem into a separate declarative naming layer.

The result is a small internal system used in AlekLabs Eye Trainer. View transition participation is described directly in component templates using attributes, while a runtime function activates the required transition hierarchy only for the duration of a transition. Vite compiler transforms, generated TypeScript types, and a VS Code grammar provide the tooling around it.

The browser still performs the actual View Transition. The new layer deals with naming and orchestration.

Moving Transition Identity Out of CSS

A normal View Transition implementation often starts with CSS such as:

.card {
    view-transition-name: card;
}

That works well while an element has one permanent transition identity.

My application needed something more dynamic. A DOM element can participate in one transition when a panel changes, another when a dialog opens, and a more specific child transition when only part of the same UI changes.

Keeping all of that identity in CSS made the relationship between the component structure and transition structure increasingly difficult to see.

I wanted the template itself to answer a simple question:

Which View Transition hierarchies can this element participate in?

CSS could then remain responsible for the visual behavior of the generated View Transition pseudo-elements.

The distinction became important. The attributes in my templates do not directly set view-transition-name. They are persistent metadata describing possible transition relationships. The actual view-transition-name values exist only while a particular transition is running.

First Attempt: Vue Directives

Vue directives initially looked like a natural solution.

Something like this would have been expressive:

<al-panel v-transition="'settings'">

The limitation appeared as soon as the directive was placed on components.

Vue directives used on components are applied to the component root. Unlike fallthrough attributes, they cannot be forwarded to another element with v-bind="$attrs". Multi-root components add further restrictions.

My UI has a deep component hierarchy, including many internal UI components. I needed transition metadata to move naturally through those abstraction layers.

Ordinary attributes already have exactly this property in Vue.

That made attributes a much better transport mechanism.

A Small Attribute Language

The initial attribute names were too verbose. Repeating a long view-transition-* or application-specific prefix throughout large templates made the transition structure visually noisy.

I introduced $ as a source-level marker for View Transition metadata.

A simplified example looks like this:

<al-panel-expandable :$modulator-panel="num">
    <modulation-curve-setting $-motion />
    <al-adjust $-amount />
</al-panel-expandable>

The first attribute establishes a transition family. If num is 2, its resolved name can become:

modulator-panel-2

The child attributes extend the inherited family:

modulator-panel-2-motion
modulator-panel-2-amount

The interesting part is that $-motion contains no knowledge of modulator-panel, the instance number, or the component in which the hierarchy started.

It simply declares its position inside the current transition family.

This makes transition structure composable across components.

Hierarchical Names

The naming layer behaves as a hierarchy rather than a flat collection of unrelated IDs.

A direct attribute starts a family:

<al-panel :$al-setting="targetId">

A descendant can extend it:

<al-slider $-value />

For a target ID of rotation, the runtime can resolve this as:

al-setting-rotation
al-setting-rotation-value

The hierarchy can cross Vue component boundaries because the compiler output consists of normal attributes.

Several transition families can also coexist in the same area of the application. An element can permanently declare metadata for several possible scenarios while receiving only the actual view-transition-name relevant to the transition currently being executed.

This avoids a major practical problem of the native property: a rendered element taking part in a named View Transition has one view-transition-name, and custom names must be unique among participating rendered elements.

My layer therefore treats names as potential roles rather than permanent CSS state.

Controlling Participation and Propagation

The syntax gradually acquired a few compact controls as real cases appeared.

The current model can be summarized like this:

Source syntax	Meaning
`$panel`	Start or participate in a transition family
`$-value`	Extend the inherited family with `value`
`:$panel="id"`	Add a dynamic instance value
`$panel!`	Define the transition here without propagating it further
`$panel-`	Establish a family for descendants without making this element participate

The last two are particularly useful in reusable component trees.

Sometimes a component is only a structural boundary. Its children need a shared transition namespace, while the component root itself should not get its own snapshot. In other cases a transition applies to one level and should stop before unrelated nested UI starts inheriting it.

These controls make that decision part of the template rather than additional JavaScript.

The runtime also supports compact shortcut definitions and the browser's match-element mode for cases where element identity itself should supply the unique transition matching. Internally, the parser resolves all of these forms into the same transition definition model.

The `$` Syntax Exists Only During Authoring

I did not want unconventional $... attributes to become the permanent runtime DOM representation.

A Vue compiler transform rewrites them during compilation.

Conceptually:

$modulator-panel
$-amount

becomes runtime metadata in the form:

data-transition-modulator-panel
data-transition--amount

Additional marker attributes are generated when propagation or parent-only behavior is requested. The transform operates on the Vue compiler AST, including both static attributes and static v-bind argument names.

For example, the source-level ! suffix becomes an internal --no-propagate marker, while a trailing - on a named family produces a --parent-only marker. vite-plugin-vue-transition-attr…

This gives me two representations with different purposes.

The source representation is optimized for developer experience:

$modulator-panel
$-motion
$-amount

The DOM representation is explicit and conventional enough for runtime inspection:

data-transition-modulator-panel
data-transition--motion
data-transition--amount

Runtime Orchestration

All imperative orchestration is concentrated in one startTransition() function.

Application code can start a transition by name:

await startTransition(`al-setting-${targetId}`, () => {
    dialogTarget.value = target;
});

It can also start from a DOM element:

await startTransition(panel, () => {
    item.amountCurveOn = value;
});

The second form is useful when the caller does not need to know the hierarchy name. The runtime examines the element and its subtree and determines which declared transition names belong to it.

Multiple prefixes can also be supplied to activate several declarative hierarchies during the same View Transition.

Internally, startTransition() performs the lifecycle that I previously had scattered across individual features.

Before calling document.startViewTransition(), it resolves the requested prefixes and temporarily assigns viewTransitionName to matching elements. During the update callback it performs the application state change, waits for Vue's nextTick(), removes the old assignments, scans the updated DOM, and assigns names again for the new state. After the browser reports the transition as finished, all temporary names are removed.

The second scan is important. A transition frequently changes which elements exist. The old snapshot and new snapshot therefore cannot rely on a single static set of DOM nodes.

The declarative attributes remain stable metadata. The runtime derives the correct active names independently on both sides of the DOM update.

Prefix matching provides another useful property. Starting:

startTransition('modulator-panel-2', update);

can activate the family rooted at that prefix, including more specific descendants such as:

modulator-panel-2-motion
modulator-panel-2-amount

The runtime performs that matching centrally instead of requiring every call site to enumerate all participating elements.

Keeping CSS Generic

The system also assigns a shared view-transition-class to participating elements.

This allows generic snapshot behavior to remain very small:

::view-transition-old(.view-transitioned),
::view-transition-new(.view-transitioned) {
    width: 100%;
    height: 100%;
    object-fit: fill;
}

view-transition-class is designed exactly for this kind of shared styling: unlike view-transition-name, the class does not need to be unique and can style multiple named transition pseudo-elements. MDN Web Docs

Specific transitions can still have their own CSS where required. The naming, hierarchy, selection, and lifecycle no longer have to be encoded there.

Editor Tooling Became Part of the Design

Once transition metadata moved into templates, another problem became obvious: attributes disappear visually inside large Vue files.

I wanted transition structure to be immediately recognizable while reading a component.

I added a tiny VS Code extension with a TextMate grammar that highlights $... transition attributes separately from ordinary attributes. The grammar is injected directly into Vue template syntax. transition-attributes.tmLanguage package

This turned out to be more valuable than I initially expected.

When opening a large template, I can visually scan the transition structure without tracing JavaScript. Parent families, child segments, and dynamic transition bindings stand out immediately.

The transition layer became visible as part of the component architecture.

Generating Transition Names and Types

The next step was eliminating manually maintained name lists.

A second Vite plugin scans Vue files, parses each SFC with @vue/compiler-sfc, parses the template with @vue/compiler-dom, walks the AST, and collects $... transition names. It runs initially and again when Vue files are added, changed, or removed. vite-plugin-transition-names

It then generates a TypeScript source file:

export const transitionNames = [
    'al-setting',
    'modulator-panel'
] as const;

That generated constant feeds the runtime type:

type TransitionPrefix = typeof transitionNames[number] | `${typeof transitionNames[number]}-${string}`;

As a result, creating a new transition family in a template automatically makes the name available to TypeScript autocomplete at startTransition() call sites. The same generated information also catches many naming mistakes during development.

There is no separate registry to remember to update.

The template is the source of truth.

The Real Production Case

This system grew out of AlekLabs Eye Trainer rather than an isolated animation experiment.

A single modulation component already contains several examples: dynamically identified modulator panels, motion and amount children, target settings, slider values, dialog transitions, and transitions started both from DOM elements and from explicit hierarchical prefixes.

That is the kind of component where a collection of one-off View Transition implementations becomes difficult to maintain. Several independent UI operations coexist, and each operation may involve a different subset of the same component tree.

With the naming layer, most of that information remains close to the markup.

The behavioral code describes the state update.

The template describes transition participation.

The runtime connects the two.

This Is Not Fundamentally Vue-Specific

My current implementation is integrated deeply with Vue because AlekLabs Eye Trainer uses Vue. The compiler transform uses Vue's compiler packages, the generated-name plugin scans .vue templates, and the transition runtime waits for nextTick() before resolving the new DOM.

The underlying model is framework-independent.

The browser only sees DOM attributes and document.startViewTransition().

A React, Svelte, Web Components, or plain HTML implementation could use the same architecture with a different authoring transform and a framework-appropriate mechanism for waiting until the DOM update completes.

The important part is the separation between persistent declarative metadata and temporary native View Transition state.

What I Learned From Building It

The View Transition API itself remained small throughout this process. Most of the engineering work appeared around naming, composition, lifecycle, discoverability, and developer tooling.

For isolated transitions, direct view-transition-name declarations are sufficient.

For a larger application, I found it much more manageable to treat transition participation as its own declarative application layer.

The final workflow is now straightforward: mark potential participants in the template, compose them into hierarchical namespaces, start a transition from a typed prefix or DOM element, and let one runtime function assign and clean up the browser state.

Vite handles the source transformation and name discovery. TypeScript provides autocomplete and validation. The editor makes the structure visually recognizable. CSS focuses on the resulting animation.

This changed View Transitions in AlekLabs Eye Trainer from feature-specific imperative code into reusable infrastructure.

And, more importantly for a growing UI, adding the next transition no longer requires inventing another orchestration mechanism.

A Useful Side Effect: Agent-Friendly Transitions

A pleasant side effect of this architecture is how well coding agents work with it.

Once an agent is told that $... attributes describe View Transition participation, it can usually extend fairly complex transitions without needing to understand the runtime implementation. For many tasks, the instruction can be as small as: use the $ transition attributes to connect these elements into the same transition hierarchy.

Even transitions involving several components and multiple moving elements can often be implemented without adding feature-specific JavaScript or CSS. The shared runtime already handles name resolution, DOM updates, View Transition lifecycle, and cleanup.

This also makes agent-generated changes much easier to review. Instead of inspecting a new block of transition-specific JavaScript together with additional CSS selectors and animation rules, I can often review only a few attribute changes in the template. The transition structure is visible directly in the markup, and the diff stays small.

In practice, modern coding agents handle this declarative syntax very well. Once the pattern exists in the codebase, they can infer the hierarchy from nearby examples and produce complex multi-element transitions with surprisingly little guidance.

For me, this has become another argument for moving repeated UI behavior into declarative infrastructure: it improves developer experience for humans, and it also gives coding agents a much smaller and more constrained surface to modify.

Container queries: prefer the right container-type for the axis you query

Tue, 13 Oct 2026 08:23:04 +0000

Prerequisites

Basic familiarity with CSS container queries and the container-type and container-name properties.
Ability to inspect DOM and computed styles in the browser devtools.

Implementation decision

If your rules include block-axis queries (height, block-size), keep the container that those elements rely on set to container-type: size.
If you only need inline-axis checks (width), prefer container-type: inline-size to limit containment cost.
Use container-name to ensure the browser targets the intended ancestor when nested containers could confuse matching.

Expected result

When the container remains container-type: size, both width- and height-based @container queries will find a valid ancestor and evaluate normally.
If you switch the same container to container-type: inline-size at runtime, inline-axis (width) queries will still match, but block-axis (height) queries will report no eligible container and stop matching.
A named container still resolves by name, but a name does not grant missing axis support; axis-based queries still need the right container-type.

Limitation

The guidance isolates containment eligibility. It does not cover cases where a query fails due to selector specificity, layout overrides, or DOM moves that change ancestors. Always verify the actual DOM path and computed container-type in the browser where the issue appears.

Working example

export function createElement({ tag = 'div', width = 0, height = 0 } = {}) {
  return {
    tag,
    width,
    height,
    parent: null,
    children: [],
    containerType: 'normal',
    containerName: undefined,
  };
}

export function appendChild(parent, child) {
  child.parent = parent;
  parent.children.push(child);
}

export function setContainerType(el, type) {
  el.containerType = type;
}

export function setContainerName(el, name) {
  el.containerName = name;
}

export function toggleContainerType(el, nextType) {
  setContainerType(el, nextType);
}

function compare(op, left, right) {
  switch (op) {
    case '>': return left > right;
    case '>=': return left >= right;
    case '<': return left < right;
    case '<=': return left <= right;
    default: throw new Error(`unsupported compare operator: ${op}`);
  }
}

function queryAxis(query) {
  if (query.kind === 'name-only') return null;
  if (query.axis) return query.axis;
  if (query.feature === 'width') return 'inline';
  if (query.feature === 'height') return 'block';
  return null;
}

export function findEligibleContainer(startEl, query) {
  let node = startEl.parent;
  const axis = queryAxis(query);

  while (node) {
    if (query.kind === 'name-only') {
      if (node.containerName === query.name) return node;
    } else if (axis) {
      if (node.containerType === 'size') return node;
      if (node.containerType === 'inline-size' && axis === 'inline') return node;
    }
    node = node.parent;
  }

  return null;
}

export function evaluateQuery(targetEl, query) {
  const container = findEligibleContainer(targetEl, query);
  if (!container) {
    return { matched: false, reason: 'no-eligible-container', container: null };
  }

  if (query.kind === 'name-only') {
    return { matched: true, container };
  }

  const axis = queryAxis(query);
  const size = axis === 'inline' ? container.width : container.height;
  return {
    matched: compare(query.compare, size, query.value),
    container,
    containerValue: size,
  };
}

Read the full article: https://chriseugenerodriguez.com/blog/why-do-container-queries-stop-matching-when-you-switch-container-type-dynamically

Build a Pure CSS Radar Chart — Lightweight, Max Performance

Sun, 11 Oct 2026 20:07:46 +0000

Most radar charts pull in SVG path math or a JavaScript charting library. You can skip both.

With st-core.fscss, a spider (radar) chart is:

an FSCSS array of scores (0–100)
polar coordinates stored as CSS variables (--st-sxN, --st-syN)
shapes drawn with clip-path: polygon()
rings and spokes from gradients

No canvas. No SVG. No chart runtime on the critical path.

Source: github.com/fscss-ttr/st-core.fscss

Here’s how it works

1. Data is an array

@arr skills[80, 65, 90, 55, 70, 85]

Length can be 5, 6, 8 — whatever you need. Geometry (number of polygon vertices) is fixed when FSCSS expands the mixins.

2. One mixin writes coordinates

.spider {
  @st-spider-points(skills, 42)  /* array, max radius % of the box */
  position: relative;
  width: 280px;
  height: 280px;
  border-radius: 50%;
}

For each index i:

angle = (i - 1) × 360° / N (0° at the top)
radius = (value / 100) × rmax
CSS gets:

--st-sxN: calc(50% + (r * 1%) * sin(θ));
--st-syN: calc(50% - (r * 1%) * cos(θ));

Trig stays in the browser’s calc(). Updating values later is rewriting those variables.

3. Renderers only read variables

@st-spider-fill(.spider-fill, skills)
@st-spider-line(.spider-line, skills)
@st-spider-dots(.spider-dot-, skills, 9px)
@st-spider-grid(.spider-grid)
@st-spider-spokes(.spider-spokes, skills)

Layer	Role
fill	Closed polygon through every `--st-sx/sy` pair
line	Dual-pass polygon (outer path + path scaled toward center) so the stroke has real thickness
dots	Absolutely positioned markers at each vertex
grid	Concentric rings (`radial-gradient`)
spokes	Thin radial axes (`conic-gradient`)

Rule: call @st-spider-points on the host. Children inherit. Same model as linear @st-chart-points / fill / line in st-core.

4. Markup is plain HTML

<div class="spider">
  <div class="spider-grid"></div>
  <div class="spider-spokes"></div>
  <div class="spider-fill"></div>
  <div class="spider-line"></div>
  <div class="spider-dot-1"></div>
  <div class="spider-dot-2"></div>
  <div class="spider-dot-3"></div>
  <div class="spider-dot-4"></div>
  <div class="spider-dot-5"></div>
  <div class="spider-dot-6"></div>
</div>

Dots need real nodes — the mixin emits .spider-dot-1 … .spider-dot-N rules; it does not invent elements.

Here’s how values can be displayed on the dot nodes

Markers are normal DOM nodes, so you can show the score next to (or inside) each dot without a chart API.

Option A — `data-value` + CSS `::after`

<div class="spider-dot-1" data-value="80"></div>
<div class="spider-dot-2" data-value="65"></div>
<!-- … -->

.spider-dot-1,
.spider-dot-2,
.spider-dot-3,
.spider-dot-4,
.spider-dot-5,
.spider-dot-6 {
  /* st-core already sets left/top from --st-sx / --st-sy */
}

[data-value]::after {
  content: attr(data-value);
  position: absolute;
  left: 50%;
  top: -1.4em;
  transform: translateX(-50%);
  font-size: 0.65rem;
  font-variant-numeric: tabular-nums;
  color: var(--st-text);
  white-space: nowrap;
  pointer-events: none;
}

Push labels slightly outward per axis if they collide with the polygon (different top / left offsets per index).

Option B — nested label element

<div class="spider-dot-1">
  <span class="dot-label">80</span>
</div>

.dot-label {
  position: absolute;
  left: 50%;
  bottom: calc(100% + 4px);
  transform: translateX(-50%);
  font-size: 0.65rem;
  color: var(--st-muted);
}

Option C — update labels from JS with the series

function setSeries(host, values, rmax = 42) {
  const n = values.length;
  let css = "";
  values.forEach((v, i) => {
    const ang = (i * 360) / n;
    const r = (v / 100) * rmax;
    css += `--st-sx${i + 1}: calc(50% + (${r} * 1%) * sin(${ang} * 1deg));`;
    css += `--st-sy${i + 1}: calc(50% - (${r} * 1%) * cos(${ang} * 1deg));`;
    const dot = host.querySelector(`.spider-dot-${i + 1}`);
    if (dot) {
      dot.dataset.value = v;
      // or: dot.querySelector(".dot-label").textContent = v;
    }
  });
  host.style.cssText = css;
}

Geometry and labels stay in sync because both come from the same array pass.

Axis names (Speed, Quality, …) stay outside the dots — absolute labels around the circle — so vertices stay readable at small sizes.

Here’s why it’s lighter

Traditional radar	st-core radar
Chart.js / D3 / Recharts bundle	Mixins → CSS
SVG path string updates	Custom properties + `clip-path`
Layout + paint on every redraw	Often compositor-only if you transition `clip-path`
Library hydration before first paint	CSS paints as soon as the stylesheet applies

Compile time: FSCSS expands loops into concrete polygon() stops and selectors. Array length is fixed in the stylesheet.

Runtime: Changing scores is assigning --st-sxN / --st-syN (and optional label text). No path serializer, no virtual DOM for the shape.

Size: A compiled spider block is on the order of ~1 kb of CSS for the chart rules — not a 50–200 kb chart dependency.

Performance profile:

First paint: no JS required for a static series
Updates: style recalc + composite; avoid layout thrash if size is fixed
Multi-series: extra layers are extra divs + inherited variables, not extra chart instances

That’s “max performance” in the practical sense: minimum work per frame and minimum bytes on the wire.

Here are some use cases of spider (radar) charts

Skills / competency matrices — Speed, Quality, UX, Scale, Cost, Support for a team or candidate.
Product scorecards — Compare features across dimensions (performance, price, ecosystem, docs, support).
Sprint or OKR health — Delivery, quality, collaboration, predictability on one glanceable shape.
Security / compliance posture — Control families as axes; one polygon per system or vendor.
Player or character stats — Games and education UIs where polar layout is the expected metaphor.
Brand or perception studies — Trust, value, innovation, service — survey averages as radii.

Anywhere humans already think in “balanced vs spiky” profiles, a radar chart communicates faster than six separate bars.

Here’s how to do multi-series radar charts with still pure CSS

Each series is a separate host with its own @st-spider-points. Shared grid and spokes sit underneath.

@import((*) from st-core@v2)
@st-root()
@st-spider-root()

@arr seriesA[70, 55, 40, 85, 90]
@arr seriesB[45, 75, 60, 50, 55]
@arr seriesC[85, 40, 70, 35, 65]

@st-spider-fill(.fill-a, seriesA)
@st-spider-line(.line-a, seriesA)
@st-spider-dots(.dot-a-, seriesA, 8px)

@st-spider-fill(.fill-b, seriesB)
@st-spider-line(.line-b, seriesB)
@st-spider-dots(.dot-b-, seriesB, 8px)

@st-spider-fill(.fill-c, seriesC)
@st-spider-line(.line-c, seriesC)
@st-spider-dots(.dot-c-, seriesC, 8px)

@st-spider-grid(.spider-grid)
@st-spider-spokes-n(.multi-spokes, 5)

.multi-spider {
  position: relative;
  width: 320px;
  height: 320px;
  border-radius: 50%;
  background: var(--st-surface);
}

.series-a {
  @st-spider-points(seriesA, 42)
  position: absolute;
  inset: 0;
  --st-accent: #ff9f43;
  --st-spider-fill-opacity: 20%;
}
.series-b {
  @st-spider-points(seriesB, 42)
  position: absolute;
  inset: 0;
  --st-accent: #54a0ff;
  --st-spider-fill-opacity: 16%;
}
.series-c {
  @st-spider-points(seriesC, 42)
  position: absolute;
  inset: 0;
  --st-accent: #ff6b9d;
  --st-spider-fill-opacity: 18%;
}

<div class="multi-spider">
  <div class="spider-grid"></div>
  <div class="multi-spokes"></div>

  <div class="series-a">
    <div class="fill-a"></div>
    <div class="line-a"></div>
    <div class="dot-a-1"></div>
    <div class="dot-a-2"></div>
    <div class="dot-a-3"></div>
    <div class="dot-a-4"></div>
    <div class="dot-a-5"></div>
  </div>

  <div class="series-b">
    <div class="fill-b"></div>
    <div class="line-b"></div>
    <div class="dot-b-1"></div>
    <!-- … -->
  </div>

  <div class="series-c">
    <div class="fill-c"></div>
    <div class="line-c"></div>
    <div class="dot-c-1"></div>
    <!-- … -->
  </div>
</div>

Why this stays pure CSS:

No JS chart instance per series
Isolation is DOM + custom properties, not a scene graph
Opacity and accent are tokens (--st-spider-fill-opacity, --st-accent)
Spoke count can match the axis count via @st-spider-spokes-n(..., 5) without tying spokes to one series’ array

If two series shared one host and only one @st-spider-points call, the last write would win and every series would draw the same shape. Separate hosts fix that — the same multi-series rule as linear st-core charts.

Quick start

FSCSS CLI, Vscode extention, or prototyping via its cdn

@import((*) from st-core@v2)

Full API in the repo: github.com/fscss-ttr/st-core.fscss

Pure CSS radar charts are not a compromise. With st-core they’re a styling problem: arrays in, variables out, polygons on screen — lightweight by construction, fast by default.

Stop setting your dark mode background to #000000 and text to #FFFFFF

Sun, 11 Oct 2026 18:40:37 +0000

Pure black on pure white creates high chromatic contrast that causes eye strain and severe halation for readers with astigmatism.

A proper dark theme uses layered dark grays/slates (#121212, #1E1E1E) to express depth through elevation shadows and tinted surfaces rather than stark, blinding contrast.

What are your favorite color palettes for comfortable dark mode reading?

Debugging scroll anchoring when a prepended feed shifts

Fri, 09 Oct 2026 19:59:45 +0000

If a feed prepends new rows while someone is reading older ones, inspect the scroll container before adding JavaScript to adjust its offset. Chromium may already be compensating for the inserted height through scroll anchoring. A transform on the relevant path can suppress that compensation, producing a jump even though the prepend code did not change.

Reproduce the two states

Save this as scroll-anchor.html and open it in Chromium. Click Prepend after the list settles. Then open the same file with ?suppressed=1 and repeat. The two runs differ only in the transform applied immediately before the insertion.

<button id="prepend">Prepend</button>
<div id="viewport" class="viewport"><ol id="feed"></ol></div>
<style>
  .viewport { height: 300px; overflow: auto; }
  .viewport.transform-shift { transform: translateY(0); }
  #feed li { min-height: 72px; }
</style>
<script>
  const viewport = document.querySelector('#viewport');
  const feed = document.querySelector('#feed');
  for (let index = 0; index < 30; index++) {
    const row = document.createElement('li');
    row.textContent = `Message ${index + 1}`;
    feed.append(row);
  }
  feed.children[16].scrollIntoView({ block: 'center' });

  document.querySelector('#prepend').addEventListener('click', () => {
    const before = viewport.scrollTop;
    if (location.search.includes('suppressed=1')) {
      viewport.classList.add('transform-shift');
    }
    const row = document.createElement('li');
    row.textContent = 'New message';
    feed.prepend(row);
    requestAnimationFrame(() => {
      console.log({ before, after: viewport.scrollTop });
    });
  });
</script>

With anchoring enabled, the browser should increase scrollTop to keep the same message near its prior viewport position. With the transform applied, the controlled Chromium fixture used for the original article leaves the offset unchanged, so visible content moves. Compare both the measured offset and the message in view; a single number alone can hide what the reader experienced.

Decide whether to keep anchoring

If the feed should preserve the current reading position, investigate transforms on the scroller and its ancestors before adding manual scroll correction. If movement is intentional, overflow-anchor: none is the explicit CSS opt-out. Apply it only to the section where that behavior is wanted, then retest insertion and focus behavior. Avoid disabling anchoring across a whole page to hide a local layout problem.

This example is a small browser fixture, not a recipe for virtualized lists. The recorded independent test ran in Chromium on Linux; it does not establish identical results in other browsers or in a framework's scrolling abstraction. The MDN scroll anchoring overview describes suppression triggers, and the MDN overflow-anchor reference covers the opt-out.

Read the full article and view the tested screenshots

Halving Codebase Duplication in Static Site Generators

Thu, 08 Oct 2026 00:09:06 +0000

In large-scale static site architectures, especially projects serving thousands of programmatic SEO landing pages such as 2,993 generated routes across duration views and multilingual hubs, markup duplication tends to grow invisibly. When a codebase scales across multiple sibling pages and shared layout files, repetitive boilerplate markup and stylesheet rules accumulate without immediate detection. During a recent static analysis audit using SonarCloud and jscpd, our codebase exhibited an overall duplication rate of 10.36 percent, representing 5,749 duplicated lines across 182 distinct clone clusters. Legal and compliance views each contained identical multi-line style blocks styling document layouts. Timer surface modals and interactive drawers were duplicated verbatim across four key presentation and timer routes. Stage widget markup, including announcement carousels and embedded video players, was repeated across various views. Global theme stylesheets duplicated numerous identical lines of CSS variables between default light theme selectors. While quality gates on new code passed initially, the cumulative technical debt posed high maintenance overhead and pushed repository metrics uncomfortably close to the 50,000 line free-tier ceiling of our static analysis tools. This article explores how to systematically detect, isolate, and collapse that duplication while keeping test suites fully green.

Architectural Decision and Trade-offs

Instead of attempting to micro-optimize small utility functions, we applied a high-impact Pareto extraction strategy. This approach focused on targeting large block clones first, since roughly 80 percent of codebase duplication typically resides in a small fraction of files, specifically inline modal dialogs, drawers, and repeated stylesheet blocks. We extracted all 12 modal backdrops and the realtime cheer drawer into a clean, dedicated component named TimerModals.astro consisting of 821 lines. We then extracted shared stage widgets like announcement slides and video players into StageWidgets.astro, parameterized with flexible props for internationalized layouts. Centralizing legal styling into a dedicated legal.css file imported once per document further reduced inline redundancy. In native CSS, we merged default light theme variables and light data-theme selectors into a unified selector block, leveraging CSS specificity to eliminate duplicate declarations without breaking dark mode operating system toggles. To protect test invariants during these refactorings, assertions that previously scanned raw template strings for specific DOM identifiers were upgraded to dynamically resolve child component imports, maintaining comprehensive coverage without coupling tests to strict file structures.

Implementing Component Extraction and CSS Merging

To see how this works in practice, consider the structural organization of duplicated modal templates in static site generators. Instead of repeating identical modal markup across multiple layout files, isolate the markup into a single parameterized component and import it where needed. The following example demonstrates how an Astro template imports a consolidated modal component and a centralized stylesheet:

---
import TimerModals from '../components/timer/TimerModals.astro';
import StageWidgets from '../components/timer/StageWidgets.astro';
import '../styles/legal.css';

const { pageTitle } = Astro.props;
---
<html lang="en">
  <head>
    <title>{pageTitle}</title>
  </head>
  <body>
    <main>
      <StageWidgets slidesLabel="Announcement" videoLabel="Player" />
    </main>
    <TimerModals />
  </body>
</html>

Similarly, CSS token redundancy can be solved by merging duplicate variable declarations. Instead of maintaining separate blocks for root and explicit light themes, combine them into a single rule set while handling dark mode through media queries:

:root, [data-theme="light"] {
  --color-bg: #ffffff;
  --color-text: #111111;
}

@media (prefers-color-scheme: dark) {
  :root:not([data-theme="light"]) {
    --color-bg: #0b0f19;
    --color-text: #f3f4f6;
  }
}

This method keeps client DOM element identifiers stable, ensuring that existing client-side scripts, accessibility attributes, and end-to-end test selectors continue to function without requiring rewrites of interaction logic.

Verification and Test Suite Integrity

Refactoring massive template blocks carries the inherent risk of breaking downstream layouts or test assertions. To validate our deduplication effort without regressions, we executed a rigorous verification checklist across multiple validation tools. Running the duplication detector confirmed that repository duplication dropped from 10.36 percent down to 5.43 percent across the entire project. Total line count settled at 49,321 lines, placing the repository safely below the strict 50,000 line free-tier boundary. Unit test suites containing 109 individual assertions passed with zero failures. Linter and type check passes reported zero errors across all component files. Finally, executing 96 Playwright end-to-end browser interaction flows confirmed that all modal dialogs, drawer toggles, and UI components behaved correctly in a rendered browser environment. For a related implementation, see Executing A Thorough Technical Project Review.

Conclusion

Systematic codebase deduplication in static site generators requires targeting large structural blocks rather than chasing minor utility redundancies. By isolating repetitive modal dialogs into reusable components, unifying theme tokens, and updating test harnesses to verify composed trees, engineering teams can significantly lower duplication rates. This discipline preserves strict code analysis quotas, reduces maintenance overhead, and ensures that large programmatic websites remain robust and performant as they scale.

Animating a 3D Gift Box with WebGPU

Sun, 04 Oct 2026 12:49:20 +0000

What is WebGPU, in one paragraph?
WebGPU is a modern browser API that gives JavaScript direct, low-overhead access to your graphics card.

It replaces WebGL, which was built mainly for drawing.
WebGPU is modeled on native APIs like Vulkan, Metal and Direct3D 12, and it adds compute shaders, so the GPU can run any parallel math, not just triangles. That’s why it matters for AI: neural networks are mostly giant matrix multiplications, which is exactly what GPUs are good at.

Learn more :-
WebGPU is a modern browser API

FOUC-Proof Retro Design Systems

Sat, 03 Oct 2026 09:06:20 +0000

When building web interfaces with a retro arcade aesthetic, developers often adopt vibrant neon color palettes to recreate an 80s terminal feel. However, applying these bright accents directly across both light and dark surfaces introduces two critical problems. First, neon shades like electric cyan frequently fail minimum WCAG contrast requirements against pale backgrounds, dropping below the 4.5 to 1 ratio needed for accessibility. Second, relying on client-side JavaScript or late-loading framework components to manage theme state causes a jarring Flash of Unstyled Content or white flash during document parsing. Solving these issues requires combining asymmetric color calibration with synchronous pre-render execution in static site generators like Astro. For a related implementation, see Offline First Event Pipeline.

The Pitfall of Retro Aesthetics on the Web

Nostalgic design systems rely heavily on high-contrast neon tones to establish character. While electric cyan or neon green looks striking against a dark matte chassis, using those exact same hex codes on a light background destroys readability. A color that passes contrast checks in a dark environment will often wash out completely on a light surface. Attempting to fix this by handcoding individual theme styles across disparate components leads to code duplication and visual fragmentation. Maintaining a cohesive brand identity requires a structured token architecture that adapts semantically depending on the active theme mode.

The Mathematics of Accessible Contrast

To keep a consistent visual identity without sacrificing readability, the color system must use dual-role semantic token calibration. Instead of forcing identical accent values in both modes, the primary accent variable shifts based on the document theme attribute. In light mode, the system switches to a calibrated deep arcade teal that achieves a WCAG AAA contrast ratio against pale surfaces. In dark mode, it returns to the high-vibrancy electric cyan. Secondary accents, such as a high-energy orange tone, serve consistently as action indicators. The following CSS custom property configuration demonstrates how to structure these semantic tokens at the root level: For a related implementation, see Audit Macos System Data Before Deleting.

:root {
  --surface: #fbfcfc;
  --surface-raised: #f0f2f5;
  --text-main: #111418;
  --accent: #007e85;
  --accent-secondary: #ff5722;
  --line: #d1d5db;
}

[data-theme="dark"] {
  --surface: #0e1114;
  --surface-raised: #161b22;
  --text-main: #f0f6fc;
  --accent: #00adb5;
  --accent-secondary: #ff5722;
  --line: #30363d;
}

Eliminating FOUC with Synchronous Head Scripts

Even with well-structured CSS variables, waiting for external stylesheets or framework hydration to apply the correct theme attribute creates visual flicker. Client-side scripts that execute inside DOMContentLoaded or standard component lifecycles run too late in the rendering pipeline. To eliminate this delay, a blocking script must execute synchronously inside the document head before the body layout paints. By checking localStorage or prefers-color-scheme immediately, the browser can set the target attribute and background color instantly. The following component snippet illustrates how to implement this pattern in an Astro layout:

<script is:inline>
  const storedTheme = localStorage.getItem('theme');
  const prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches;
  const theme = storedTheme || (prefersDark ? 'dark' : 'light');
  
  document.documentElement.setAttribute('data-theme', theme);
  if (theme === 'dark') {
    document.documentElement.style.backgroundColor = '#0e1114';
  } else {
    document.documentElement.style.backgroundColor = '#fbfcfc';
  }
</script>

Maintaining a Single Source of Truth

Scaling a token-based design system across static sites and standalone tools requires clear organizational boundaries. Core platform utilities like extension showcases or isolated calculators may demand independent UI scopes, but editorial and reading surfaces must consume global design variables uniformly. Desktop reading aids, active bullet indicators, and border lines should bind directly to semantic variables like --accent and --line rather than hardcoded color values. Keeping these token mappings documented in a versioned reference file ensures consistency across design vaults and code repositories without introducing runtime overhead.

FSCSS 1.2.5 ships property shorthands: size, px, inset-x, ratio-fit()

Wed, 30 Sep 2026 23:48:53 +0000

A new FSCSS release. This one's aimed at the pairs everyone keeps typing out by hand:

/* before */
width: 32px;
height: 32px;

/* after */
size: 32px;

Same deal for the other repeat offenders:

.card {
  px: 16px;      /* padding-left + padding-right */
  py: 14px;      /* padding-top + padding-bottom */
  mx: auto;      /* margin-left + margin-right */
  max-w: 360px;
}

.overlay-side {
  pos: absolute;
  inset-x: 45px; /* left + right only, top/bottom untouched */
  top: 0;
  h: 4px;
}

The inset-x one is the one I actually wanted to exist. inset: auto 45px sets all four sides, there's no native way to say "just left and right" without writing left and right separately. Now there is.

There's also ratio-fit() for the fill-container-keep-aspect-ratio pattern:

.media > img {
  inset: ratio-fit(16 / 9);
  obj-fit: cover;
}

Compiles ahead of time, no runtime polyfill needed for any of it if you're already compiling with the CLI.

npm install fscss@1.2.5
fscss input.fscss output.css

Also ships stack, hstack, center, auto-fit, truncate, line-clamp, border/background shorthands, and the usual aliases (fs, fw, jc, ai, pos, shadow...). Full map's linked below. There's a real UI using a chunk of these together, a dual-phone budget app template combining this with modules like st-core@v2 charts, if you want to see it in context rather than isolated snippets.

Release: https://github.com/Figsh/xfscss/releases/tag/v1.2.5
Shorthands reference: https://fscss.devtem.org/shorthands
Budget app template: https://github.com/fscss-ttr/st-core.fscss/tree/main/templates/budget-app

Anyone using size/px/inset-x already hit any edge cases worth flagging?

🚨 CSS Specificity — The Hidden Reason Your UI Breaks

Wed, 30 Sep 2026 16:07:21 +0000

Most developers learn CSS specificity once.

They remember:

#id > .class > div

Then move on.

Until one day…

Everything looks correct.

The CSS is present.

The selector is correct.

The z-index looks higher.

And yet the UI is broken.

That’s when CSS specificity stops being a beginner topic and becomes a production debugging problem.

The Production Incident That Started This

Recently, I was working on a microfrontend application.

Everything worked fine initially.

I opened a page, launched a modal and the UI looked correct.

Then I navigated to another microfrontend.

Its CSS got loaded.

After returning to the original microfrontend, suddenly:

❌ Modal appeared behind page content
❌ Overlay behaved incorrectly
❌ z-index looked correct but wasn't working

DevTools showed my CSS rule still existed.

Yet another CSS rule was winning.

The culprit?

CSS Specificity.

🧠 What is CSS Specificity?

CSS specificity is the algorithm browsers use to decide:

Which CSS rule wins when multiple rules target the same element.

Browsers don't simply apply:

"The last CSS rule."

That's one of the biggest misconceptions.

Specificity is calculated first.

Only when specificity is equal does source order become important.

⚔️ Example

.modal {
  z-index: 9999;
}

.some-library .modal {
  z-index: 100;
}

HTML:

<div class="some-library">
  <div class="modal"></div>
</div>

Many developers expect:

.modal

to win because the value is larger.

But CSS doesn't compare values first.

It compares selectors.

🧮 How Specificity Works

Specificity is usually represented as:

ID - CLASS - TYPE

Specificity Table

Selector	Specificity
`*`	0-0-0
`div`	0-0-1
`.modal`	0-1-0
`[type="text"]`	0-1-0
`:hover`	0-1-0
`#dialog`	1-0-0
Inline Style	Highest

MDN defines specificity as the weight browsers calculate to determine which declaration gets applied when multiple selectors match the same element.

Example Calculation

Selector:

button.primary

Contains:

button     → 0-0-1
.primary   → 0-1-0

Total:

0-1-1

Another selector:

#header button.primary

Contains:

#header   → 1-0-0
button    → 0-0-1
.primary  → 0-1-0

Total:

1-1-1

This selector wins.

❌ Myth #1 — Last CSS Always Wins

Many developers believe:

The CSS rule written last wins.

Not always.

Example:

#header {
  color: red;
}

div {
  color: blue;
}

HTML:

<div id="header">
  Hello
</div>

Result:

Red

Why?

Because:

#header = 1-0-0
div     = 0-0-1

Specificity wins before source order.

❌ Myth #2 — Higher z-index Always Wins

This causes countless production bugs.

Developers often write:

.modal {
  z-index: 99999;
}

And expect it to appear above everything.

Not necessarily.

Because:

z-index works inside stacking contexts.

🧠 What is a Stacking Context?

A stacking context is a separate layering environment.

Example:

.parent {
  position: relative;
  z-index: 1;
}

.child {
  position: absolute;
  z-index: 999999;
}

Even with:

the child cannot escape its parent's stacking context.

This is why modal, tooltip, dropdown, and popover bugs often feel confusing.

The Microfrontend Problem

This is where specificity becomes extremely important.

Imagine:

Microfrontend A

.modal {
  z-index: 9999;
}

Microfrontend B

.layout .modal {
  z-index: 100;
}

Specificity:

.modal
0-1-0

.layout .modal
0-2-0

Microfrontend B wins.

Even if your CSS is still loaded.

Why My Fix Worked

Originally:

.modal {
  z-index: 9999;
}

But another selector had higher specificity.

So I wrapped the modal:

<div class="dialog-wrapper">
  <Modal />
</div>

Then:

.dialog-wrapper .modal {
  z-index: 9999;
}

Before:

.modal
0-1-0

After:

.dialog-wrapper .modal
0-2-0

Now my selector became more specific and started winning.

The CSS value never changed.

Only specificity changed.

And the issue disappeared.

🚨 Why This Happens More in Microfrontends

Microfrontends often share:

Same DOM
Same global CSS
Same class names
Same browser environment

Problems include:

CSS leakage
Style collisions
Unexpected overrides
Load-order changes after navigation

This makes specificity bugs significantly more common.

Modern CSS Specificity Features Developers Often Miss

1️⃣ `:is()`

Example:

:is(.btn, .link)

The :is() pseudo-class itself doesn't add specificity.

Instead, it takes the specificity of the most specific selector inside it.

Example:

:is(.btn, #header)

Specificity:

1-0-0

Because:

#header

is most specific.

2️⃣ `:not()`

Many developers think:

:not(.hidden)

adds nothing.

Not true.

:not() itself doesn't contribute specificity.

But selectors inside it do.

Example:

:not(.hidden)

Specificity:

0-1-0

3️⃣ `:where()`

One of the most underrated CSS features.

Example:

:where(.btn)

Specificity:

0-0-0

Always.

:where() intentionally has zero specificity.

This makes it extremely useful for:

Design systems
Component libraries
Shared UI frameworks

Because consumers can easily override styles.

How to Debug CSS Specificity Issues

When CSS isn't applying:

Check these in order:

1. Is the rule present?

Open DevTools.

Verify the CSS exists.

2. Is it crossed out?

Crossed-out CSS usually means:

Another rule won.

3. Which selector is winning?

DevTools shows the winning selector.

Inspect it carefully.

4. Compare specificity

Many bugs become obvious here.

5. Check CSS load order

When specificity is equal:

Last rule wins.

6. Check stacking contexts

Especially for:

Modals
Dropdowns
Tooltips
Popovers

7. Check portals

React portals often render outside expected DOM hierarchy.

This changes how CSS behaves.

🎯 Best Practices

✅ Prefer class selectors over IDs

✅ Avoid deeply nested selectors

✅ Use low-specificity CSS in shared libraries

✅ Use :where() for easily overridable styles

✅ Be careful with global CSS in microfrontends

✅ Avoid excessive !important

Final Thoughts

Most developers think CSS specificity is a beginner topic.

In reality:

It's one of the most common reasons production UIs break unexpectedly.

Especially in:

Large applications
Design systems
Microfrontends
Shared component libraries

The tricky part is that the CSS often looks correct.

The rule exists.

The value is correct.

And yet another selector silently wins.

Understanding specificity deeply transforms CSS debugging from:

Trial and Error

into:

Predictable Engineering

Key Takeaways

CSS does not simply apply the last rule
Specificity determines which selector wins
Higher z-index does not always mean higher visibility
Microfrontends make specificity issues more common
:is(), :not(), and :where() have special specificity behavior
!important should be a last resort
DevTools can quickly reveal specificity conflicts when used correctly

Understanding CSS specificity is one of those skills that feels minor — until it saves you hours of debugging a production UI issue.

FSCSS auto-loop: percentage keyframes

Sat, 26 Sep 2026 07:18:17 +0000

This snippet builds a stepped “processing 0% → 99% → done” animation by looping an array into @keyframes percentages — not a JS timer.

Setup

npm install -g fscss@latest
VS Code: FSCSS language support (FSCSS Support)
File: my-first-fscss.fscss → compile or runtime-load

Source (your idea, tightened)

h2::after {
  content: "...";
  animation: count 10s steps(100) forwards;
}

/* 1, 2, … 99  (auto list for keyframe stops) */
@arr numlist[count(99)]

@define counter(start:ing..., process:ing..., end:ed){`
  0% {
    content: "@use(start)0%";
  }
  @arr.numlist[]% {
    content: "@use(process)@arr.numlist[]%";
  }
  100% {
    content: "@use(end)";
  }
`}

@keyframes count {
  @counter(Processing..., Processing..., Processed)
}

What “auto-loop” is here

Piece	Role
`count(99)`	Builds a numeric list used as 1–99 (engine: `count(n)` / `count(n, 1)` → index list).
`@arr numlist[…]`	Stores that list.
`@arr.numlist[]`	Auto-index: expand once per item.
`@arr.numlist[]%`	Each item becomes a keyframe selector: `1%`, `2%`, … `99%`.
`@define counter(…)`	Template for the keyframe body; `@use(start\|process\|end)` fills labels.
`@counter(…)` inside `@keyframes`	Injects the whole ladder into `count`.

So the loop is compile-time expansion, not for in the browser.

Breakdown

1. Target

h2::after {
  content: "...";
  animation: count 10s steps(100) forwards;
}

Animates content on the pseudo-element.
steps(100) ≈ one visual step per percent over 10s.
forwards keeps the final Processed text.

2. Index array

@arr numlist[count(99)]

Same family as modules indexes: a list long enough to drive stops. Here each value is also the percentage number in the output.

3. Reusable keyframe block

@define counter(start:…, process:…, end:…){` … `}

0% — intro label + 0%.
@arr.numlist[]% — for each n in numlist, emit:
- selector: n%
- content: "<process>n%"
100% — final label only (e.g. Processed).

4. Wire into a named animation

@keyframes count {
  @counter(Processing..., Processing..., Processed)
}

Expands to a long @keyframes count { … } with ~100 content stops.

Shape of compiled CSS (illustrative)

Exact quoting depends on the compiler; structure is:

h2::after {
  content: "...";
  animation: count 10s steps(100) forwards;
}

@keyframes count {
  0% {
    content: "Processing...0%";
  }
  1% {
    content: "Processing...1%";
  }
  2% {
    content: "Processing...2%";
  }
  /* … */
  99% {
    content: "Processing...99%";
  }
  100% {
    content: "Processed";
  }
}

That is the auto-loop: one array walk → many keyframe rules.

Example HTML

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>FSCSS auto-loop counter</title>
  <script src="https://cdn.jsdelivr.net/npm/fscss@1.2.4/runtime.min.js" async></script>
  <link type="text/fscss" href="my-first-fscss.fscss">
  <!-- or: <link rel="stylesheet" href="my-first-fscss.css"> after CLI -->
  <style>
    body {
      font-family: system-ui, sans-serif;
      padding: 2rem;
      background: #0f172a;
      color: #e2e8f0;
    }
    h2 {
      font-size: 1.25rem;
      font-weight: 600;
    }
    h2::after {
      margin-left: 0.35em;
      color: #38bdf8;
    }
  </style>
</head>
<body>
  <h2>Status</h2>
  <!-- ::after shows Processing...0% → … → Processed -->
</body>
</html>

Compile

fscss my-first-fscss.fscss my-first-fscss.css

Mental model

count(99)  →  list of stops
@arr.x[]%  →  “for each item, emit item% { … }”
@define    →  reuse labels (start / process / end)
@keyframes →  holds the expanded ladder

Auto-loop = array auto-index used as keyframe percentages (or selectors elsewhere), so one definition drives N rules.

Variants

Progress label only: change @use(process) strings.
Fewer steps: count(20) + shorter animation / steps(20).
Same pattern for staggered selectors: *Emails are not allowed*[] { animation-delay: … } (as in arrays docs).

Web design trends 2026: what is worth adopting

Fri, 25 Sep 2026 12:24:02 +0000

Most of the 2026 trend coverage describes a real shift: a reaction against the flawless, interchangeable look that AI-generated design produced at scale. Read the roundups from Figma, Webflow and Wix side by side and the same instinct runs through all of them. Make it look like a person decided this.

That reaction contains some things worth adopting, some worth adopting carefully, and a few that will look dated by next summer. Trend lists are written by designers for designers, so they rarely say what a trend costs once it has to be built, made responsive, kept accessible and maintained by people who never saw the mockup. That is the part I want to cover here, trend by trend, from the side of the person who builds it.

Bento grids: adopt

Modular tiles of different sizes, popularised by Apple's product pages and now standard on SaaS marketing sites. It is the rare trend that is structurally useful. Content of unequal importance gets unequal space, the tiles reflow cleanly on small screens, and adding a feature later does not mean redesigning the section.

It is also cheap to build, which is not true of most things on these lists. CSS Grid does nearly all of the work: a few tiles spanning two columns or two rows, a single column below a breakpoint, and nothing that needs JavaScript. If the grid lives inside a component that appears in more than one place, container queries let each tile respond to the space it actually has rather than to the viewport, and every current browser supports them.

One trap is worth knowing before you reach for grid-auto-flow: dense. It fills the holes by pulling later tiles up into earlier gaps, so the visual order can stop matching the source order, and keyboard focus follows the source. For tiles that are just content that is fine. For tiles that are links or buttons, a user tabbing through the grid will jump around it.

The design failure is uniformity. Twelve identical tiles is a table pretending to be a bento grid. The layout works when the size differences mean something, when the biggest tile really is the most important thing, and it needs real content to look designed rather than diagrammatic. Build it with placeholder text and it will look fine in review and empty in production.

Typography as the interface: adopt carefully

Very large, viewport-scaled type carrying the page instead of imagery. Figma lists bold typography among its trends, and Webflow's version is dynamic text treatments. There is an engineering argument alongside the aesthetic one: text weighs almost nothing next to a hero image, so a type-led page can be both striking and fast. When the headline is the largest thing on the screen, it becomes the page's Largest Contentful Paint element, and a block of text paints long before a large photograph finishes downloading.

The care is in the details, and they are exactly the kind a design file does not show. Type sized in vw alone does not grow when someone zooms, because zooming shrinks the viewport by the same factor. Mixing a rem term into the preferred value of a clamp() helps, but it does not guarantee much: Adrian Roselli's tests show fluid type growing noticeably less than plain type at 200% zoom, and text that cannot reach twice its original size is a potential failure of WCAG's resize-text criterion. The only way to know is to zoom your own page to 200% and look.

The rest is ordinary typography that the trend tempts people to forget. Give the headline a minimum that stays readable on a phone and a maximum that stops it eating a wide monitor. Keep body copy to a comfortable line length, somewhere around 65ch, and do not let body text shrink below about 16 pixels to make a huge headline look even bigger. Done without those constraints, it is an accessibility problem wearing a trend's clothes.

Tactile brutalism and intentional imperfection: depends who you are

Raw geometry, hard 1px borders, stark type, visible texture, hand-drawn marks, unpolished photography. Wix files it under elevated brutalism and tactile maximalism, Figma under neo-brutalism. The motivation is explicit: proving a human made this, at a moment when flawless is free. For agencies, designers and brands selling craft or personality, it works and it differentiates.

For a law firm, a medical practice, a manufacturer or a financial service, deliberate roughness reads as carelessness rather than authorship. Trust-sensitive sectors pay for legibility and calm, not for evidence of hands. Know which one you are before buying the aesthetic.

The build cost is low, with one thing to watch: how the texture arrives. Grain done as a full-screen overlay with a blend mode has to be blended again on every frame you scroll, and that bill is paid on the slowest phone that visits. A small tiled image gets the same look for almost nothing. The rest of the style is a gift to accessibility rather than a threat to it, because hard borders and stark black on white bring their contrast with them.

Anti-grid and organic layouts: usually skip

Flowing shapes, overlapping elements, deliberately broken alignment. They look superb in a portfolio shot and they are expensive to build responsively, because every breakpoint is a bespoke decision rather than a rule. Overlap usually means absolute positioning or negative margins, and both break the moment the content changes. A longer heading, a translated label or one extra card, and the composition collapses.

If the site is a showcase and the content is fixed, it can be worth it. On a site that has to survive a marketing team adding sections for three years, a disciplined grid with a few deliberate breaks gets most of the effect at a fraction of the maintenance. Grid makes those breaks cheap, too. Two items can share the same grid lines and overlap without either leaving the layout, which is the version of broken alignment that survives a content change.

Micro-interactions: adopt, but functionally

The consensus has moved from motion as decoration to motion as feedback: a button that acknowledges a press, a field that responds to input, a state change you can follow. Figma lists motion design among its trends. That is good, and it is cheap.

Two constraints keep it good. The first is prefers-reduced-motion, which every current browser supports. For people with vestibular disorders, heavy animation is a real barrier rather than a preference. Reduced does not have to mean none, either: swapping a slide for a short fade usually keeps the feedback and drops the movement.

The second is the interaction cost. Interaction to Next Paint, the Core Web Vital that succeeded First Input Delay, measures how long the page takes to paint after a tap, a click or a key press, and Google counts 200 milliseconds or less as good. Animation that runs JavaScript on the main thread during input is exactly what that metric punishes, so an effect meant to make the page feel responsive can measurably make it less so. Animating transform and opacity in CSS keeps most of that work off the main thread. Animating layout properties from a click or scroll handler puts it straight back.

What I would skip outright

Scroll-jacking, where the page takes over scrolling to run a sequence. It breaks user expectation, keyboard navigation and screen readers, and it has been dying for years without quite finishing. Webflow's 2026 list has a trend called guided scrolling, and it is worth reading closely, because it describes the opposite: progress indicators and visual cues that show where you are while the scroll stays yours. That version is fine. The one that decides how fast you are allowed to move down the page is not.

Heavy 3D on a landing page, unless the product genuinely is the visual. Figma's list opens with 3D and immersive elements, and for a shoe you can spin or a room you can walk through, it earns its weight. Elsewhere the cost is real and rarely repaid. A WebGL <canvas> is not even eligible to be the Largest Contentful Paint element, so the scene itself is never what the metric waits for. What it does is compete with the element that is, for bandwidth and for the main thread. On our own site the three.js scenes are loaded with a dynamic import and kept out of the initial bundle entirely, so the headline and the text never wait for them.

Cursor effects, which do not exist on a phone or a tablet, where a large share of your traffic arrives.

And AI-generated stock imagery. Twelve months ago it read as modern. It now reads as cheap, precisely because everyone has seen the same aesthetic. Real photographs of real things, even imperfect ones, are the safer bet for trust, which is the whole point of the intentional-imperfection trend.

The part that is not a trend

Every year the list changes, and the two things that decide whether a site performs do not: it loads fast, and everyone can use it. A trend-perfect site that takes four seconds to show its headline, or fails keyboard navigation, loses to a plain one that does neither. Spend the design budget on the trends that survive that test — bento structure, type-led pages, functional motion — and treat the rest as taste.

That is also the question worth asking of any trend before it goes into a build. What does it cost at the breakpoints nobody mocked up, in the language nobody designed for, on the slowest phone that will visit? The good ones are cheap in all three places. The rest are cheap only in the screenshot.

The original

This is the longer, build-side version of a guide on our site. The original is the short version for the people paying for the design, and it ends with the questions clients ask about all this: whether to follow trends at all, how often a business site should be redesigned, whether trendy designs hurt SEO, and whether minimalism is finished.

Web design trends 2026: what is worth adopting

Layout Grids in CSS: Designing with Millimeter Precision Before Writing Code

Tue, 22 Sep 2026 06:00:00 +0000

If you find yourself constantly guessing gap, padding, and margin values in your browser inspect tool, you are likely skipping a fundamental step: establishing a layout grid system before writing layout CSS.

In traditional editorial design, grids provide visual harmony, alignment, and proportional scaling across print pages. In frontend engineering, a mathematical layout grid bridges the gap between raw CSS containers and intentional visual design.

1. The 8pt Spatial System

The most versatile framework for modern web interfaces is the 8pt grid rule (8px, 16px, 24px, 32px, 48px, 64px). Because most screen dimensions are divisible by 8, aligning component padding, margins, and line heights to multiples of 8 creates natural visual rhythm.

/* Predictable Spatial System Tokens */
:root {
  --space-1: 0.25rem; /* 4px */
  --space-2: 0.5rem;  /* 8px */
  --space-3: 1rem;    /* 16px */
  --space-4: 1.5rem;  /* 24px */
  --space-5: 2rem;    /* 32px */
  --space-6: 3rem;    /* 48px */
}

2. Moving Beyond Hardcoded Layout Spans

Instead of setting rigid pixel widths on individual components, leverage CSS Grid with explicit fractional track ratios (fr) and fluid min-max clamping. This mirrors professional editorial layout grids directly in the DOM.

/* Clean Editorial Grid Layout */
.grid-editorial {
  display: grid;
  grid-template-columns: repeat(12, minmax(0, 1fr));
  gap: var(--space-4);
  max-width: 1200px;
  margin-inline: auto;
  padding-inline: var(--space-3);
}

/* Main Content Spans 8 Columns, Sidebar Spans 4 Columns */
.main-content {
  grid-column: span 12;
}

.sidebar {
  grid-column: span 12;
}

@media (min-width: 768px) {
  .main-content {
    grid-column: span 8;
  }
  
  .sidebar {
    grid-column: span 4;
  }
}

3. Fluid Alignment with `clamp()`

To maintain precision across screens without writing dozens of media queries, combine grid gap logic with mathematical fluid scaling using clamp():

.card-grid {
  display: grid;
  /* Automatically fits items with a minimum width of 280px */
  grid-template-columns: repeat(auto-fit, minmax(min(280px, 100%), 1fr));
  /* Fluid spacing that scales continuously between mobile and desktop */
  gap: clamp(1rem, 2.5vw, 2rem);
}

Systemic Spacing Beats Trial and Error

When you build web layouts using an explicit grid math system, you stop tweaking CSS margins by trial and error. Your layouts become predictable, accessible, and resilient across screen sizes.

Call to Action (CTA)

Do you use strict spatial systems (like the 8pt grid) in your stylesheets, or do you adjust layout spacing visually as you build? Let’s discuss in the comments!

(Published by Joseph Salaki — Visual Designer & Frontend Engineer at byjoemetry.com)

How to Use st-core.fscss with Svelte

Mon, 21 Sep 2026 12:45:40 +0000

st-core.fscss draws charts with pure CSS, clip-path polygons plus custom properties, no JS chart library, no SVG, no canvas. Svelte doesn't need to draw anything for it. It just needs to own the data and reactively set --st-p1, --st-p2, and so on whenever your series changes. Wanted to write up the actual integration because getting the responsibilities split correctly took me a minute the first time through.

Why compiled mode, not the runtime CDN

Svelte already has a build pipeline. Shipping the FSCSS runtime to a Svelte app just to expand a few chart mixins into static CSS is unnecessary work for the browser to do on every load. The runtime CDN script is fine for a CodePen or a quick static HTML demo, but for an actual Svelte or SvelteKit app you compile once at build time and import plain CSS.

Three layers, each with one job:

Layer	Job
FSCSS CLI	Expand `@st-chart-fill` / `@st-chart-line` into static CSS
Svelte	Reactive `data[]` → `--st-pN`
Browser CSS	Paint, plus optional `clip-path` transitions

Svelte state  →  style="--st-p1: 30%; --st-p2: 45%; …"
                      ↓
              compiled st-core.css
                      ↓
                 chart on screen

1. Write the FSCSS entry file

src/styles/st-core.fscss:

@import((*) from st-core@v2)

@st-root()

/* Length at compile time = number of polygon stops */
@arr chartData[0, 0, 0, 0, 0, 0, 0]

@st-chart-fill(.chart-fill, chartData)
@st-chart-line(.chart-line, chartData)

.chart {
  @st-chart-points(chartData)
  position: relative;
  width: 100%;
  height: 220px;
  background: var(--st-surface);
  border-radius: var(--st-radius-lg);
  overflow: hidden;
}

.chart-fill,
.chart-line {
  transition: clip-path 0.5s cubic-bezier(0.4, 0, 0.2, 1);
}

The zeros are placeholders, they only matter for their count. Svelte overwrites the real Y values through CSS variables at runtime. What you can't change without recompiling is the array's length — match it to your series (7 days of data → 7 entries).

2. Compile it as part of your build

npm install -D fscss@latest
npx fscss src/styles/st-core.fscss src/styles/st-core.css

Wire it into package.json so it runs automatically before every build:

{
  "scripts": {
    "build:st-core": "fscss src/styles/st-core.fscss src/styles/st-core.css",
    "prebuild": "npm run build:st-core"
  }
}

Then import the compiled CSS once, wherever makes sense for your app (root layout, app.css, or the chart's parent component):

import '../styles/st-core.css';

3. Map your data to `--st-pN`

Chart geometry in st-core is top-down, the same way CSS itself is. A high value needs to sit near 0%, not 100%. So every point gets inverted:

--st-pᵢ = (100 - humanValue) %

A score of 90 ends up 10% from the top, which is exactly where you'd expect it visually.

Here's a reusable Chart.svelte that does that mapping reactively, Svelte 4 style:

<script>
  /** @type {number[]} 0–100, higher = taller */
  export let data = [];
  export let height = '200px';
  export let color = '#9d7eff';

  $: cssVars = [
    ...data.map((value, index) => `--st-p${index + 1}: ${100 - value}%`),
    `--st-accent: ${color}`,
    `height: ${height}`
  ].join('; ');
</script>

<div class="chart" style={cssVars}>
  <div class="chart-fill"></div>
  <div class="chart-line"></div>
</div>

And the Svelte 5 version, using $props / $derived instead of the old export-let / reactive-statement pattern:

<script>
  let { data = [], height = '200px', color = '#9d7eff' } = $props();

  let cssVars = $derived(
    [
      ...data.map((value, index) => `--st-p${index + 1}: ${100 - value}%`),
      `--st-accent: ${color}`,
      `height: ${height}`
    ].join('; ')
  );
</script>

<div class="chart" style={cssVars}>
  <div class="chart-fill"></div>
  <div class="chart-line"></div>
</div>

Both do the exact same job, just with whichever reactivity API your Svelte version uses.

4. Use it like any other component

<script>
  import './styles/st-core.css';
  import Chart from './lib/Chart.svelte';

  let weekly = [45, 70, 30, 90, 60, 80, 50];

  function randomize() {
    weekly = Array.from({ length: 7 }, () => Math.floor(Math.random() * 80) + 10);
  }
</script>

<Chart data={weekly} color="#4fffb0" height="250px" >

<!-- Svelte 4 -->
<button type="button" on:click={randomize}>Randomize</button>

<!-- Svelte 5 -->
<!-- <button type="button" onclick={randomize}>Randomize</button> -->

Reassigning weekly recomputes cssVars, the browser applies the new custom properties, and the compiled CSS's clip-path transition animates the shape change. No chart library re-rendering, no SVG path recalculation, no manual DOM diffing on your end.

Fixed length vs changing length

Because geometry is baked in at compile time, the array length is the one thing you can't change on the fly:

Situation	What to do
Always exactly N points	Compile `@arr chartData` with N zeros, always pass exactly N values from Svelte
Length varies, up to a max of M	Compile M zeros, then `data.slice(0, M)` and pad shorter series with `0`

If you compile a template expecting 5 points and hand it 8 values from Svelte, the extra --st-p6, --st-p7, --st-p8 have nowhere to go, there's no polygon stop for them until you recompile with a longer array.

What not to do in production

<!-- Fine for a demo, avoid as your only path in a real Svelte app -->
<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.3/runtime.min.js"></script>

Runtime mode is for CodePen and quick static HTML, not for a build pipeline that already exists. See the plain HTML integration sample if that's what you actually want.

The mental model, condensed

@st-chart-points, fill, and line define the structure and only ever read --st-p*.
Svelte's only job is to replace those variables when the data changes.
transition: clip-path gives you motion for free, no animation library needed.

Nothing here is Svelte-specific past step 3, the same pattern maps directly to Vue, React, or vanilla JS, only the reactivity layer changes. Contributions for other frameworks welcome under integration/.

Repo: github.com/fscss-ttr/st-core.fscss
Svelte sample: integration/svelte

Finally Shipped st-core.fscss v2 — CSS Charts Without the 8-Point Ceiling

Sat, 19 Sep 2026 01:08:17 +0000

For a while, st-core.fscss charts had one annoying limit: every line, fill, and dot was locked to exactly 8 data points. --st-p1 through --st-p8, hardcoded. Want to plot 12 weeks of revenue? Tough. Want 5 points for a quick demo? You'd pad the array with zeros and hope nobody noticed.

v2 gets rid of that.

The core change: Array (`@arr`)

Instead of passing 8 raw numbers into @st-chart-points, you now declare a named array of any length:

@arr myData[50, 10, 97, 35, 66, 50, 80, 54, 70, 60]

@st-chart-fill(.chart-fill, myData)
@st-chart-line(.chart-line, myData)

st-core reads the array length at compile time, works out even X-spacing across the chart width, and builds the clip-path: polygon() shape from however many points you gave it. 5 points, 12 points, 50 points, doesn't matter. No more counting to 8.

The gotcha that took me a minute to internalize

Here's the part that actually tripped me up while building the multi-series examples: @st-chart-line(selector, array) and @st-chart-fill(selector, array) aren't what set the data on an element. They declare the renderer for that selector, the array argument just tells it how many points to expect.

The thing that actually writes --st-p1…--st-p{n} onto an element is @st-chart-points(array).

That distinction matters the moment you have more than one series on a chart. In a multi-line setup, if .line-b doesn't call @st-chart-points(seriesB) itself, it silently inherits whatever the parent container set, meaning it renders the wrong dataset. Looks fine at a glance, wrong shape in practice. Caught it while building a 3-series dashboard card where two lines were quietly drawing the same data.

.fill-b {
  @st-chart-points(seriesB)   /* required, not optional */
  opacity: 0.3;
  --st-accent: #4fffb0;
}

Once that clicked, the mental model got simple: renderer declarations are structural (once per selector), point data is per-element (as many times as you have distinct series).

How it feels to ship

Pure CSS charting was already a fun constraint to design inside of, no JS runtime, no SVG, no canvas. Making the dataset size flexible removes the last thing that made it feel like a toy rather than something you'd reach for on a real dashboard. Compiled output is still under a kilobyte. Still zero hydration.

Docs and full examples are up in the repo, including the legacy v1 reference for anyone still on fixed 8-point charts.

Repo: github.com/fscss-ttr/st-core.fscss

Open-source

with ♥️

The source code is totally math notebook 😅

Have been writing and debugging from morning till night, and finally released it. The usage is now as simple as CSS.

😊

Stop Using Value-Based CSS Variables: Why `--color-action-primary` Beats `--accent-blue`

Mon, 14 Sep 2026 06:00:00 +0000

When setting up CSS custom properties for a new project, it’s tempting to name variables after the values they hold. We’ve all written code like --accent-blue: #3b82f6; or --dark-gray: #1e293b;.

It feels quick and explicit at first. But as soon as your design scales—or as soon as you need to implement dark mode—value-based variable names start working against you.

The Problem with Value Names

Value-based names tell you what a color is, but they don't tell you how or where it should be used.

If --accent-blue is used for primary buttons, active tab borders, focus rings, and success notifications, what happens when a design update changes the primary button to purple while keeping focus rings blue? You end up creating --accent-blue-2 or --accent-purple, and your stylesheet grows sideways.

Even worse, value names completely break down under theme switching:

/* Fragile: Value-based naming in Dark Mode */
:root {
  --bg-white: #ffffff;
  --text-black: #0f172a;
}

[data-theme="dark"] {
  /* Reading "--bg-white" when the hex is dark gray creates instant code confusion */
  --bg-white: #0f172a; 
  --text-black: #f8fafc;
}

The Solution: Semantic Tokens

Semantic design tokens give variables a role rather than a descriptive name. A semantic token answers the question: "What function does this element perform in the UI?"

When you name custom properties by intent, dark mode and component overrides become effortless:

/* Scalable: Role-based Semantic Tokens */
:root {
  /* Primitive Brand Values */
  --blue-600: #2563eb;
  --slate-900: #0f172a;
  --slate-50: #f8fafc;

  /* Semantic UI Tokens (Light Theme) */
  --color-surface-base: var(--slate-50);
  --color-text-main: var(--slate-900);
  --color-action-primary: var(--blue-600);
  --color-border-focus: var(--blue-600);
}

[data-theme="dark"] {
  /* Dark Theme Overrides map seamlessly without changing variable names */
  --color-surface-base: var(--slate-900);
  --color-text-main: var(--slate-50);
  --color-action-primary: #3b82f6;
  --color-border-focus: #60a5fa;
}

How Semantic Tokens Simplify Component Code

By enforcing semantic tokens, your component styles become immune to global color refactors:

.button-primary {
  background-color: var(--color-action-primary);
  color: var(--color-text-inverse, #ffffff);
}

.button-primary:focus-visible {
  outline: 2px solid var(--color-border-focus);
}

When your tokens describe intent, changing a color scheme across an entire application takes seconds—and your codebase remains self-documenting for any engineer who reads it.

Call to Action (CTA)

How do you usually structure your CSS variables? Do you rely on raw color names or strict semantic tokens when scaling dark mode? Let’s talk in the comments!

(Published by Joseph Salaki — Visual Designer & Frontend Engineer at byjoemetry.com)

Building Circular UI with circle-progress.fscss (No JavaScript)

Sun, 13 Sep 2026 23:02:30 +0000

Circular progress, pie charts, and step rings usually mean SVG path math or a chart library.
circle-progress.fscss does it with pure CSS — conic-gradient, masks, and FSCSS @define helpers.

Repo: Figsh/Circle-progress.fscss

What you get

Component	Define
Progress ring	`@circle-progress`
Solid pie	`@circle-pie`
Multi-slice pie	`@circle-pie-multi`
Steps ring	`@circle-steps`
Nested rings	Compose by nesting elements

All driven by CSS variables. Change --progress-value and the arc follows.

Setup

Option A — runtime (quick / prototyping)

<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.1/runtime.min.js" defer></script>

Option B — CLI compile (production)
It works well with FSCSS vscode extention

npm install -g fscss
fscss styles.fscss styles.css

Import the module:

@import((*) from circle-progress)

@progress-root()
@circle-progress(.progress-circle)

Full sample page:
samples/example.html

1. Progress ring

<div class="progress-circle p72">72%</div>

.p72 { @progress-range(72) }

Under the hood: a conic-gradient draws the arc, a radial mask cuts the hole, and a small tip marker rotates with the value.

2. Color override

.p41 {
  @progress-range(41)
  --progress-color-arc: #4d9fff;
  --progress-color-glow: rgba(77, 159, 255, 0.45);
}

Same component — only tokens change.

.p88 {
  @progress-range(88)
  --progress-color-arc: #ffb830;
  --progress-color-glow: rgba(255, 184, 48, 0.4);
}

3. Pie slice

<div class="circle-pie p30">30%</div>

@circle-pie(.circle-pie)
.p30 { @progress-range(30) --progress-color-arc: #ff5070; }

No mask — the conic fill is the whole disk.

4. Multi pie

<div class="circle-pie-multi pie-a"></div>

@circle-pie-multi(.circle-pie-multi)

.pie-a {
  --pie-a: 30;
  --pie-b: 25;
  --pie-c: 20;
  --pie-d: 15;
}

Four slices from four percentage tokens.

5. Steps ring

<div class="circle-steps steps-5">5/8</div>

@circle-steps(.circle-steps)
.steps-5 { @steps-done(5) @steps-total(8) }

.steps-3 {
  @steps-done(3)
  @steps-total(6)
  --progress-color-arc: #9d7eff;
}

6. Nested rings

<div class="progress-circle p72" style="--progress-size:200px">
  <div class="progress-circle p41"
       style="--progress-size:120px;--progress-stroke:10px">
    41
  </div>
</div>

Same define, different size/stroke on the child — composition without new APIs.

Mental model

Tokens — @progress-root() sets size, stroke, colors, value.
Shape — one @define per pattern (ring, pie, steps).
Value — @progress-range(n) or --progress-value.
Theme — override --progress-color-arc / --progress-color-glow.

No SVG paths. No chart library. Change a variable, the circle updates.

When to use runtime vs CLI

Use case	Prefer
Demos, CodePen, quick tests	CDN runtime
Production, static deploy	CLI compile to plain CSS

Runtime keeps FSCSS syntax in the page. CLI ships zero-runtime CSS.

Try it

Clone or copy from the repo and open the sample:

github.com/Figsh/Circle-progress.fscss
Sample: samples/example.html

Swap values, nest rings, add a pie — same module, different tokens.

Built with FSCSS @define · pure CSS circular UI

FSCSS v1.2.0 is out: two clean entry points, full backward compatibility, and inline

Sat, 05 Sep 2026 08:26:35 +0000

FSCSS is open source, built in the open, and free for anyone to use, extend, or pick apart. That's the whole point of it. Every release is meant to make it easier for other developers to build with, not harder. v1.2.0 is the clearest example of that yet.

What shipped

Previous versions of FSCSS scattered their browser-facing files across the package: /e/exec.js, /exec.js, /xfscss.js, /xfscss.min.js, and more. Depending on what you needed, you'd end up guessing which file was the right one to load.

v1.2.0 consolidates all of that into two public entry points:

<!-- Auto-run, for plain HTML pages -->
<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.0/runtime.min.js" async></script>

// Manual control, for tooling and modules
import xfscss from "https://cdn.jsdelivr.net/npm/fscss@1.2.0/esm.js";

runtime.js auto-scans the page and compiles everything on load, <style> blocks, <link type="fscss"> sources, and now inline style attributes too. esm.js never auto-runs and never touches page loading, since it's meant for using FSCSS as a tool: an FSCSS-to-CSS converter, a build step, or any pipeline where you decide what gets processed and when.

Use one or the other. Never both.

Nothing breaks

This is the part worth repeating: the npm package and CLI are completely unchanged, and every method that worked in the 1.1.x line still works exactly the same way in 1.2.0. @define, @fun, @event, @arr, pattern(), all of it. The consolidation only touches the browser entry-point files. If you're compiling ahead of time with the CLI, this release changes nothing for you.

Inline styles now go through the full pipeline

This is the headline feature. From v1.2.0, style="..." attributes are compiled on boot the same way <style> blocks are:

<style>
  @define btn-style(bg: #636EE7){
    padding: 10px 20px;
    color: color-mix(#dddddd, @use(bg));
    background: @use(bg);
    border: 2px solid;
    border-radius: 25px;
    font-weight: 700;
  }
</style>

<button style="@btn-style(#1a2a4f)">Search</button>
<button style="@btn-style(#f00f00)">Search</button>

Combined with xfscss.process(), that means an inline mixin call can be recompiled at runtime and swapped straight back into the element, no rewritten CSS, no framework state:

const update = async (btn) => {
  const newStyle = await xfscss.process("@btn-style(@arr.colors!.randint)");
  btn.setAttribute("style", newStyle);
};

The full walkthrough of this: including a detail (method declared inline stay resolvable even after their declaration is cleaned out of the attribute), if you want to go deeper: FSCSS v1.2.0 lets you write mixins directly in style="...".

Why this matters for an open-source tool

None of this is about adding complexity for its own sake. FSCSS exists to cut down on repetitive CSS and give developers capabilities plain CSS doesn't have natively, and every release should make that easier to reach for, not harder to keep up with. Two entry points instead of a pile of internal files. Full compatibility instead of a migration guide. A feature that makes the JS API and the language work together instead of sitting side by side.

Open source only stays useful if the people using it can trust an upgrade won't cost them a rewrite. That's the bar this release was held to.

try it

npm install fscss@latest

<script src="https://cdn.jsdelivr.net/npm/fscss@1.2.0/runtime.min.js" async></script>

Bug reports, feature requests, and pull requests are all welcome on GitHub

The bug nobody fixed for 4 years (and how it got me my first Contributor badge)

Tue, 01 Sep 2026 23:02:15 +0000

Have you ever opened the issues tab of an open source project, stared at the list, and closed it?

I have. More than once.

The feeling is always the same: "this is for grown-ups, I'm not good enough to touch it". So you close the tab, go back to your side project, and contributing becomes something you'll do when you're "ready".

Spoiler: you'll never be ready. I started by fixing a footer that broke on mobile.

The project and the bug

TimeConv is a simple time converter: you give it a date and it hands you back UTC, seconds, or whatever timezone you asked for. Static site, hand-written HTML and CSS, no framework.

Issue #41 said the footer broke on mobile. Opened in August 2022. Four people passed through it over the years, diagnosed the problem, agreed with the diagnosis...

And not one of them opened a PR.

That's the kind of issue I recommend if you're starting out: old, already diagnosed by other people, and with nobody working on it. Half the work is done and the odds of duplicating someone's effort are low.

The CSS bug that wasn't a CSS bug

The original code did this:

footer {
  position: absolute;
  height: 15vh;
  bottom: 0;
}

Absolutely positioned footer, pinned to the bottom. Works beautifully — until the page has enough content to scroll. Then the footer floats in the middle of your text, because bottom: 0 is relative to the viewport, not to the content.

The modern fix is the flexbox sticky footer: make body a flex column with min-height: 100vh, and give the footer margin-top: auto, which pushes it into whatever space is left over.

I swapped it, tested it, and... two pages didn't budge.

Here's the part I didn't see coming, and the most useful thing I took from this contribution: margin-top: auto only pushes an element if it's a direct child of the flex container. In credits.html the footer sat four levels deep inside a .row — which is a horizontal flex container. And in utcsecondstodatetime.html it was literally outside <body>.

So I opened the HTML of those two files and found a duplicated <html>, orphan </div>s, and tags closing out of order. The file was broken badly enough that prettier couldn't even parse it.

Which means: the issue was filed as a CSS bug, and no amount of CSS was ever going to fix it without touching the HTML. That's why four people diagnosed it and nobody shipped — the diagnosis was only half right.

Final PR: 7 files, 175 lines added, 174 removed.

The red check that almost killed it

PR opened, and CI lights up: Lint Code Base failed.

The beginner reflex (mine included) is to run prettier --write across the repo and push everything green. Don't. That would have added ~138 lines of reindentation to a 7-file PR, and the reviewer would have had to separate the fix from the formatting.

What I did instead was pull the original files from main and run the linter against them:

npx prettier --check docs/
npx htmlhint docs/

Result: the original files already failed. And utcsecondstodatetime.html on main didn't even parse. htmlhint reported 18 errors on the original versus 0 on mine.

I posted that in the PR, with the output from both sides. That is precisely what unblocked the merge — the maintainer could see the red was inherited instead of taking my word for it.

It's a rule for me now:

An inherited red check gets explained with reproduced evidence, not fixed by growing the PR.

Three weeks after opening it (and one polite ping along the way, because maintainers of small projects do go quiet), I got an "Awesome, LGTM!" and the merge.

Hands on: test a static site in 30 seconds

No Node, no build step, nothing:

git clone https://github.com/ArjunSharda/TimeConv.git
cd TimeConv/docs
python3 -m http.server 8000

Open http://localhost:8000, hit F12, turn on the device toolbar and test at 320, 375 and 768 pixels wide. Test one short page and one long page — a footer bug only shows up in one of them.

That's the entire test loop for a static-site contribution. Really.

"But that's just CSS, it doesn't count"

It counts. And let me lay out both sides, because this choice is yours.

Small project. Upside: the maintainer actually reads your PR, the codebase fits in your head, and you get to close the full issue → PR → merge loop, which is where the learning lives. Downside: little reach, sometimes an inactive maintainer, and a process too informal to teach you rigor.

Large project. Upside: serious CI, hard review, documented conventions — you learn the craft. Downside: long review queues, and a real chance someone fixes the bug before you do (that happened to me on another project, and it's an article of its own).

I don't think there's a right side. I think starting small and moving up is kinder to your motivation.

Wrapping up

Seven files, 175 lines added, zero lines of complex logic. Result: a Contributor badge and a four-year-old issue closed.

What was blocking that issue wasn't technical difficulty. It was that nobody had opened the HTML.

Your turn: open the issues tab of a project you actually use, filter by is:issue is:open sort:created-asc, and look at the oldest ones. One of them is waiting for somebody to open the file.

And if you do it, brace yourself for one thing: the merge isn't the end. After mine landed I got excited and kept poking around the site — and while testing the pages in the browser, I noticed the converters only worked once. A second conversion needed a page reload.

There were two bugs. They hid each other, with a side effect that pushed whatever the user typed straight into their browser history.

That's the next article.

Author's note: this was my first contribution to TimeConv, merged in August 2026. I'm documenting every open source contribution I make in this series. If you contribute to open source too, I'd like to hear about it.

References

Building Fluentic Style: Bringing React Native Style Composition to React

Sat, 29 Aug 2026 01:22:22 +0000

Fluentic Style is my attempt to make React styling feel explicit, composable, and predictable again, without giving up the ergonomics developers expect.

Years ago, I worked on web apps with Emotion, and I loved it.

It was flexible, productive, and convenient. But over time, some of the codebases I worked on became harder and harder to change. I do not blame Emotion for that. The problem was how I used the convenience it gave me.

I wrote class names that depended on DOM structure. I used nested selectors because they were quick. I reached into child elements from parent styles. It worked, until months later I had to change something and no longer felt confident about what else would break.

That feeling is what I remember most.

Not that the styling was impossible. Not that the tool was bad. Just that I slowly lost confidence when changing UI.

The Problem Was Confidence

A lot of frontend styling problems are not about whether something is technically possible.

CSS is powerful. CSS-in-JS is powerful. Utility classes are powerful. CSS Modules are useful. Static extraction is useful.

The hard part is usually confidence.

Can I change this component without accidentally changing another component?

Can I understand where this style comes from?

Can I tell which style wins?

Can I move this element without breaking some selector far away?

Can I delete this class name?

Can I add a variant without making the component more fragile?

When styles depend on class names, DOM structure, nested selectors, and implicit relationships between elements, every change becomes a little less obvious.

You can still build good systems this way. Many teams do.

But that way of styling makes it very easy to create hidden coupling.

And hidden coupling is where confidence starts to fade.

Then I Spent Years in React Native

After that, I spent years mostly working on React Native projects.

React Native styling changed how I think about UI.

The styling model is much smaller:

<View style={[styles.root, disabled && styles.disabled, style]} />

Styles are objects.

Styles are passed as values.

Arrays compose styles.

The later style wins.

Variants are usually explicit.

The style belongs close to the element that uses it.

There is no class name pretending to be both identity and styling hook. There is no global selector reaching through some DOM structure. There is much less “where did this come from?”

Of course React Native styling is not perfect. It has its own limitations. But the mental model is very simple.

And after using that model for years, I came back to React web.

That was when web styling felt more complicated to me than it used to.

Not because CSS got worse.

Actually, CSS got much better.

We have better layout. Better selectors. Better browser support. Better build tools. Better frameworks.

But for component-heavy React work, I started to miss the React Native mental model a lot.

In React Native, this kind of style composition is completely normal:

<View style={[base, variant, state, props.style]} />

And that normality matters.

Base first. Then the variant. Then the current state. Then the style passed from outside.

It makes styling feel like data. Like values. Like composition.

Not like a string contract with the DOM.

React web already has pieces of this too. Emotion’s css prop can feel especially close, and other tools have their own ways to compose styles.

However the thing I wanted was not just style composition for one element.

React Native does not solve every part of this either. When a component has multiple internal elements, you still need to decide which parts can be styled and how those styles are passed through.

I wanted the same explicit composition to work not only for one root element, but across a whole styleable component: root, icon, label, header, content, footer, or whatever parts the component chooses to expose.

Not just root element composition:

<Component css={[base, variant, props.css]} />

But a component style theme where each public part can be composed explicitly, without the caller reaching into DOM structure or relying on class names as hidden hooks, with something as simple as this:

<Component theme={[baseTheme, variantTheme, props.theme]} />

That is where Fluentic started to feel different.

React Web Has Something React Native Misses

But I do not want to pretend React Native has the perfect model.

It does not.

The web has something extremely useful: selectors.

Sometimes selectors are exactly what you want.

You want hover states:

.button:hover {
  background: var(--hover);
}

You want focus states.

You want child coordination.

You want media queries.

You want pseudo elements.

You want to style based on parent state.

You want to express relationships without manually passing a style prop into every single element.

That is real power.

React Native often makes this more manual. You wire state. You pass style props. You conditionally apply styles element by element.

That explicitness is nice until it becomes repetitive.

So the question I kept thinking about was:

Can React styling keep the simple React Native mental model, but still keep the useful parts of CSS?

Can styles be values, while selectors still exist?

Can composition be explicit, while output is still real CSS?

Can override order be obvious, while runtime work stays small?

That question became the beginning of Fluentic.

Extraction Is Not the New Idea

Modern React styling has changed a lot.

Runtime CSS-in-JS used to feel like a reasonable default for many React apps. Today, the tradeoffs are more visible.

Performance matters.

Server rendering matters.

Streaming matters.

React Server Components changed what can happen on the server and what should happen on the client.

Build-time extraction is no longer a niche idea. In many modern stacks, it feels close to mandatory.

But extraction itself is not the interesting part anymore.

There are already many libraries that extract CSS.

That is not the main reason I started working on Fluentic.

The thing I felt missing was not “another extracted CSS-in-JS library”.

The thing I wanted was a different way to write and compose styles.

A model closer to what I had in my head after years of React Native:

styles as values
explicit composition
predictable override order
local ownership
variants without magic class names
selectors when useful, but not as the default way to connect everything
build-time output that fits modern React apps

That is the shape of Fluentic.

What I Want From a Styling System

When I started thinking about Fluentic, I wrote down the requirements more like a frontend developer who has been hurt by his own past decisions than like someone trying to invent a styling library.

The requirements were not only technical.

They were emotional too.

I wanted to feel confident changing UI again.

1. Styles Should Be Values

In React Native, a style is something you can pass around.

<View style={styles.card} />

Or compose:

<View style={[styles.card, elevated && styles.elevated]} />

That feels very different from:

<div className={`${styles.card} ${elevated ? styles.elevated : ""}`} />

The class name version works, of course. But the mental model is different.

One feels like composing values.

The other feels like constructing a string that points to styling somewhere else.

In Fluentic, the equivalent idea uses style(...) and the JSX css prop:

import { style } from '@fluentic/style';

const styles = {
  card: style({
    padding: 16,
    borderRadius: 8,
    backgroundColor: 'white',
  }),

  elevated: style({
    boxShadow: '0 12px 30px rgb(15 23 42 / 0.16)',
  }),
};

function Card({ elevated }: { elevated?: boolean }) {
  return (
    <section css={[styles.card, elevated && styles.elevated]}>
      Ready to style.
    </section>
  );
}

The syntax is different from React Native, because the target is still the browser.

But the feeling is familiar:

Base style first.

Conditional style after.

The style value is passed directly to the element.

2. Override Order Should Be Obvious

One of the nicest things about React Native style arrays is that the later item wins.

<View style={[styles.base, styles.large, props.style]} />

You can read that line and understand the override order.

Base first.
Then large.
Then external style.

There is very little mystery.

On the web, override order can come from many places:

stylesheet order
selector specificity
class order
nested selectors
cascade layers
inline styles
generated CSS order

Some of these are powerful. Some are necessary. But when building components, I often want the boring rule:

later style wins

Fluentic is designed around that kind of predictability.

<button css={[styles.button, primary && styles.primary, props.css]}>
  Save
</button>

That is the kind of composition I want to keep visible in React code.

3. Variants Should Be Explicit

I have written many components where styles were controlled by a mix of class names and nested selectors.

Something like:

.card.compact .title {
  font-size: 14px;
}

.card.highlighted .title {
  color: blue;
}

This is convenient.

It also couples the parent state, child structure, and class names together.

Later, when the component changes, the style assumptions are still sitting there.

For a local component, explicit composition can be enough:

const styles = {
  card: style({
    padding: 16,
    borderRadius: 8,
    backgroundColor: 'white',
  }),

  compactCard: style({
    padding: 12,
  }),

  title: style({
    fontSize: 20,
    fontWeight: 700,
  }),

  compactTitle: style({
    fontSize: 16,
  }),
};

function Card({ compact }: { compact?: boolean }) {
  return (
    <div css={[styles.card, compact && styles.compactCard]}>
      <h2 css={[styles.title, compact && styles.compactTitle]}>
        Title
      </h2>
    </div>
  );
}

This may look less magical.

That is the point.

A little less magic often means a lot more confidence later.

4. Reusable Components Need More Than Root Styling

Root-level styling is only the small case.

Reusable React components often have internal parts.

A button may have a root, an icon, and a label.

A card may have a root, header, title, content, and footer.

A caller might need to customize those parts without depending on DOM structure.

With normal class names, the public styling API often becomes accidental:

<button className="button">
  <span className="button__icon" />
  <span className="button__label">Save</span>
</button>

That works.

But now the caller knows your class names.

And if they use selectors, they may also start to know your markup.

Fluentic uses slots for this.

A slot is a named styling target that a component chooses to expose:

import { style } from '@fluentic/style';

const buttonStyles = {
  root: style.slot({
    display: 'inline-flex',
    alignItems: 'center',
    gap: 8,
    border: 0,
    borderRadius: 8,
    padding: '8px 12px',
  }),

  icon: style.slot({
    display: 'inline-flex',
    width: 16,
    height: 16,
  }),

  label: style.slot({
    fontWeight: 650,
  }),
};

This says something important:

root, icon, and label are allowed styling targets.

The DOM can stay private.

The component decides what it exposes.

5. Selectors Should Exist, But They Should Not Become the Whole Model

I still want hover and focus styles to feel natural.

In Fluentic, a simple element style can use fluent selector/state chains:

const button = style({
  backgroundColor: 'white',
  border: '1px solid var(--color-border)',
}).hover({
  backgroundColor: 'var(--color-surface-hover)',
}).focusVisible({
  outline: '2px solid var(--color-focus)',
  outlineOffset: 2,
});

Hover and focus states belong naturally in CSS.

I do not want to manually wire every interaction state in JavaScript just to avoid selectors.

But I also do not want selectors to become the main way components talk to each other.

Selectors are useful.

Selectors are also where hidden relationships often begin.

So Fluentic should support selectors, but still encourage local, explicit style ownership.

6. Runtime Work Should Be Small

Modern React apps already have enough work to do at runtime.

Styling should not require unnecessary client-side computation when the result can be known at build time.

This matters even more with SSR and React Server Components.

So Fluentic needs extraction.

But again, extraction is the implementation requirement, not the whole product idea.

The product idea is the way styles are written and composed.

7. Debugging Should Lead Back to the Code

This does not happen every day, but when it happens, it is painful.

I have had simple style issues take much longer than they should because tracing the final rule back to the code was not clear enough. Sometimes the source map was not precise. Sometimes the class name pointed me to generated output, but not to the exact style code that produced it.

That kind of debugging makes me lose confidence quickly.

Atomic CSS has a real benefit: it can keep the final CSS output small. But it also means the browser often shows many generated class names in the HTML. That tradeoff is acceptable only if those class names can still be traced back to the style code that created them.

If the browser shows an atomic class name, I still need a way to answer:

which code created this rule?
which component owns it?
did this come from the base style, a variant, a scope, or an incoming override?
why did this style win?

Because styling bugs are often not about one declaration. They are about the path that declaration took into the UI.

So Fluentic is not only about producing CSS. It is also about making generated styles easier to trace back to the React code that created them.

8. App Themes Should Not Be an Afterthought

There are two things many apps do not need on day one, but often wish they had prepared for from the beginning: i18n and theming.

At first, it is easy to assume the app only needs one language, one brand, one density, and one visual mode.

Then later the app needs dark mode. Or a different brand theme. Or a denser admin layout. Or product-specific styling.

That is when theming becomes painful.

Not because dark mode is hard by itself, but because the codebase was not prepared for styles to change at the app level.

So Fluentic has to support theming without forcing every value to become a carefully named token from day one.

Named tokens are useful when the name matters, which is usually when a component exposes values that other code is expected to override intentionally:

const card = createTokens({
  surface: '#ffffff',
  text: '#111827',
  border: '#d8e3df',
});

const cardStyles = {
  root: style.slot({
    backgroundColor: card.surface,
    color: card.text,
    border: '1px solid',
    borderColor: card.border,
  }),
};

Now the component has a small theme surface.

Other code does not need to know its DOM structure. It only needs to know the values the component chose to expose.

But at the app level, naming every color or spacing value can become more effort than help.

Sometimes the value itself is the clearest thing to read, search, and maintain.

That is why Fluentic also has createValues(...):

const color = createValues([
  '#ffffff | Surface',
  '#111827 | Text',
  '#d8e3df | Border',
]);

The app can use those values directly:

const page = style({
  backgroundColor: color('#ffffff | Surface'),
  color: color('#111827 | Text'),
});

And createTheme(...) can provide different values at the app or subtree level:

const darkTheme = createTheme([
  color('#ffffff | Surface', '#111827'),
  color('#111827 | Text', '#ffffff'),
  color('#d8e3df | Border', '#374151'),
]);

function App() {
  return (
    <main css={[page, darkTheme]}>
      <Dashboard />
    </main>
  );
}

At the component level, those app values can be mapped into the component’s exposed tokens through style.scope(...) and passed to the component:

const dashboardCardTheme = style.scope([
  card.surface(color('#ffffff | Surface')),
  card.text(color('#111827 | Text')),
  card.border(color('#d8e3df | Border')),
]);

<Card theme={dashboardCardTheme} />

The app theme still controls what those app values become. The component theme only says how this component should connect to those values.

The goal is not to force every app to define many themes from day one.

The goal is to make themeability available from the beginning, so dark mode and app-level styling do not become a retrofit later.

What Fluentic Is Trying To Be

Fluentic is my attempt to bring a React Native-inspired styling mental model to React web apps.

The goal is not to hide CSS.

The web is still the web.

You still need to understand layout, cascade, inheritance, media queries, pseudo states, and browser behavior.

Fluentic is not trying to make CSS disappear.

It is trying to make component styling feel more explicit, composable, and predictable.

The smallest version looks like this:

import { style, type StyleProp } from '@fluentic/style';

const styles = {
  button: style({
    height: 36,
    paddingInline: 12,
    borderRadius: 6,
    border: '1px solid #d1d5db',
    backgroundColor: '#ffffff',
  }).hover({
    backgroundColor: '#f3f4f6',
  }),

  primary: style({
    borderColor: '#2563eb',
    backgroundColor: '#2563eb',
    color: '#ffffff',
  }),

  disabled: style({
    opacity: 0.5,
    pointerEvents: 'none',
  }),
};

type ToolbarButtonProps = React.ComponentProps<'button'> & {
  primary?: boolean;
  css?: StyleProp;
};

function ToolbarButton({
  primary,
  disabled,
  css,
  ...props
}: ToolbarButtonProps) {
  return (
    <button
      {...props}
      disabled={disabled}
      css={[
        styles.button,
        primary && styles.primary,
        disabled && styles.disabled,
        css,
      ]}
    />
  );
}

For reusable components, Fluentic can go further with tokens, slots, scopes, and combineStyle(...).

import {
  style,
  createTokens,
  combineStyle,
  bindScope,
  type StyleProp,
  type StyleTheme,
} from '@fluentic/style';

const button = createTokens({
  color: {
    surface: '#2563eb',
    surfaceHover: '#1d4ed8',
    text: '#ffffff',
    dangerSurface: '#dc2626',
  },
  space: {
    gap: 8,
    paddingInline: 12,
  },
});

const buttonStyles = {
  root: style.slot({
    display: 'inline-flex',
    alignItems: 'center',
    gap: button.space.gap,
    border: 0,
    borderRadius: 8,
    paddingBlock: 8,
    paddingInline: button.space.paddingInline,
    backgroundColor: button.color.surface,
    color: button.color.text,
  }).hover({
    backgroundColor: button.color.surfaceHover,
  }),

  icon: style.slot({
    display: 'inline-flex',
    width: 16,
    height: 16,
  }),

  label: style.slot({
    fontWeight: 650,
    lineHeight: 1,
  }),
};

type ButtonProps = {
  children: React.ReactNode;
  css?: StyleProp;
  icon?: React.ReactNode;
  theme?: StyleTheme;
};

function BaseButton(props: ButtonProps) {
  const css = combineStyle(
    buttonStyles,
    bindScope(buttonStyles.root, props.theme),
  );

  return (
    <button css={[css.root, props.css]}>
      {props.icon ? <span css={css.icon}>{props.icon}</span> : null}
      <span css={css.label}>{props.children}</span>
    </button>
  );
}

Then variants can target public slots and component tokens instead of reaching through DOM structure:

const dangerButton = style.scope([
  button.color.surface(button.color.dangerSurface),

  buttonStyles.label({
    fontWeight: 700,
  }),
]);

const compactButton = style.scope([
  buttonStyles.root({
    gap: 6,
    paddingBlock: 6,
    paddingInline: 10,
  }),

  buttonStyles.label({
    fontSize: 13,
  }),
]);

function Button({
  danger,
  compact,
  theme,
  ...props
}: ButtonProps & {
  danger?: boolean;
  compact?: boolean;
}) {
  return (
    <BaseButton
      {...props}
      theme={[
        danger && dangerButton,
        compact && compactButton,
        theme,
      ]}
    />
  );
}

At the app level, values can stay readable while still being themeable.

import { createTheme, createValues, style } from '@fluentic/style';

const color = createValues([
  '#2563eb | Accent',
  '#1d4ed8 | AccentHover',
  '#ffffff | AccentText',
]);

const darkTheme = createTheme([
  color('#2563eb | Accent', '#60a5fa'),
  color('#1d4ed8 | AccentHover', '#93c5fd'),
  color('#ffffff | AccentText', '#0f172a'),
]);

Then the app can map those values into the component’s exposed tokens through a component theme:

const appButtonTheme = style.scope([
  button.color.surface(color('#2563eb | Accent')),
  button.color.surfaceHover(color('#1d4ed8 | AccentHover')),
  button.color.text(color('#ffffff | AccentText')),
]);

function App() {
  return (
    <main css={darkTheme}>
      <Button theme={appButtonTheme}>
        Save
      </Button>
    </main>
  );
}

The app theme decides what the app values become.

The component theme decides how this button connects to those values.

The component itself stays explicit about the parts and tokens it exposes.

The important part is not only the exact syntax.

The important part is the styling approach:

styles are defined as values
styles are composed explicitly
conditional styles are visible
component parts can be named with slots
variants can target slots without depending on DOM structure
app and component themes can be prepared early without becoming a separate styling system
selectors are available, but they are not the whole styling model
CSS is extracted for production builds
debugging should lead back to the React code, not stop at a generated class name

That is the balance I want.

React Native simplicity.

CSS power.

Modern React output.

A styling system where the everyday path stays simple, explicit when the component grows and prepared for the app-level concerns that usually arrive later.

Why Not Just Use Existing Tools?

This is a fair question.

There are many good styling tools now.

Some are utility-first.
Some are CSS-in-TypeScript.
Some are zero-runtime.
Some are compiler-first.
Some are design-system focused.
Some are close to CSS Modules with better ergonomics.

I am not building Fluentic because I think all of them are bad.

I am building it because I want a very specific feel.

The feel of React Native style composition, adapted to React web.

The thing I miss is not only extraction, type safety, or colocated styles.

It is the simple confidence of this line:

style={[base, variant, state, props.style]}

That mental model has been living rent-free in my head for years.

When I came back to React web, I wanted that feeling again.

But I also wanted hover, focus, media queries, selectors, SSR, extraction, component slots, and CSS output.

So Fluentic is my attempt to connect those worlds.

What I Am Trying To Avoid

Fluentic is also shaped by the things I want to avoid from my own past web code.

I want to avoid class names becoming a private styling API between parent and child components.

I want to avoid parent styles reaching too deeply into child structure.

I want to avoid selectors that make markup hard to change.

I want to avoid styling systems where I cannot easily answer “which style wins?”

I want to avoid too much runtime styling work.

I want to avoid cleverness that feels good today and suspicious six months later.

That last one is important.

A lot of styling decisions feel great when writing them.

The real test is how they feel when changing them later.

Fluentic Is Still Early

Fluentic is still early.

I am still exploring the API, constraints, compiler behavior, and the right balance between CSS power and React Native-like explicitness.

But the direction is clear:

React styling should feel more like composing values, and less like maintaining invisible relationships between class names and DOM structure.

That is the idea I want to test.

Not whether CSS can do everything. It can.

Not whether extraction is useful. It is.

The question is:

Can styling for component-heavy React apps feel predictable again?

Can we keep the parts of CSS that make the web powerful, while making everyday component styling feel closer to the React Native model?

That is what I am building with Fluentic.

You can check out Fluentic here:

GitHub: https://github.com/fluentic-dev/style
Docs: https://fluenticstack.com/style

If this problem feels familiar, especially if you have worked on both React web and React Native apps, I’d love to hear what you think.

Which parts of React styling become harder to change over time?

Which parts of React Native styling do you wish existed on React web?

And what component-styling cases should Fluentic cover next?

That feedback would be much more useful than stars alone, though I will not pretend stars hurt.

Beyond CSS-in-JS: From Element Styles To Component Themes

Wed, 26 Aug 2026 04:30:40 +0000

I started Fluentic Style with a small idea:

I wanted React Native-style composition in React web.

<View style={[base, active && activeStyle, props.style]} />

That kind of style composition always felt practical to me.

You have a base style.
You add another style when some state is active.
You still let styles come from props.

So the first Fluentic idea looked like this:

<div css={[base, active && selected, props.css]} />

That was the starting point.

I wrote about it here:

Bringing React Native Style Composition to React

But the more Fluentic evolved, the clearer it became that the real problem was never just CSS-in-JS or build-time extraction.

What felt missing was a better pattern for component-level styling, and for theming that can move from app-wide defaults down to a specific component.

The bigger question became:

Can a styling system cover the everyday path from styling one element, to styling reusable components, to component themes, to app-wide themes, while still keeping debugging and production extraction usable?

That is the version of Fluentic I am building now.

Not just another CSS-in-JS syntax.

More like an attempt to connect the parts of styling that often feel split apart.

The Problem Is Not Only Putting CSS In JS

CSS-in-JS gave frontend developers something useful.

It made styles feel closer to components.
It made dynamic styling easier.
It made local styling easier.
It made React UI feel less split between a component file and a separate stylesheet.

But daily app styling is bigger than:

How do I put CSS on this DOM element?

That is one layer.

A real app usually moves through several layers:

element style
component style
component variant
component theme
app-wide theme
production output
debugging

Many styling approaches are good at one or two of those.

Some are great for quick element styles.
Some are great for app-wide tokens.
Some are great for utility classes.
Some are great for local CSS files.
Some are great for runtime dynamic values.
Some are great for extracted CSS.

But in real app work, I kept wanting those layers to connect better.

That became the bigger Fluentic goal:

style composition from elements, to components, to component themes, to app-wide themes

without turning each layer into a separate styling system.

Start With One Element

The smallest case should stay small.

If I only need to style one element, I should be able to write one style and attach it.

import { style } from '@fluentic/style';

const saveButton = style({
  borderRadius: 8,
  padding: '8px 12px',
});

<button css={saveButton}>Save changes</button>;

If that element needs hover, media, or state styles, it should still stay attached to the same style idea:

const saveButton = style({
  borderRadius: 8,
  padding: '8px 12px',
}).hover({
  backgroundColor: '#f3f4f6',
});

<button css={saveButton}>Save changes</button>;

For teams that like utility-class authoring, Fluentic can also work closer to that style:

const saveButton = cx(
  'inline-flex',
  'items-center',
  'rounded-md',
  'px-3',
  'py-2',
).hover('bg-slate-100');

<button css={saveButton}>Save changes</button>;

So Fluentic does not start by forcing every use case into components, themes, or design-system structure.

Sometimes you just need to style an element.

That should be easy.

Then The Element Becomes A Component

The next problem appears when that styled element becomes reusable.

A button is not always just one DOM node.

It can have parts:

function Button(props) {
  return (
    <button>
      <span>{props.icon}</span>
      <span>{props.children}</span>
    </button>
  );
}

Now the styling question changes.

There is a root.
There is an icon.
There is a label.

Maybe a loading indicator.
Maybe an action area.
Maybe a wrapper around some third-party element.

Frontend teams already think in these names:

root, icon, label, content, trigger, item, control, thumb, track, portal

The old HTML/CSS way would usually name those parts with classes:

.button { ... }
.button__icon { ... }
.button__label { ... }
.button[data-danger] .button__label { ... }

That is understandable.

But in a component system, the component owns the inside.

So when the outside needs to style those parts, React APIs often grow shapes like this:

<Button
  className="danger-button"
  iconClassName="danger-icon"
  labelClassName="danger-label"
>

or:

<Button
  classes={{
    root: 'danger-button',
    icon: 'danger-icon',
    label: 'danger-label',
  }}
>

or:

<Button
  styles={{
    label: { fontWeight: 700 },
  }}
>

These are practical. I have written APIs like this many times.

But the repeated shape is clear:

the component has parts, and outside code needs a supported way to style those parts

Fluentic’s answer is style.slot(...).

A slot is a normal style for the component itself, but it also gives that component part an identity that outside styles can target later.

const buttonStyles = {
  root: style.slot({
    borderRadius: 8,
    padding: '8px 12px',
  }),

  icon: style({
    flex: '0 0 auto',
  }),

  label: style.slot({
    fontWeight: 700,
  }),
};

Notice that not every internal element needs to be a slot.

icon can stay private with style(...).

root and label become public styling targets with style.slot(...).

That is the first important split:

use style(...) for ordinary element styles
use style.slot(...) when a component part should be styleable from outside

Component Themes Are Not The Same As App Themes

Once a component exposes slots, outside code needs a way to provide styles for those slots.

That is where style.scope(...) comes in.

A scope groups changes for public component parts:

const dangerButton = style.scope([
  buttonStyles.root({
    backgroundColor: '#dc2626',
  }),

  buttonStyles.label({
    color: 'white',
  }),
]);

The component receives that as a theme-like input:

type ButtonProps = {
  children: React.ReactNode;
  icon?: React.ReactNode;
  theme?: StyleTheme;
};

Then the component prepares the styles it will render:

function Button(props: ButtonProps) {
  const css = combineStyle(
    buttonStyles,
    bindScope(buttonStyles.root, props.theme),
  );

  return (
    <button css={css.root}>
      {props.icon ? <span css={css.icon}>{props.icon}</span> : null}
      <span css={css.label}>{props.children}</span>
    </button>
  );
}

This is different from passing a raw class name into each part.

The outside says what it wants to change:

<Button theme={dangerButton}>Delete</Button>

The component still decides where those styles attach.

That is why I think of scopes as component-facing themes.

They are not only global colors.

They can change slots, tokens, states, media rules, and multiple component parts together.

App-Wide Themes Need A Different Layer

App-wide theming is related, but it is not exactly the same problem.

Sometimes the app wants to define shared values:

const color = createTokens({
  surface: '#ffffff',
  text: '#111827',
  accent: '#2563eb',
  danger: '#dc2626',
});

A style can use those tokens:

const page = style({
  backgroundColor: color.surface,
  color: color.text,
});

Then an app theme can override those token values:

const darkTheme = createTheme([
  color.surface('#0f172a'),
  color.text('#f8fafc'),
]);

That is app-facing theming.

It answers:

What should surface, text, or accent mean in this part of the app?

A component theme answers a different question:

How should this component’s public parts or component-specific tokens change?

Fluentic supports both.

Use createTheme(...) when the theme only changes token values.

Use style.scope(...) when the theme needs to affect component slots, component tokens, states, media conditions, or multiple parts together.

This distinction matters because app-wide themes and component themes often live in different realms.

A design system may define app tokens.

A component library may expose component tokens and slots.

An app may need to map app values into component values.

For example:

const button = createTokens({
  color: {
    surface: '#2563eb',
    surfaceHover: '#1d4ed8',
    text: '#ffffff',
  },
});

const appButtonTheme = style.scope([
  button.color.surface(color.accent),
  button.color.surfaceHover(color.accent),
  button.color.text('#ffffff'),
]);

The app theme controls what color.accent means.

The component theme says how the button should use that app value.

That is the kind of bridge I wanted Fluentic to support.

Not app theming over here, component theming over there, and manual glue in between.

One styling path that can connect them.

Variants Become Scopes Too

Component variants are usually where styling logic starts getting busy.

A variant like this looks simple:

<Button size="sm" tone="danger" />

But internally it may affect several parts:

root padding
label font size
icon size
background color
hover color
disabled color

Without a shared styling shape, that often becomes a matrix of class names or conditionals.

In Fluentic, a variant can be a scope:

const compactButton = style.scope([
  buttonStyles.root({
    gap: 6,
    paddingBlock: 6,
    paddingInline: 10,
  }),

  buttonStyles.label({
    fontSize: 13,
  }),
]);

const dangerButton = style.scope([
  buttonStyles.root({
    backgroundColor: '#dc2626',
  }),

  buttonStyles.label({
    color: 'white',
  }),
]);

And because scopes are values, they compose:

<Button
  theme={[
    compact && compactButton,
    danger && dangerButton,
    props.theme,
  ]}
>
  Delete
</Button>

This is where Fluentic starts feeling bigger than element-level CSS-in-JS.

The same composition idea can move from:

<div css={[base, active && selected]} />

to:

<Button theme={[compact && compactButton, danger && dangerButton]} />

The shape stays familiar.

The layer changes.

Debugging Still Has To Follow The Whole Path

A nice authoring API is not enough if generated CSS becomes a dead end.

That is one of the places where I think styling tools often ask developers to accept too much friction.

You write nice code.

DevTools shows generated class names or injected CSS.

Then you have to guess where the rule came from.

Fluentic emits atomic CSS, but not only for output size or dedupe.

Atomic CSS also gives a useful debugging unit:

one generated rule can map back to one styling decision

For example:

style({
  backgroundColor: '#2563eb',
}).hover({
  backgroundColor: '#1d4ed8',
});

A generated hover background-color rule should be able to point back to the backgroundColor inside .hover(...).

For slots and scopes, the trace should stay meaningful too.

If this wins:

const dangerButton = style.scope([
  buttonStyles.label({
    color: 'white',
  }),
]);

the generated color rule should be able to lead back to the scoped label override.

That is why Fluentic keeps debug metadata and sourcemap information in development.

The debug story should follow the same path:

style → slot → scope → generated CSS → source trace

If component styling is part of the model, debugging component styling has to be part of the model too.

Production Extraction Should Fit The Same Model

The other big requirement is production.

A runtime-only CSS-in-JS library can be convenient, especially in small apps.

But production apps need more.

They need extracted CSS.
They need SSR and framework integrations.
They need predictable output.
They need the runtime to do less work when the build can prepare things ahead of time.

Fluentic’s compiler and bundler plugins extract the static style declarations from patterns like:

style(...)
style.slot(...)
style.scope(...)

and emit extracted atomic CSS plus prepared JavaScript output.

But real apps still have runtime-known choices:

<Button
  theme={[
    compact && compactButton,
    danger && dangerButton,
    props.theme,
  ]}
>
  Delete
</Button>

The build can prepare CSS from the style declarations.

The runtime still resolves which themes, scopes, token values, and prop-driven choices apply during render.

That is important.

I do not want a system where extracted CSS only works for the boring cases, and the moment a component becomes dynamic you move to a different styling model.

The goal is one authoring model:

build extracts what can be prepared
runtime resolves what the app decides while rendering

Syntax Should Be Flexible, But The Path Should Stay Connected

CSS-in-JS discussions often become syntax discussions.

Objects.
Tagged templates.
Utility classes.
Inline styles.
Generated classes.
CSS files.

I understand why. Syntax is what developers touch every day.

Fluentic started object-first:

const card = style({
  padding: 16,
  borderRadius: 12,
});

But Fluentic now also supports Tailwind-like class-name authoring:

const card = cx('rounded-xl', 'bg-white', 'p-4');

It also supports Tailwind-style object presets and custom transforms.

A design system can create its own vocabulary:

const panel = ui({
  row: true,
  center: true,
  gapX: 12,
});

The point is not that every team should write styles the same way.

The point is that different syntaxes can still feed the same Fluentic path.

Once they become Fluentic styles, they can still participate in:

element styling
slots
scopes
token themes
component themes
atomic CSS output
production extraction
sourcemaps
debug metadata

That is the practical reason custom transforms matter.

They are not only a syntax trick.

They let a team adapt the authoring vocabulary without leaving the rest of the styling system behind.

Frameworks Need Bridges, Not A New Styling Model

Fluentic started with React.

React is still the main focus.

But modern frontend is not only one JSX/runtime story.

Next.js App Router brings server components, server/client rendering, HMR, streaming concerns, development CSS, sourcemaps, and production extraction.

SolidJS has its own compiler-centered JSX path.

Preact has a different prop shape.

So Fluentic is moving toward a stable styling core with framework-specific bridges.

React can use Fluentic’s JSX runtime, or it can use a cssProp compiler transform.

Next.js gets a deeper integration for App Router, RSC development styling, debug CSS, sourcemaps, and production extraction.

SolidJS client-side support uses a css prop transform before Solid’s compiler.

The goal is:

keep the style path stable, adapt the framework handoff

That keeps Fluentic from being only a React runtime library.

The style ideas can stay the same while the JSX integration changes per framework.

What Fluentic Currently Has

Fluentic Style is still new and currently in beta.

But it already covers much more than my first small idea.

Authoring:

style(...) object styles
cx(...) class-name authoring
Tailwind-like class-name preset
Tailwind-style object preset
custom style functions
custom transforms

Element and component composition:

css prop arrays
conditional styles
style.slot(...) for public component parts
style.scope(...) for component themes and slot overrides
combineStyle(...)
bindScope(...)

Theming:

createToken(...)
createTokens(...)
createTheme(...) for token-only themes
style.scope(...) for component themes, slot overrides, and token mapping

Build and debug:

atomic CSS in development and production
production CSS extraction
prepared JavaScript output
debug metadata
sourcemap support
development utilities for inspecting generated styles

Frameworks:

React
Next.js App Router
SolidJS client-side support
Preact-oriented adapter path

That is far beyond the original idea.

The first goal was:

bring React Native-style composition to React web

The current goal is closer to:

make everyday styling composition work from element styles to component styles to component themes to app-wide themes, with debugging and production output still part of the same story

That is the part that keeps me building it.

Closing

I do not think existing CSS-in-JS approaches are wrong.

I do not think CSS is broken.

A lot of styling approaches are useful, and I still use many familiar patterns.

Fluentic is my attempt to connect the parts that I kept seeing split apart:

quick element styling
component styling
component theming
app-wide theming
style composition
generated CSS debugging
production extraction
framework integration
flexible authoring syntax

It is still beta, and I expect the API to keep improving.

But the direction is clear now.

Fluentic is no longer only my attempt to bring React Native-style arrays to React web.

It is an attempt to make styling feel more complete for component-based apps: from one element, to a reusable component, to local component themes, to app-wide themes, while still caring about CSS output, DevTools, production builds, and framework realities.

Useful links:

Common CSS Mistakes Beginners Make (and How to Fix Them)

Tue, 25 Aug 2026 05:00:00 +0000

Introduction

Every one of these mistakes cost me real debugging time when I was learning. Not because CSS is inherently confusing — but because nobody explained why these things happen, just that they do. Understanding the "why" is what actually prevents you from repeating them.

1. The Box Model Confusion

By default, width and height don't include padding and border — meaning a box you set to 300px wide can visually render wider once padding is added.

.box {
  width: 300px;
  padding: 20px;
  border: 2px solid black;
  /* Actual rendered width: 300 + 20+20 + 2+2 = 344px */
}

The fix: set this once, globally, at the start of every project:

* {
  box-sizing: border-box;
}

Now width: 300px means the element is always 300px total, padding and border included. This single line prevents a huge number of layout bugs.

2. Margin Collapse

Two vertical margins between sibling elements don't add together — they collapse into the larger of the two.

.first { margin-bottom: 20px; }
.second { margin-top: 30px; }
/* Actual gap between them: 30px, NOT 50px */

This confuses beginners constantly because it seems inconsistent — but it's expected browser behavior for vertical margins specifically (doesn't apply to horizontal margins, or to Flexbox/Grid gap).

The fix: use gap on a flex or grid container instead of relying on margins between children — it doesn't collapse and is far more predictable.

3. Overusing `!important`

.button {
  background: blue !important;
}

!important overrides normal CSS specificity rules — which feels like a quick fix, but it creates a mess later. Once you have several !important rules fighting each other, debugging becomes genuinely painful because normal specificity logic no longer applies.

The fix: understand specificity instead. IDs beat classes, classes beat elements. If you're reaching for !important, it usually means a more specific selector (or restructuring your CSS) would solve it more cleanly.

4. Not Understanding `position: absolute`

.tooltip {
  position: absolute;
  top: 0;
  left: 0;
}

Beginners often expect this to position relative to the whole page. In reality, position: absolute positions relative to the nearest ancestor with position: relative (or absolute/fixed) set. If no ancestor has that, it positions relative to the whole document — which is rarely what you actually want.

The fix: always set position: relative on the parent container first:

.card {
  position: relative;
}
.badge {
  position: absolute;
  top: 8px;
  right: 8px;
}

5. Fighting Flexbox/Grid Instead of Reading the Docs

A very common beginner pattern: not getting the exact spacing/alignment you want, then adding random margins and padding until it "looks right" by trial and error.

The fix: learn justify-content, align-items, and gap properly (covered fully in Article 2). Once you understand these three properties, most alignment problems have a direct, one-line solution instead of a pile of guessed margins.

6. Not Resetting Default Browser Styles

Browsers apply their own default styles to elements (<ul> gets bullet points and padding, <h1> gets specific margins, etc.), and these defaults are inconsistent across browsers.

The fix: use a simple CSS reset at the top of your stylesheet, or use Tailwind CSS, which includes a solid reset (Preflight) automatically.

7. Specificity Wars from Nested Selectors

.card .header .title span {
  color: red;
}

Deeply nested selectors like this become extremely hard to override later, since they carry heavy specificity.

The fix: keep selectors as flat as possible. A single well-named class (.card-title) is easier to maintain than four levels of nesting.

Final Thoughts

Almost every CSS mistake on this list comes down to one thing: not understanding why the browser is doing what it's doing, and reaching for a quick patch instead. Once you understand the box model, specificity, and positioning contexts properly, CSS debugging goes from guesswork to genuinely logical problem-solving.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

Understanding exec() in FSCSS — Two Completely Different Jobs

Sat, 22 Aug 2026 22:45:11 +0000

Understanding `exec()` in FSCSS

In FSCSS, exec() serves two completely different purposes depending on where you write it:

Inside your stylesheet: as a utility / debugging function
In JavaScript / HTML: to load and compile the styles

Let’s break both down clearly.

1. Inside Stylesheets: Debugging & Logging

When used inside an @event block or after processing an array, exec() lets you run small JavaScript helpers directly from your CSS.
Its main job here is printing debug information to the browser console so you can check if your logic is working.

Console Logging

You can pass flags like _log, _warn, _info, or _error:

@event scaleSize(e) {
  if e >= 8 {
    return| num(8*2)em exec(_log, "Scaling to 16em for optimal readability")
  }
}

Checking Array Data

You can also inspect the current values inside an FSCSS array:

@arr fruits[ apple, orange, banana ]

/* Prints: apple orange banana straight to your browser console */
exec(_log, "@arr.fruits")

This is extremely useful while building complex logic with @event, @arr, or calculated values.

2. In JavaScript & Imports: Compilation Engine

Outside the stylesheet, exec is the core engine that compiles and runs FSCSS source code.

CDN Initialization (HTML)

The compiler file loaded via CDN is named exec.min.js:

<script src="https://cdn.jsdelivr.net/npm/fscss@1.1.25/exec.min.js" defer></script>

<style>
  /* Tells the engine to execute the initialization for a module */
  @import(exec(_init circle-progress))
</style>

Programmatic JavaScript Usage

You can also import and control the compiler directly from JavaScript:

import { exec } from "https://cdn.jsdelivr.net/npm/fscss@1.1.25/e/xfscss.min.js";

new exec({
  type: "URL",
  content: "styles.fscss",
  onSuccess: "Styles loaded successfully!",
  onError: "Oops, style compilation failed!"
});

This gives you full control over loading, success messages, and error handling.

Quick Summary

Location	Purpose	Common Use Case
Inside `.fscss`	Debugging & console logging	Check `@event` logic or array values
In HTML / JavaScript	Compile and run FSCSS	Load styles or initialize modules

Two different jobs. Same name.
Once you know the context, exec() becomes much clearer.

Useful links

Docs → fscss.devtem.org
vscode extention FSCSS Support
npm → npmjs.com/package/fscss

pattern() in FSCSS 1.1.25

Tue, 18 Aug 2026 12:18:46 +0000

FSCSS v1.1.25 ships a new core method: pattern().

You describe what you want in plain language, and FSCSS matches the closest pattern at compile time.

pattern(0.5: "Hello World Card", `
  border-radius: 12px;
  padding: 24px;
  background: linear-gradient(135deg, #667eea, #764ba2);
  color: #fff;
  box-shadow: 0 8px 24px rgba(0,0,0,0.25);
`)

.card {
  hello world card
}

Compiles to:

.card {
  border-radius: 12px;
  padding: 24px;
  background: linear-gradient(135deg, #667eea, #764ba2);
  color: #fff;
  box-shadow: 0 8px 24px rgba(0,0,0,0.25);
}

Notice .card doesn't call anything — it just contains a phrase close enough to "Hello World card" to trigger the match.

Why this exists

@define is precise but rigid. You call it by exact name, with exact arguments. That's great for a library you built yourself, but it breaks down in a few real situations:

Design handoffs. A designer or junior dev writes dark card with rounded corners inside a rule instead of hunting through your define library for the right call signature.
AI-generated markup. Tools that generate FSCSS from natural-language prompts can emit descriptive phrases instead of needing to know your exact mixin names.
Fast prototyping. You don't always remember what you named something six months ago. pattern() lets close-enough phrasing still resolve correctly.

pattern() doesn't replace other variable methods — it sits next to it, for cases where flexibility matters more than precision.

The syntax

pattern(threshold: "description", `
  css to inject
`)

threshold — a number from 0 to 1. The minimum similarity score a phrase must reach to trigger this pattern. Omit it and it defaults to 1 (near-exact match only).
description — the plain-language phrase you're matching against.
css — what gets injected when a phrase matches. Use backticks so the CSS can freely contain single or double quotes.

Threshold uses a colon, deliberately — 0.5: reads as a labeled parameter, distinct from a plain comma-separated argument. It's there so the number's purpose is visually obvious to anyone reading your stylesheet.

How matching works

Every phrase in your code gets compared against every pattern description using similarity scoring (Dice coefficient, if you're curious — it compares word overlap between the phrase and the description). The pattern with the highest score that also clears its own threshold wins.

That means:

pattern(0.8: "dark background and light color", `
  background: #212121;
  color: #ffffff;
`)

.chip {
  style dark background and light color
}

.tooltip {
  dark background light color
}

Both .chip and .tooltip resolve to the same CSS, even though neither phrase matches the description word-for-word. That's the point — you're not looking up a name, you're describing an outcome.

Tuning the threshold

High threshold (0.8–1) → strict. Good for short, generic descriptions where you don't want accidental matches ("button" alone would be too easy to trigger by accident).
Low threshold (0.4–0.6) → forgiving. Good for longer, more specific descriptions where a few words might vary but the intent is clearly the same.

If two patterns could plausibly match the same phrase, the highest-scoring one wins — so keep descriptions distinct from each other, especially at lower thresholds.

Property patterns vs. block patterns

Same split as @define:

Property patterns inject a group of declarations inside a rule:

pattern(0.6: "rounded primary button", `
  border: none;
  border-radius: 8px;
  padding: 10px 20px;
  background: #ffffff;
  color: #764ba2;
  font-weight: 600;
  cursor: pointer;
`)

.btn {
  rounded primary button
}

Block patterns inject full structures — keyframes, media queries, whole at-rules — and can stand alone outside any selector:

pattern(0.7: "Animated keyframe for spin", `
  @keyframes spin {
    0% { transform: rotate(0); }
    100% { transform: rotate(360deg); }
  }
`)

An Animated keyframe for spin

Content injection example

Because the CSS argument is just a string, pattern() isn't limited to properties — it can inject anything valid at that point in your stylesheet, including pseudo-element content:

pattern(0.9: "hello world heading", `h1:before{content: 'Hello World';}`)

  hello world heading

What's shipped in v1.1.25

CDN
API
CLI
VSCode Extention

Try it

pattern() is available on v1.1.25

Docs: fscss.devtem.org/pattern

CSS Animations for Beginners: Transitions, Keyframes & Transforms

Tue, 11 Aug 2026 05:00:00 +0000

Introduction

CSS animations were the thing that made me actually enjoy frontend development. Building a static layout is satisfying, but the moment something moves smoothly on hover or fades in on load, a project suddenly feels alive.

The good news: you only need three concepts to cover almost every animation you'll want to build — transitions, transforms, and keyframes. Let's go through all three.

1. Transitions — Smoothing Out State Changes

A transition smooths out a property change between two states (like normal and hover).

.button {
  background-color: #3b82f6;
  transition: background-color 0.3s ease;
}

.button:hover {
  background-color: #2563eb;
}

Without transition, the color change would be instant. With it, the color smoothly shifts over 0.3 seconds.

Syntax breakdown: transition: [property] [duration] [easing];

In Tailwind:

<button class="bg-blue-500 hover:bg-blue-600 transition duration-300">

2. Transform — Moving, Scaling, Rotating

transform changes an element's position, size, or rotation without affecting the layout of surrounding elements.

.card {
  transition: transform 0.3s ease;
}

.card:hover {
  transform: translateY(-8px) scale(1.02);
}

This lifts a card slightly and grows it a tiny bit on hover — a very common effect on portfolio sites and product cards.

Common transform values:

translateY(-8px) — moves up
scale(1.05) — grows by 5%
rotate(5deg) — rotates slightly
translateX(20px) — moves right

In Tailwind:

<div class="transition hover:-translate-y-2 hover:scale-105">

3. Keyframes — Multi-Step Animations

Transitions handle two states. @keyframes handles animations with multiple steps, or ones that run automatically without needing a trigger like :hover.

@keyframes fadeInUp {
  from {
    opacity: 0;
    transform: translateY(20px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

.hero-title {
  animation: fadeInUp 0.8s ease-out;
}

This makes an element fade in while sliding up slightly — a very common "page load" effect.

You can also define multiple steps with percentages:

@keyframes pulse {
  0% { transform: scale(1); }
  50% { transform: scale(1.1); }
  100% { transform: scale(1); }
}

.notification-dot {
  animation: pulse 2s infinite;
}

This creates a continuous pulsing effect, useful for notification badges or "live" indicators.

Putting It Together: A Real Example

Here's a button with a hover lift, a smooth color transition, and a subtle entrance animation on page load:

@keyframes fadeIn {
  from { opacity: 0; }
  to { opacity: 1; }
}

.cta-button {
  background-color: #3b82f6;
  transition: all 0.3s ease;
  animation: fadeIn 0.6s ease-in;
}

.cta-button:hover {
  background-color: #2563eb;
  transform: translateY(-4px);
  box-shadow: 0 10px 20px rgba(59, 130, 246, 0.3);
}

This is genuinely how most polished-feeling buttons on real websites are built — nothing exotic, just transitions and transforms combined thoughtfully.

Common Beginner Mistakes

Animating too many properties at once. Subtlety wins — one or two properties changing smoothly looks more professional than five things moving at once.
Using all in transitions carelessly. transition: all 0.3s works, but is slightly less performant than specifying exact properties like transition: transform 0.3s, background-color 0.3s.
Animating width/height/top/left instead of transform. These properties trigger layout recalculation and can feel janky. transform and opacity are GPU-accelerated and much smoother.
Overusing infinite animations. A pulsing badge is fine. A constantly bouncing hero heading gets annoying fast — use continuous animation sparingly.

Final Thoughts

You don't need a JavaScript animation library for most of what makes a website feel polished — smooth hovers, subtle lifts, and clean entrance animations are all achievable with plain CSS. Start by adding a transition to every hover state in your next project and see how much more "finished" it instantly feels.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

I built pure CSS 3D dice cube module: FSCSS

Fri, 07 Aug 2026 22:17:10 +0000

cube.fscss is a lightweight, pure CSS 3D cube system built on FSCSS. It renders a spinnable 6-face cube using nothing but perspective, transform-style: preserve-3d, and translateZ/rotateX/rotateY — no JavaScript, no 3D library, no canvas.

Here's example whole thing rendered live, nothing but <div>s and CSS:

<script src="https://cdn.jsdelivr.net/npm/fscss@1.1.24/exec.min.js" defer></script>

<style>
@import((*) from cube)

@cube-root()
@cube-wrapper(.my-cube)
@cube-face(.my-cube div)
@cube-face-front(.my-cube .f1)
@cube-face-back(.my-cube .f2)
@cube-face-left(.my-cube .f3)
@cube-face-right(.my-cube .f4)
@cube-face-top(.my-cube .f5)
@cube-face-bottom(.my-cube .f6)
@cube-micro-dice(.my-cube .cube)

.my-cube {
  @cube-size(80px)
  transform: rotateY(50deg) rotateX(30deg);
  animation: spin 5s linear infinite;
}

@keyframes spin {
  0%   { transform: rotateX(20deg) rotateY(40deg); }
  100% { transform: rotateX(380deg) rotateY(400deg); }
}
</style>

<div class="my-cube">
  <div class="cube f1 dice-1"></div>
  <div class="cube f2 dice-2"></div>
  <div class="cube f3 dice-3"></div>
  <div class="cube f4 dice-4"></div>
  <div class="cube f5 dice-5"></div>
  <div class="cube f6 dice-6"></div>
</div>

No dice PNGs. No SVG paths. No canvas draw calls. Every pip is a radial-gradient.

Why build this

Already had a chart/dashboard module (st-core.fscss) built on clip-path polygons — no JS charting library, just CSS custom properties driving the shape. I wanted to see how far that "CSS does the visual math" philosophy could stretch into actual 3D space. A cube felt like the right next test: real perspective, real preserve-3d, real face geometry — not a flat illusion.

How the geometry works

A cube is 6 absolutely-positioned faces sharing one parent set to transform-style: preserve-3d. Each face gets pushed out from the center by half the cube's edge length, then rotated to face outward:

front  → translateZ(half)
back   → rotateY(180deg) translateZ(half)
top    → rotateX(90deg)  translateZ(half)
bottom → rotateX(-90deg) translateZ(half)
right  → rotateY(90deg)  translateZ(half)
left   → rotateY(-90deg) translateZ(half)

The entire cube's dimensions live in two CSS variables: --cube-size and --cube-half (always size ÷ 2). Resize the whole thing with one call:

.my-cube {
  @cube-size(150px)
}

Faces, offsets, and dice dot size all scale together — no manually recalculating six translateZ values by hand.

Dice pips, no font glyphs

I originally reached for Unicode dice characters (⚀⚁⚂⚃⚄⚅) for the pips, but font rendering for those glyphs is wildly inconsistent across platforms — some Android/Chrome stacks show them thin, outlined, or as tofu boxes. Stacked radial-gradients solved it instead:

.dice-3 {
  background-image:
    radial-gradient(circle var(--cube-dot-size) at 25% 25%, var(--cube-dot-color) 99%, transparent 100%),
    radial-gradient(circle var(--cube-dot-size) at 50% 50%, var(--cube-dot-color) 99%, transparent 100%),
    radial-gradient(circle var(--cube-dot-size) at 75% 75%, var(--cube-dot-color) 99%, transparent 100%);
}

Font-independent, crisp at any size, and the dot radius is itself a variable — so it scales automatically with @cube-size() instead of overflowing on a big cube or vanishing on a small one.

It's not just dice

Faces and face content are decoupled on purpose. The face mixins only handle position — what renders inside is a separate "micro" you apply on top. Right now there are eight:

cube-micro-fire — pulsing gradient-text fire
cube-micro-matrix — scrolling digital rain
cube-micro-neon — pulsing cyan/magenta glow border
cube-micro-float — subtle bounce, stacks with anything
cube-micro-glass — frosted backdrop-filter panel
cube-micro-holo — holographic shifting gradient text
cube-micro-glitch — RGB-split glitch shift
cube-micro-dice — the pips above

Mix and match per face on the same cube:

@cube-micro-fire(.my-cube .f1)
@cube-micro-matrix(.my-cube .f2)
@cube-micro-neon(.my-cube .f3)
@cube-micro-glass(.my-cube .f5)
@cube-micro-holo(.my-cube .f6)

Try it

CDN, drop-in:

<script src="https://cdn.jsdelivr.net/npm/fscss@1.1.24/exec.min.js" defer></script>
<style> 
  @import((*) from cube)
  /* your mixins here */
</style>

Or compile ahead of time with the CLI for a plain .css file, zero runtime:

npm install -g fscss
fscss style.fscss style.css

Full docs, token reference, and more examples: github.com/fscss-ttr/cube.fscss

If you build something with it — I'd love to see. And if you hit issue, open an issue, it's open-source.

help us star the repo so more dev can discover it. 🙏

Why I Replaced Tailwind CSS With Vanilla CSS

Thu, 06 Aug 2026 12:39:32 +0000

I removed Tailwind CSS from this site and rewrote every style by hand in vanilla CSS. The reason is short: modern CSS now does natively what I was pulling Tailwind in to get. Cascade layers, custom properties, nesting, and :has() all ship in every current browser, and Tailwind v4 is built on those exact primitives. Once the browser speaks the language directly, a build step that generates it for you reads as overhead rather than leverage. When I rebuilt this site in December 2025 I reached for Tailwind v4 on instinct. This month I took it back out.

TL;DR

The features I used Tailwind for (design tokens, nesting, scoping, a consistent scale) are now native CSS or handled by Astro's scoped styles.
Tailwind v4 is itself built on native cascade layers, custom properties, and color-mix(), with Lightning CSS doing the build. I was shipping an engine to generate CSS the browser already understands.
The migration dropped three Tailwind packages, moved global styles into native @layers, and put every component's styles in Astro's scoped <style> blocks.
The site stayed Baseline Widely available the whole way.

Why replace Tailwind at all?

Because the job Tailwind did for me is now built into the platform. When I list what I actually reached for it to solve, every item has a native answer today:

What I used Tailwind for	The vanilla replacement	Baseline Widely since
Style layering and predictable overrides	`@layer` cascade layers	Sept 2024
Design tokens and theming	Custom properties (`--x`)	long-standing
Nesting without a preprocessor	Native CSS nesting (`&`)	June 2026
Parent and state selectors	`:has()`	June 2026
Component-scoped responsive rules	Container queries and Astro scoped styles	Aug 2025

The dates are the point. CSS nesting and :has() only crossed into Baseline Widely availability around June 2026, roughly two months before I did this. Cascade layers got there in September 2024, color-mix() in November 2025, size container queries in August 2025. The Chrome team's CSS Wrapped 2025 counted 22 new CSS features landing in Chrome in a single year. The gap Tailwind was filling closed while I wasn't looking, and 2026 is the year it actually finished closing.

None of this makes Tailwind bad. It makes it optional for what I'm doing here: a single-author content site where nobody but me touches the CSS.

Tailwind v4 already runs on the CSS I switched to

The thing that tipped me over was reading how Tailwind v4 works under the hood. Its January 2025 rewrite is explicit that it is built on modern CSS. The announcement lists "native cascade layers," "registered custom properties," "color-mix()," and logical properties as the foundation. The earlier post introducing its Oxide engine is blunter about the plumbing: the engine is "up to 10x faster," and "the only thing the new engine depends on is Lightning CSS."

Read that back with a migration in mind. Tailwind v4 generates native cascade layers, sets custom properties, and runs the output through Lightning CSS for prefixing and minification. That is the same stack I now write directly. I was running an engine whose job was to emit CSS features my target browsers already implement. For an app with dozens of engineers and a shared design system, that engine buys you consistency and guardrails worth paying for. For this site, it was a generator sitting between me and CSS I could just write.

There is a small irony worth stating plainly. Tailwind v4 leans on registered custom properties (@property), which won't reach Baseline Widely availability until around January 2027, so Tailwind ships its own fallbacks for it. My hand-written CSS holds a stricter bar than the framework I removed.

What the migration actually looked like

The site is Astro, so it splits cleanly in two: global styles in src/styles, and per-component styles in each .astro file's scoped <style> block. I rewrote both.

Cascade layers replace the Tailwind import

The old entry point started with Tailwind's import, its typography plugin, and a @custom-variant line for every palette so theme selectors would compile:

@import "tailwindcss";
@plugin "@tailwindcss/typography";

@custom-variant tokyo-night (&:where([data-theme="tokyo-night"]));
@custom-variant dracula (&:where([data-theme="dracula"]));
/* ...thirteen more palettes... */
@custom-variant dark (&:where([data-mode="dark"], [data-mode="dark"] *));

Fifteen @custom-variant declarations, one per palette, plus one for dark mode, all to teach the framework about selectors the browser already understands. The replacement is one line of real CSS that declares the cascade order, then a plain file per layer:

@layer reset, tokens, base, primitives, prose, utilities;

Ordering the layers by hand turned out to be the feature I most underrated in Tailwind. Layers win by declaration order regardless of selector specificity, so the reset can be dead simple, tokens can sit under everything, and utilities win last without a single !important. I get the exact override behavior Tailwind gave me, spelled out in one readable statement.

Design tokens are just custom properties

Theming didn't really change, which is the tell. Under Tailwind the palettes were already CSS variables swapped by a data-theme attribute; the framework just wrapped them in @theme and @custom-variant. Stripping that wrapper left plain rules:

:root,
[data-theme="catppuccin-mocha"] {
  --bg: #11111b;
  --ink: #cdd6f4;
  --accent: #89b4fa;
  /* ...the rest of the reduced token set... */
}

Sixteen of those blocks, one per theme, in a tokens layer. The switcher sets data-theme on <html>, the variables cascade in, and syntax highlighting tracks them through more variables. No config object, no plugin API, just the custom properties that were doing the work all along.

Components: from class lists to scoped styles

This is where the day-to-day difference shows. Here is the card component before, as a Tailwind class list:

<article
  class:list={[
    "relative rounded border bg-card p-4 sm:p-6",
    "has-focus-visible:outline-2 has-focus-visible:outline-offset-2 has-focus-visible:outline-ring",
    className,
  ]}
  {...props}
>
  <slot />
</article>

And after, as scoped CSS in the same file:

<article class={className} {...props}>
  <slot />
</article>

<style>
  article {
    position: relative;
    border-radius: var(--radius);
    border-width: 1px;
    background-color: var(--bg-elevated);
    padding: 1rem;

    &:has(:focus-visible) {
      outline: 2px solid var(--accent);
      outline-offset: 2px;
    }
  }

  @media (width >= 40rem) {
    article {
      padding: 1.5rem;
    }
  }
</style>

The markup goes quiet and the intent moves into CSS that reads like CSS. Native nesting holds the :has() state rule next to the base rule, and a normal media query handles the responsive padding that sm:p-6 used to encode. Astro scopes these styles through a generated data-astro-cid attribute, so a bare article selector is enough and the element needs no class of its own. And because scoped styles compile unlayered, they beat the global layers without any specificity games. That last property is what made the migration safe to do component by component: a scoped rule always wins over a global primitive, so I could move one file at a time without the two systems fighting.

Lightning CSS does the vendor work

The reflex worry with dropping a framework is that you inherit its chores: prefixing, downleveling new syntax, minifying. I inherited none of them, because Lightning CSS was already in the pipeline. It's a Rust parser, transformer, and minifier by Devon Govett, and it is the same tool Tailwind v4's Oxide engine depends on. Astro's Rust compiler uses it too, so turning it on for my own CSS was one line:

vite: {
  css: { transformer: "lightningcss" },
  build: {
    cssTarget: ["chrome111", "edge111", "firefox114", "safari16.4", "ios16.4"],
  },
}

It adds the handful of -webkit- prefixes my target browsers still need, lowers nesting for the stragglers, and minifies, all against a Baseline target set. The package.json diff was the satisfying part: out went tailwindcss, @tailwindcss/vite, and @tailwindcss/typography; in went a single lightningcss dev dependency that was effectively already there. The long-form article styling followed the same instinct I wrote about in shadcn/typeset vs Tailwind Typography: own the file, delete the rules you don't want.

Did the site stay Baseline compliant?

Yes, and that was a hard constraint, not a nice-to-have. Every feature this site ships has to be Baseline Widely available, interoperable across the core browsers for at least 30 months. That's exactly why the timing worked: the two features I lean on hardest, native nesting and :has(), only reached Widely availability around June 2026. If I'd tried this a year earlier they'd have been Baseline Newly at best, and the card component above would have needed an @supports gate with a full fallback. Doing it now, they're safe to use unguarded. The one place I still gate behind @supports is the anchor-positioned reading indicator in the table of contents, which is genuinely still Newly available.

Do you still need Tailwind in 2026?

Only if someone other than you owns the CSS. That is the honest split, and it decides whether replacing Tailwind with vanilla CSS is worth it for you:

A team with a shared design system: probably keep Tailwind. The constraints that feel like overhead on a solo site are the whole point when twenty people style the same product. Consistency you don't have to enforce by review is worth a build step.
A solo project or a content site: the trade-off has flipped. You get design tokens from custom properties, override control from cascade layers, nesting and state selectors natively, and scoping from your framework's components. The framework's value is real but no longer necessary.

I'm not claiming Tailwind lost. Kevin Powell has spent years arguing that learning CSS itself pays off, and the platform finally caught up to make that cheap. Tailwind v4 is a genuinely good piece of engineering, built on the same modern CSS that made me comfortable leaving it. For this site, hand-written CSS wired to theme variables is less code, one fewer dependency, and output I can read top to bottom. That's the same own-the-source call I keep making here, and this time the browser did most of the work for me.

Baseline 2026: 4 APIs That Changed How I Code

Wed, 22 Jul 2026 17:54:25 +0000

Baseline 2026 brought a wave of new interoperable web platform APIs. Not the kind of big where everything changes overnight. The kind where APIs that have been experimental for years finally ship in every browser. Baseline means you can use them in production without a polyfill, and the 2026 cohort has a handful that actually changed what I reach for when I start a new project. Not "technically you could," but "I stopped installing this."

The Navigation API: one `navigate` event instead of three different APIs

The Navigation API became Baseline Newly available in early 2026, supported in Chrome, Edge, Firefox 147, and Safari 26.2. It replaces the fragmented mess that was History API routing: pushState for navigation, popstate for back/forward, and manual link click handlers to prevent full-page reloads. Three separate APIs you had to wire together yourself, or reach for a router library that did it for you.

Here is what client-side routing looked like before:

// Before: three separate concerns, manually wired
window.addEventListener("popstate", (e) => {
  renderRoute(window.location.pathname);
});

document.addEventListener("click", (e) => {
  const link = e.target.closest("a[data-route]");
  if (link) {
    e.preventDefault();
    history.pushState(null, "", link.href);
    renderRoute(new URL(link.href).pathname);
  }
});

// Initial render
renderRoute(window.location.pathname);

And here is the Navigation API equivalent:

// After: one centralized event
navigation.addEventListener("navigate", (e) => {
  const url = new URL(e.destination.url);
  e.intercept({
    handler() {
      renderRoute(url.pathname);
    },
  });
});

One event. One interception point. The intercept() call tells the browser "I'll handle this navigation, wait for me," which also means the browser can show a loading indicator natively. You get scroll restoration (e.scroll()), form data access (e.formData), and entry traversal (navigation.traverseTo(key)) without wiring any of it yourself.

This does not kill React Router or TanStack Router. Both have open discussions about adopting the Navigation API as a backend: React Router's and TanStack Router's. They would sit on top of it rather than reimplement the History API workaround they currently maintain. The frameworks add value (nested routes, data loading, error boundaries) that the raw Navigation API does not. What the API kills is the need to pull in a router just to avoid full-page reloads on a content site. If your routing needs are modest (a blog, a docs site, a dashboard with a few views), the platform now has you covered.

The caveat: Safari 26.2 is missing precommitHandler support, which limits some advanced interception patterns. And Ian Hickson, the spec author, famously called pushState() his "favourite mistake," so the replacement had a low bar to clear.

Container style queries: theming without JS class toggling

Container style queries for custom properties became Baseline Newly available in May 2026, with Firefox 151 shipping the last piece and Chrome 148 adding name-only container queries the same month.

This one solves a problem I have written far too much JavaScript for: switching visual variants based on context. A card that renders differently in a sidebar vs. a hero section. A theme toggle that propagates across the component tree. All done with CSS classes, JS observers, or both.

Here is the old pattern:

// Before: JS class toggling for a card variant
function Card({ variant = "default" }) {
  return (
    <div className={`card card--${variant}`}>
      <h3>{title}</h3>
      <p>{excerpt}</p>
    </div>
  );
}

.card--featured { /* special styles */ }
.card--compact { /* compact styles */ }

And with container style queries:

.sidebar {
  container-name: sidebar;
  /* no container-type needed for style queries */
}

.card {
  /* default styles */
}

@container sidebar style(--variant: featured) {
  .card {
    /* featured layout */
  }
}

@container sidebar style(--compact: true) {
  .card {
    /* compact layout */
  }
}

The container declares its context via CSS custom properties, and descendant elements react. No JS. No class chains. The component does not need to know where it is rendered; the container owns that relationship.

The limitation worth mentioning: style queries currently only support custom properties. The spec allows querying any CSS property, but no browser ships that yet. So you query style(--theme: dark), not style(background-color: black). For the use case it solves (theming, layout variants, contextual styling): custom properties are exactly what you want. For arbitrary CSS property introspection, we are still waiting.

`:open`: state tracking you never write

The :open pseudo-class became Baseline Newly available in May 2026 when Safari 26.5 shipped it. It matches any element with an open semantic state: <dialog>, <details>, <select>, and <input type="color"> / <input type="date"> with their pickers open.

Before :open, styling an open disclosure meant either an attribute selector or JS:

/* Before: attribute selector, limited */
details[open] > summary {
  border-radius: 4px 4px 0 0;
}

// Before: manual state tracking for a dialog
dialog.addEventListener("toggle", () => {
  document.body.classList.toggle("dialog-open", dialog.open);
});

With :open:

details:open > summary {
  border-radius: 4px 4px 0 0;
}

/* Style the page when any dialog is open */
html:has(dialog:open) {
  overflow: hidden;
}

/* Style a label when its associated select is open */
label:has(select:open) {
  color: var(--accent);
}

The :has() combo is where this gets useful. html:has(dialog:open) is a body scroll lock in one line of CSS. label:has(select:open) is a parent style change driven by a child's state: something that used to require a JS mutation observer or a framework binding. The :open selector tracks semantic state, not visibility: a <details> that is semantically open but visually hidden still matches :open. That distinction matters for things like display: none inside an open disclosure.

This replaces the details[open] attribute selector (which only works for <details>) and the pattern of manually toggling CSS classes on <body> or parent elements when modals or pickers open. One pseudo-class, all openable elements, no JS.

`Math.sumPrecise()`: the "wait, `reduce` is wrong?" moment

Math.sumPrecise() became Baseline Newly available in April 2026, part of ES2026 after reaching TC39 Stage 4 in July 2025.

The problem it solves is floating-point summation error:

const numbers = [1e20, 0.1, -1e20];
numbers.reduce((a, b) => a + b, 0);  // 0
Math.sumPrecise(numbers);              // 0.1

The naive reduce approach loses precision because floating-point addition is not associative. When you add a very small number to a very large one, the small number disappears. Math.sumPrecise() uses the Shewchuk algorithm (or an equivalent) to produce the maximally correct answer: the result you would get with arbitrary-precision arithmetic rounded back to a float.

What it does NOT fix: 0.1 + 0.2. That is a floating-point representation problem, not a summation problem. Math.sumPrecise([0.1, 0.2]) still returns 0.30000000000000004 because the literals 0.1 and 0.2 are inexact before sumPrecise ever sees them.

The API is deliberately not variadic (Math.sumPrecise(1, 2, 3) throws). It takes an iterable to avoid stack overflows on large datasets. Empty iterables return -0 (the floating-point additive identity). Non-number elements throw a TypeError, unlike Math.max which silently coerces. TypeScript does not ship type definitions for it yet (issue #63427), so you may need a manual declaration depending on your TypeScript 7 version.

This is not the API that will headline anyone's year-end retrospective. But it fixes a real footgun: the kind of bug that passes code review because nobody spots the summation error in a 50-item array spread across a few chained .map() and .filter() calls. I wrote about JavaScript gotchas before, and floating-point behavior is the category that surprises experienced developers the most. Having a built-in that handles the common case correctly is a quiet win.

What "Baseline Newly available" actually means for Baseline 2026

All four of these APIs are Baseline Newly available, not Widely available. That distinction matters:

Newly available: All core browsers (Chrome, Edge, Firefox, and Safari across desktop and mobile) support the feature. You can use it in production.
Widely available: The feature has been interoperable for 30 months. You can use it without thinking about browser support.

These four are firmly in the "use it today" category. All core browsers ship them. If you still support older Safari or Firefox versions, feature detection is straightforward: "navigation" in window, CSS.supports("selector(:open)"), @supports (container-name: x) in CSS. None of these require a polyfill to degrade gracefully; they just need a fallback path.

The 30-month clock to Widely availability means these become "don't even think about it" territory between mid-2028 and late 2028.

The web platform is eating libraries from the edges in

None of these four APIs kills a major framework. You will still reach for React Router if your app has nested layouts, data loaders, and route-level error boundaries. You will still use a CSS-in-JS library if your design system demands it. What they kill is the dependency you pulled in for one thing: the router for a content site, the classnames utility for variant switching, the state tracking for modal-open classes.

The gap between "what the platform gives you" and "what you need a library for" keeps narrowing. The HTTP QUERY method landed earlier this year for safe reads with a body. Now we have routing, variant-driven styling, state selectors, and precise math, all Baseline, all in every browser.

We are not at zero dependencies. But each Baseline release shrinks the surface area that justifies pulling in someone else's code. And 2026 has been a good year for that.

Tailwind CSS for Beginners: From Zero to Your First Component

Tue, 21 Jul 2026 05:00:00 +0000

Introduction

The first time I saw a Tailwind CSS class list — something like flex items-center justify-between p-4 bg-slate-800 rounded-lg shadow-md — I genuinely thought it looked messy. Why not just write regular CSS?

Then I actually used it on a real project, and within a week I understood why so many developers (myself included now) switched permanently. You stop context-switching between HTML and a separate CSS file, you stop naming classes like .card-wrapper-inner-2, and you build UI noticeably faster.

This is the guide I wish I had when I started.

What Tailwind CSS Actually Is

Tailwind is a utility-first CSS framework. Instead of writing custom CSS classes, you compose your design directly in your HTML using small, single-purpose utility classes.

Regular CSS:

.button {
  padding: 8px 16px;
  background-color: #3b82f6;
  border-radius: 8px;
  color: white;
}

Tailwind:

<button class="px-4 py-2 bg-blue-500 rounded-lg text-white">
  Click Me
</button>

Same result. No separate CSS file needed for this button.

Setting It Up (React + Vite)

npm create vite@latest my-app -- --template react
cd my-app
npm install tailwindcss @tailwindcss/vite

In vite.config.js:

import tailwindcss from '@tailwindcss/vite'

export default {
  plugins: [tailwindcss()],
}

In your main CSS file:

@import "tailwindcss";

That's it — no separate config file required for modern Tailwind setups. Restart your dev server and you're ready to use utility classes anywhere.

Core Concepts You Need to Know

1. Spacing

p-4 = padding on all sides, px-4 = horizontal padding only, py-4 = vertical only, m-4 = margin. The number is a spacing scale (4 = 1rem = 16px).

2. Flexbox & Grid utilities

flex, items-center, justify-between, grid, grid-cols-3, gap-4 — everything from the Flexbox/Grid article, just as classes.

3. Responsive Design

Prefix any class with a breakpoint: md:flex-row means "apply this on medium screens and up."

<div class="flex flex-col md:flex-row gap-4">

This stacks items vertically on mobile, then switches to a row on tablets and larger.

4. Hover & State Variants

<button class="bg-blue-500 hover:bg-blue-600 transition">

hover: applies only on hover. Same pattern works for focus:, active:, disabled:.

Building Your First Component: A Pricing Card

<div class="max-w-sm mx-auto bg-slate-800 rounded-2xl p-6 shadow-lg">
  <h3 class="text-xl font-bold text-white mb-2">Starter Plan</h3>
  <p class="text-slate-400 mb-4">Perfect for small projects</p>
  <p class="text-3xl font-bold text-white mb-6">$9<span class="text-base font-normal text-slate-400">/mo</span></p>
  <button class="w-full py-2 bg-blue-500 hover:bg-blue-600 rounded-lg text-white font-medium transition">
    Get Started
  </button>
</div>

Notice what's happening: max-w-sm mx-auto centers and constrains the card width, rounded-2xl and shadow-lg give it depth, and everything is readable directly from the class names — no jumping to a separate file to understand the styling.

Common Beginner Mistakes

Fighting the spacing scale. Don't reach for custom pixel values
immediately — Tailwind's default scale (4, 8, 12, 16...) covers 95%
of real use cases.
Not using @apply for repeated patterns. If you're copy-pasting the
same 8 classes everywhere, extract them into a component instead of
a CSS class — that's the React way to do it, not @apply.
Ignoring the official docs. Tailwind's docs (tailwindcss.com) are
genuinely excellent — searchable, example-driven, and the fastest
way to find the exact class you need.

Final Thoughts

Tailwind feels weird for about a week, then it feels like the only sane way to write CSS. The speed difference is real — I build UI noticeably faster now than when I wrote custom CSS files for every component.

Start small: rebuild one existing component using Tailwind instead of your old CSS, and see how it feels.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev

shadcn/typeset vs Tailwind Typography for Markdown

Sat, 18 Jul 2026 16:44:34 +0000

You render some markdown, get back a pile of unstyled HTML, and then you style it. Headings, paragraphs, lists, tables, code. You do it for the blog. Then you do it again for the docs. Then a third time for the chat UI that streams model output token by token. Every context, the same elements, slightly different rules.

shadcn shipped a take on this on July 10, 2026, called shadcn/typeset. It's worth a look even if you don't use the rest of shadcn/ui, because it isn't a component and it isn't a CLI install. It's one CSS file you copy into your project and own outright.

What is shadcn/typeset?

Typeset is a styling system for rendered HTML and markdown, delivered as a single CSS file. You wrap your content in a .typeset container and everything inside it gets styled: headings, paragraphs, lists, tables, code, blockquotes, links, footnotes, even MathML and <details>.

<div className="typeset typeset-docs">
  <YourMarkdownRenderer>{content}</YourMarkdownRenderer>
</div>

.typeset turns the styles on. .typeset-docs is a preset, a small class you layer on top to tune the look for a specific context. You can define as many presets as you have contexts: one for the blog, one for the docs, one for chat.

The thing to internalize up front: there's no npm package and no config layer. As the changelog puts it, "the file lives in your project," nothing to update, nothing to work around. If a heading annoys you, you open the file and change the rule. That's the whole distribution model.

This is a different thing from shadcn/ui's Typography component, which gives you styled React heading and paragraph components to author by hand. Typeset styles HTML you didn't write, the output of a markdown renderer.

How do you install shadcn/typeset?

You don't run a CLI. As of this release there's no npx shadcn@latest add typeset, and expecting one will send you looking for a command that doesn't exist.

Instead you build the file in the interactive builder, pick your sizes and fonts, and copy the generated typeset.css into your project. Then you import it after Tailwind:

@import "tailwindcss";
@import "./typeset.css";

Import order matters, and I'll come back to why in a moment. Once it's in, the wrapper from the first snippet is all you need.

Size, leading, and flow

Typeset condenses typographic tuning into three CSS variables it calls "rhythm," and everything else derives from them:

.typeset {
  --typeset-size: 1em;      /* base font size */
  --typeset-leading: 1.75;  /* line-height */
  --typeset-flow: 1.25em;   /* vertical space between blocks */
}

A preset is just those three variables set to different values under a class name:

.typeset-chat {
  --typeset-flow: 1em;
  --typeset-leading: 1.6;
}
.typeset-docs {
  --typeset-size: 15px;
  --typeset-flow: 1.5em;
}

Because it's all CSS custom properties, you can override a single value inline without touching the file:

<article className="typeset [--typeset-flow:1.75em]">{content}</article>

The sizing is container-relative rather than a fixed rem scale. Below 48rem the base size gets a 1.125x bump and then settles back to the raw value on larger screens, so text reads comfortably on a phone without a separate small-screen variant. Colors and borders pull from your app's theme tokens (--color-foreground, --color-muted-foreground, --color-border, --radius) with sensible fallbacks, so dark mode just works when your tokens flip. There's no second inverted palette to maintain.

One deliberate omission: Typeset doesn't set a max-width. Your layout owns the measure. The builder's Measure control adds a max-width to the wrapper if you want it, but the stylesheet itself stays out of your layout's business.

Why your Tailwind utilities win without !important

Here's the detail I liked most. Typeset lives in the CSS @components layer and uses zero-specificity :where() selectors for every element rule:

@layer components {
  .typeset {
    & :where(h1) { font-size: 1.75em; /* ... */ }
    & :where(p)  { margin-block-start: var(--typeset-flow); }
  }
}

The override comes from cascade layers, not specificity. Typeset's rules live in the @components layer, and Tailwind's utilities live in the @utilities layer, which is declared after it. When rules in two different layers conflict, the later layer wins outright, no matter how specific either selector is. So a utility beats a Typeset rule with no !important and no special modifier syntax. Slap .text-3xl on a heading and it just wins.

:where() does a related but separate job: it holds every element rule at zero specificity, so an override that isn't already shielded by a later layer, like plain CSS you write yourself or a rule in the same layer, can still win without a specificity fight. That's also why import order matters. Importing Tailwind first establishes its layer order, which puts @utilities after Typeset's @components.

If you want to pull a whole subtree out, there's an escape hatch: .not-typeset (or the data-not-typeset attribute), which cascades to descendants including any nested .typeset container.

<Card className="not-typeset">Untouched component.</Card>

shadcn is candid that both of these ideas, the :where() guard and the opt-out class, are borrowed from @tailwindcss/typography, which has a .not-prose of its own. Which brings us to the comparison you actually clicked for.

shadcn/typeset vs Tailwind Typography

The Tailwind CSS Typography plugin, and the .prose class it hands you, has been the default answer for styling rendered markdown for years, and it's still excellent at what it was built for. Typeset isn't a drop-in replacement or a wrapper around it. It's a different set of trade-offs. The docs lay them out directly:

	Tailwind Typography (`.prose`)	Typeset
Sizing	Fixed `rem` scale, `.prose-sm` to `.prose-2xl`	Relative to the container, any size
Dark mode	`.prose-invert`, a second palette	Your tokens flip, nothing to add
Overrides	`prose-a:`, `prose-headings:` modifier API	Plain utilities and CSS win
Streaming	No append-stability contract	Designed for stable appends
Distribution	npm plugin, generated CSS	One CSS file you own

The way I'd frame it: .prose is a well-designed dependency you configure, and Typeset is a starting point you edit. If you like the modifier API and want a maintained plugin tracking Tailwind releases, .prose is still a great pick. If you'd rather own the file and delete the rules you don't want, Typeset fits that instinct better. It's the same philosophy as the rest of shadcn/ui: copy the code in, make it yours.

What makes it streaming-safe?

This is the part that made Typeset feel designed for 2026 rather than 2020. If you've built a chat UI that renders an LLM's markdown as it streams, you've watched the layout twitch as each token lands. Typeset treats that as a first-class constraint.

The rule is that there are no forward-looking selectors in the layout. :last-child, :has(), and :empty are deliberately kept out of spacing rules, because what they match changes as content appends, which restyles blocks that were already on screen. Spacing flows in one direction only, using margin-block-start and never margin-block-end:

& :where(p) {
  margin-block-start: var(--typeset-flow);
  margin-block-end: 0;
}

The same discipline shows up in tables: the row separators sit on the cells rather than on tr:last-child, so appending a row never re-runs a :last-child match and shifts the borders above it. When you add a new block to a Typeset container, nothing before it moves. That's a genuinely hard property to get right by hand, and it's baked into the stylesheet.

What it costs you

Two things are worth knowing before you commit.

First, the stylesheet leans on modern CSS, though most of it is safe by now: color-mix() and oklch() colors have been widely supported since 2023, and logical properties like margin-block-start work everywhere. The real outlier is margin-trim, which as of 2026 still ships only in Safari and other WebKit browsers (16.4 and up). There's no fallback for it, so in Chrome and Firefox that rule quietly does nothing. Worth knowing before you count on the margin trimming it's meant to handle.

Second, wide tables wrap to fit by default. Horizontal scroll is opt-in through a .typeset-scroll wrapper you have to add in your renderer's table component or a small rehype plugin. It won't happen automatically.

Should you use it?

If you're already in the shadcn/ui world and you're styling rendered markdown, especially anything that streams, Typeset is an easy yes: it's free, it's one file, and the streaming stability alone justifies it. If you're outside that ecosystem and happy with .prose, there's no migration to rush. It's an alternative with a clearer answer to a couple of specific problems, not an upgrade you're missing out on.

What I appreciate is the framing. shadcn keeps betting that the right unit of distribution for UI is source you own rather than a dependency you configure, and Typeset applies that bet to typography. I made a similar call rebuilding this site: the long-form styling here is hand-written Tailwind wired to theme variables rather than a plugin, for exactly the reason Typeset exists. The same instinct runs through generating OG images with Satori: own the design, skip the abstraction. Owning the CSS means when something looks off, you fix the rule instead of fighting the abstraction. Go build one in the builder and read the file it hands you. It's short, and reading it teaches you more about typographic CSS than the docs do.

CSS Flexbox vs Grid: When to Use Which (Beginner's Guide)

Fri, 17 Jul 2026 05:00:00 +0000

Introduction

Every beginner hits this wall eventually: "Do I use Flexbox or Grid here?"

I remember avoiding this question for months by just using Flexbox for everything — including things Grid was clearly built for. It worked, technically, but I was fighting the tool instead of using the right one.

Here's the short version before we go deep: Flexbox is for one direction (a row or a column). Grid is for two directions at once (rows AND columns together). Once that clicks, the decision gets easy.

Let's break it down properly.

What Flexbox Actually Does

Flexbox arranges items along a single axis — either horizontally or vertically.

.container {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

justify-content controls spacing along the main axis (usually horizontal), and align-items controls alignment on the cross axis (usually vertical).

Flexbox is perfect for:

Navigation bars (logo left, links right)
Buttons sitting side by side
Centering a single element vertically and horizontally
Card content where items need to stretch or wrap in one direction

What Grid Actually Does

Grid lets you define rows and columns at the same time, and place items precisely into that structure.

.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 20px;
}

This creates 3 equal-width columns with 20px gaps — no media queries needed to get a basic responsive layout going.

Grid is perfect for:

Full page layouts (header, sidebar, main content, footer)
Image galleries
Card grids (like a blog listing page)
Anything where you're thinking in rows AND columns

The Real Test: Ask Yourself This

"Am I arranging things in one line, or am I building a layout?"

One line → Flexbox
Layout/grid of items → Grid

A Practical Example: Building a Card Grid

Here's a common beginner project — a responsive grid of cards, done the right way with Grid:

<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
  <div class="bg-slate-800 p-4 rounded-lg">Card 1</div>
  <div class="bg-slate-800 p-4 rounded-lg">Card 2</div>
  <div class="bg-slate-800 p-4 rounded-lg">Card 3</div>
</div>

(That's Tailwind CSS classes, but it maps directly to Grid under the hood — grid, grid-cols-3, gap-6.)

Now, inside each card, if you need to align an icon next to a title, or push a button to the bottom of the card — that's Flexbox's job:

<div class="bg-slate-800 p-4 rounded-lg flex flex-col justify-between">
  <div class="flex items-center gap-2">
    <span>🔥</span>
    <h3>Card Title</h3>
  </div>
  <button>Learn More</button>
</div>

This is the pattern you'll use constantly: Grid for the outer layout, Flexbox for the inner content.

Common Beginner Mistakes

Using Grid for a simple navbar. Overkill — Flexbox does this in 3
lines.
Using Flexbox for a full page layout. You'll end up wrapping and
fighting widths that Grid handles natively.
Not using gap. Both Flexbox and Grid support gap now — no more
margin hacks between items.
Forgetting Grid can do more than equal columns.
grid-template-columns: 200px 1fr gives you a fixed sidebar +
flexible main content in one line.

Final Thoughts

You don't have to pick one and stick with it forever — most real websites use both together, Grid for structure and Flexbox for alignment inside components. Once you stop treating this as an either/or decision and start asking "one direction or two?", it stops being confusing.

Try rebuilding one of your old projects using this rule and see how much cleaner the CSS gets.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

shadcn/typeset vs Tailwind Typography: Styling Markdown

Sat, 11 Jul 2026 08:23:11 +0000

What is shadcn/typeset?

<div className="typeset typeset-docs">
  <YourMarkdownRenderer>{content}</YourMarkdownRenderer>
</div>

The thing to internalize up front: there's no npm package and no config layer. The changelog puts it plainly: "one CSS file that styles everything inside a typeset container. The file lives in your project, so you can change it directly when you need to." If a heading annoys you, you open the file and change the rule. That's the whole distribution model.

How do you install shadcn/typeset?

You don't run a CLI. As of this release there's no npx shadcn@latest add typeset, and expecting one will send you looking for a command that doesn't exist.

Instead you build the file in the interactive builder, pick your sizes and fonts, and copy the generated typeset.css into your project. Then you import it after Tailwind:

@import "tailwindcss";
@import "./typeset.css";

Import order matters, and I'll come back to why in a moment. Once it's in, the wrapper from the first snippet is all you need.

Size, leading, and flow

Typeset condenses typographic tuning into three CSS variables it calls "rhythm," and everything else derives from them:

.typeset {
  --typeset-size: 1em;      /* base font size */
  --typeset-leading: 1.75;  /* line-height */
  --typeset-flow: 1.25em;   /* vertical space between blocks */
}

A preset is just those three variables set to different values under a class name:

.typeset-chat {
  --typeset-flow: 1em;
  --typeset-leading: 1.6;
}
.typeset-docs {
  --typeset-size: 15px;
  --typeset-flow: 1.5em;
}

Because it's all CSS custom properties, you can override a single value inline without touching the file:

<article className="typeset [--typeset-flow:1.75em]">{content}</article>

Why your Tailwind utilities win without !important

Here's the detail I liked most. Typeset lives in the CSS @components layer and uses zero-specificity :where() selectors for every element rule:

@layer components {
  .typeset {
    & :where(h1) { font-size: 1.75em; /* ... */ }
    & :where(p)  { margin-block-start: var(--typeset-flow); }
  }
}

If you want to pull a whole subtree out, there's an escape hatch: .not-typeset (or the data-not-typeset attribute), which cascades to descendants including any nested .typeset container.

<Card className="not-typeset">Untouched component.</Card>

shadcn/typeset vs Tailwind Typography

	Tailwind Typography (`.prose`)	Typeset
Sizing	Fixed `rem` scale, `.prose-sm` to `.prose-2xl`	Relative to the container, any size
Dark mode	`.prose-invert`, a second palette	Your tokens flip, nothing to add
Overrides	`prose-a:`, `prose-headings:` modifier API	Plain utilities and CSS win
Streaming	No append-stability contract	Designed for stable appends
Distribution	npm plugin, generated CSS	One CSS file you own

What makes it streaming-safe?

& :where(p) {
  margin-block-start: var(--typeset-flow);
  margin-block-end: 0;
}

What it costs you

Two things are worth knowing before you commit.

Should you use it?

What I appreciate is the framing. shadcn keeps betting that the right unit of distribution for UI is source you own rather than a dependency you configure, and Typeset applies that bet to typography. I made a similar call rebuilding this site: the long-form styling here is hand-written Tailwind wired to theme variables rather than a plugin, for exactly the reason Typeset exists. Owning the CSS means when something looks off, you fix the rule instead of fighting the abstraction. Go build one in the builder and read the file it hands you. It's short, and reading it teaches you more about typographic CSS than the docs do.

What Was the First Project You Ever Built in an Online Code Editor?

Wed, 01 Jul 2026 15:28:00 +0000

Everyone remembers their first "Aha!" moment in web development. For a lot of us, it didn't happen in a complex local terminal environment; it happened in a browser.

Maybe you were searching for "how to test HTML CSS JS online" and stumbled into a basic code playground. You changed a background color to "red," saw the preview update instantly, and realized you could actually build things for the web.

Online IDEs have always been the gateway to frontend development. Even today, as experienced engineers, we still rely on JavaScript playgrounds to rapidly prototype ideas, test snippets, or share solutions.

I’ve been building NitroIDE to serve as a modern, distraction-free browser IDE for exactly these moments, but it got me feeling nostalgic.

What was the very first thing you ever built in a browser-based code editor? Was it a messy personal website, a broken CSS animation, or a calculator app? Let's share some stories.

CSS Box Shadow: The Complete Guide (with Copy-Paste Examples)

Tue, 16 Jun 2026 10:08:46 +0000

The box-shadow property sounds simple — but once you start layering shadows, building card elevation systems, or trying to recreate that exact Figma drop shadow in CSS, the syntax gets complicated fast.

This guide covers everything from the basics to advanced multi-layer techniques, with copy-paste examples throughout.

The Basic Syntax

``css

box-shadow: offset-x offset-y blur-radius spread-radius color;

Each part explained:

| Parameter | What it does |

|---|---|

| offset-x | Horizontal position. Positive = right, negative = left |

| offset-y | Vertical position. Positive = down, negative = up |

| blur-radius | Edge softness. 0 = crisp, higher = more diffuse |

| spread-radius | Expands (+) or contracts (−) the shadow before blur |

| color | Any valid CSS color, usually rgba() for opacity control |

A simple card shadow:

<code>css .card { box-shadow: 0 4px 16px rgba(0, 0, 0, 0.12); } </code>

Inset Shadows

Add the inset keyword to flip the shadow inside the element — useful for pressed button states and recessed input fields:

`css / Pressed button /

.btn:active {

box-shadow: inset 0 2px 6px rgba(0, 0, 0, 0.2);

}

/ Recessed input field /

input {

box-shadow: inset 0 2px 4px rgba(0, 0, 0, 0.1);

}

Multiple Shadow Layers

You can stack multiple shadows with a comma-separated list. The first shadow is drawn on top (closest to the element):

<code>css .card { box-shadow: 0 1px 3px rgba(0, 0, 0, 0.12), / tight inner shadow for crispness / 0 6px 24px rgba(0, 0, 0, 0.08); / wide outer shadow for ambient depth / } </code>

This two-layer pattern mimics how real shadows work — a bright direct light source creates a sharp inner shadow, while ambient light creates a soft outer glow.

The Four Elevation Levels

Here's a practical elevation scale for UI design:

`css / Flat — default state /

.elevation-0 {

box-shadow: none;

}

/ Subtle — cards, sections /

.elevation-1 {

box-shadow: 0 1px 3px rgba(0, 0, 0, 0.10), 0 2px 8px rgba(0, 0, 0, 0.06);

}

/ Standard — hover state, dropdowns /

.elevation-2 {

box-shadow: 0 4px 12px rgba(0, 0, 0, 0.12), 0 8px 24px rgba(0, 0, 0, 0.08);

}

/ Elevated — modals, dialogs /

.elevation-3 {

box-shadow: 0 8px 24px rgba(0, 0, 0, 0.14), 0 16px 48px rgba(0, 0, 0, 0.10);

}

Glow Effects

Set both offsets to 0 and use a saturated colour for a glow:

`css / Green glow /

.btn-primary:focus {

box-shadow: 0 0 0 3px rgba(47, 133, 90, 0.4);

}

/ Stacked glow for stronger effect /

.notification-badge {

box-shadow:

0 0 8px rgba(229, 62, 62, 0.5),

0 0 24px rgba(229, 62, 62, 0.25);

}

Using box-shadow as a Border

box-shadow can replace a border without affecting layout — useful for focus rings and outlines:

`css / Focus ring that respects border-radius /

button:focus-visible {

outline: none;

box-shadow: 0 0 0 3px rgba(66, 153, 225, 0.6);

}

/ 2px green border without layout shift /

.selected-card {

box-shadow: 0 0 0 2px #2f855a;

}

Neumorphism

The neumorphic trend uses two shadows in opposite directions on a matching background:

`css / Element background must match --surface /

:root {

--surface: #e0e5ec;

}

.neumorphic {

background: var(--surface);

box-shadow:

9px 9px 16px #b8bec7, / dark shadow — bottom-right /

-9px -9px 16px #ffffff; / light shadow — top-left /

}

/ Pressed state /

.neumorphic:active {

box-shadow:

inset 4px 4px 8px #b8bec7,

inset -4px -4px 8px #ffffff;

}

Animating box-shadow

Animating box-shadow directly triggers a repaint on every frame. For smooth hover transitions, it's still acceptable for most UI:

`css .card {

box-shadow: 0 2px 8px rgba(0, 0, 0, 0.10);

transition: box-shadow 0.2s ease, transform 0.2s ease;

}

.card:hover {

box-shadow: 0 8px 24px rgba(0, 0, 0, 0.15);

transform: translateY(-2px);

}

For high-frequency animations (scroll-tied effects), animate opacity on a ::after pseudo-element instead — this stays on the compositor layer.

box-shadow vs filter: drop-shadow()

| | box-shadow | filter: drop-shadow() |

|---|---|---|

| Follows | Element's box | Actual rendered shape |

| Supports inset | ✅ | ❌ |

| Supports spread | ✅ | ❌ |

| Multiple layers | ✅ (comma list) | ❌ (wrap in multiple elements) |

| Best for | Buttons, cards, divs | Transparent PNGs, SVGs |

Converting Figma Shadows to CSS

Figma's shadow panel maps directly to CSS:

X → offset-x
Y → offset-y
Blur → blur-radius
Spread → spread-radius
Colour + opacity → rgba() or hsla()
Inner Shadow → add inset keyword

Quick Reference: Common Patterns

`css / Soft card /

box-shadow: 0 1px 3px rgba(0,0,0,0.10), 0 2px 8px rgba(0,0,0,0.06);

/ Material elevation 2 /

box-shadow: 0 1px 2px rgba(0,0,0,0.12), 0 2px 4px rgba(0,0,0,0.08);

/ Modal / dialog /

box-shadow: 0 8px 32px rgba(0,0,0,0.15), 0 20px 64px rgba(0,0,0,0.10);

/ Focus ring /

box-shadow: 0 0 0 3px rgba(66,153,225,0.5);

/ Inset (pressed button) /

box-shadow: inset 0 2px 4px rgba(0,0,0,0.15);

/ Neumorphic (on #e0e5ec background) /

box-shadow: 9px 9px 16px #b8bec7, -9px -9px 16px #ffffff;

/ Remove shadow /

box-shadow: none;

Building Shadows Without Guessing

If you'd rather adjust sliders than type raw CSS, the CSS Box Shadow Generator at SnappyTools gives you a live preview with multi-layer support, Figma-style controls, and a one-click copy button. No install, runs 100% in the browser.

The key insight with box-shadow` is that single-layer shadows look flat. Stack a tight, slightly opaque shadow with a wider, more transparent one — and you get depth that actually looks right.

CSS box-shadow Deep Dive: Multi-Layer Shadows and Inset Effects

Fri, 12 Jun 2026 10:17:12 +0000

The box-shadow property looks simple but hides surprising depth. Here is everything you need to know about multi-layer shadows, inset effects, and production-ready presets.

Syntax recap

``css

box-shadow: [inset] offset-x offset-y [blur] [spread] color;

offset-x / offset-y: direction of the shadow. Negative values go left/up.
blur: soft edge (0 = sharp). Cannot be negative.
spread: expand (+) or shrink (-) the shadow beyond the element.
inset: puts the shadow inside the element instead of outside.

Multiple layers

Comma-separate shadows. First shadow draws on top:

<code>css .card { box-shadow: 0 1px 3px rgba(0, 0, 0, 0.12), 0 8px 32px rgba(0, 0, 0, 0.06); } </code>

The pattern: one tight, crisp shadow for definition — one wide, soft shadow for ambient depth. This matches how real light behaves.

Inset for pressed states

<code>css .btn:active { box-shadow: inset 0 2px 6px rgba(0, 0, 0, 0.25); transform: translateY(1px); } </code>

Combine inset shadow + 1px translateY for a convincing button press.

Border replacement

box-shadow: 0 0 0 3px rgba(66, 153, 225, 0.5) is a zero-blur, zero-offset shadow that acts like an outline — respects border-radius and doesn't affect layout.

Glow effect

Zero offset + large blur + saturated colour:

<code>css .neon { box-shadow: 0 0 10px rgba(47, 133, 90, 0.5), 0 0 40px rgba(47, 133, 90, 0.2); } </code>

Quick reference table

| Use Case | CSS |

|----------|-----|

| Soft card | 0 2px 8px rgba(0,0,0,0.08) |

| Material elevation | 0 1px 3px rgba(0,0,0,0.12), 0 4px 16px rgba(0,0,0,0.08) |

| Focus ring | 0 0 0 3px rgba(66,153,225,0.5) |

| Inset press | inset 0 2px 6px rgba(0,0,0,0.2) |

| Glow | 0 0 20px rgba(47,133,90,0.4)` |

You can build and preview all of these visually at SnappyTools CSS Box Shadow Generator — sliders for every parameter, multi-layer support, live preview, and one-click CSS copy.

Originally published at https://snappytools.app/css-box-shadow-generator/

CSS Gradients: Linear, Radial, and Conic — Syntax Reference and Real Examples

Fri, 12 Jun 2026 02:07:41 +0000

CSS gradients are powerful and flexible, but the syntax is easy to forget if you don't use them every day. Here's a complete reference with real examples.

Three Types of CSS Gradients

Linear Gradient

``css

background: linear-gradient(direction, color1, color2, ...);

Direction options:

Keywords: to right, to bottom, to bottom right
Angles: 45deg, 135deg, 270deg

`css / Basic /

background: linear-gradient(to right, #2f855a, #68d391);

/ Diagonal /

background: linear-gradient(135deg, #667eea, #764ba2);

/ Three stops /

background: linear-gradient(to right, #f6d365, #fda085, #f093fb);

Angle reference: 0deg = bottom to top, 90deg = left to right, 180deg = top to bottom.

Radial Gradient

<code>css background: radial-gradient(shape size at position, color1, color2); </code>

`css / Circle from center /

background: radial-gradient(circle, #667eea, #764ba2);

/ Circle from corner /

background: radial-gradient(circle at 10% 10%, #a8edea, #fed6e3);

Conic Gradient

Good for pie charts and colour wheels:

<code>css / Pie chart: 30% / 50% / 20% / background: conic-gradient(red 0% 30%, blue 30% 80%, green 80% 100%); </code>

Hard Stops (No Fade)

Position two stops at the same point to create a sharp colour change:

<code>css / Striped flag / background: linear-gradient(to right, red 0% 33%, white 33% 66%, blue 66% 100% ); </code>

Repeating Gradients

<code>css / Diagonal stripes / background: repeating-linear-gradient( 45deg, transparent, transparent 10px, #2f855a 10px, #2f855a 20px ); </code>

Common Use Cases

| Pattern | CSS |

|---|---|

| Hero overlay | linear-gradient(135deg, #667eea, #764ba2) |

| Card darkening | linear-gradient(to bottom, transparent, rgba(0,0,0,0.6)) |

| Progress bar fill | linear-gradient(to right, #2f855a, #68d391) |

| Radial spotlight | radial-gradient(circle, rgba(255,255,255,0.3), transparent) |

| Stripe divider | repeating-linear-gradient(45deg, ...)` |

Browser Support

All three types are supported in all modern browsers (Chrome, Firefox, Safari, Edge) with no vendor prefixes needed.

Generate Without Writing It

The SnappyTools Gradient Generator lets you pick colours, adjust direction, and copy the final CSS directly — with a live preview on a real element. Useful when you want to experiment visually before writing code.

Which gradient type do you use most in production? Linear for backgrounds, or do you actually use conic gradients?

CSS Minification: What It Does and When to Use It

Wed, 10 Jun 2026 10:12:15 +0000

CSS minification removes everything in a stylesheet that the browser does not need — whitespace, comments, redundant semicolons, and shorthand colour values — without changing what any rule does. A typical stylesheet drops 20–40% in size after minification, and that reduction is compounded further when gzip is applied on the server.

What gets removed

A minifier processes your CSS and strips:

All whitespace (spaces, tabs, newlines between rules)
Comments (/ ... /)
Redundant trailing semicolons in rule blocks
Verbose colour notation (#ffffff → #fff)
Leading zeros (0.5em → .5em)
Zero units (0px → 0)

The resulting CSS is functionally identical to the original. Every selector, property, and value is preserved.

How much size reduction to expect

For a 100 KB stylesheet:

After minification: ~65–80 KB
After minification + gzip: ~15–25 KB

Minification reduces file size directly. It also improves gzip compression ratios because the compressor encounters a more consistent character pattern. Minification without gzip still helps; gzip without minification helps more; both together give the best result.

Build tool integration

Modern JavaScript build tools minify CSS automatically in production mode:

Vite:

`<code>bash vite build # CSS is minified via LightningCSS automatically </code>

Webpack:
<code>bash <h1>css-minimizer-webpack-plugin is included in most webpack templates</h1> <h1>It runs automatically when mode: 'production' is set</h1> </code>

PostCSS + cssnano (explicit):
<code>bash npx postcss styles.css --use cssnano -o styles.min.css </code>

For projects without a build pipeline, minify the file once manually before deploy. For static sites maintained without tooling, use an online minifier like the CSS Minifier & Beautifier on SnappyTools — paste the stylesheet, click Minify, copy the result.

Beautifying minified CSS

When you need to read a minified file (vendor code, a received production bundle, a legacy file without a source), beautify it first. Beautification is the reverse operation: it restores indentation, adds newlines between rules, and formats output consistently.

Beautified CSS is for reading only — re-minify before deploying if you make changes.

Source maps

If you are debugging a production issue in minified CSS, use source maps. Most minifiers support --source-map` flags. Source maps let browser DevTools map minified positions back to the original source file and line number, making CSS debugging viable without de-minifying.

When minification does not matter

For internal tools, admin panels, or sites with a single small stylesheet (under 20 KB), minification has a negligible impact. Spend optimisation effort on images and JavaScript first; CSS rarely contributes more than 5–10% of total page weight on modern sites.

Minify or beautify a CSS file without a build tool at snappytools.app/css-minifier-beautifier/ — runs entirely in your browser.

Originally published at https://snappytools.app/css-minifier-beautifier/</a>

CSS Gradients: A Complete Guide for Developers and Designers

Mon, 08 Jun 2026 10:15:50 +0000

CSS gradients let you create smooth transitions between colours without image files — they're resolution-independent, load instantly, and are supported in every modern browser. If you've been avoiding gradients because the syntax looks intimidating, this guide breaks it down step by step.

The Three Types of CSS Gradient

1. Linear Gradient

The most common type. Colour transitions along a straight line.

``css

/ Basic top-to-bottom /

background: linear-gradient(#6c63ff, #f43f8a);

/ With direction /

background: linear-gradient(to right, #6c63ff, #f43f8a);

/ With angle /

background: linear-gradient(135deg, #6c63ff, #f43f8a);

The angle controls direction: 0deg is bottom-to-top, 90deg is left-to-right, 180deg is top-to-bottom. The most popular choice in modern UI design is 135deg — a diagonal that feels dynamic without being aggressive.

2. Radial Gradient

Transitions outward from a centre point, creating circular or elliptical patterns.

`css / Default — ellipse from centre /

background: radial-gradient(#6c63ff, #f43f8a);

/ Circle, positioned top-left /

background: radial-gradient(circle at 20% 30%, #6c63ff, transparent);

Radial gradients are useful for spotlight effects, glow accents, and the mesh gradient technique (stacking multiple radials at different positions).

3. Conic Gradient

Transitions around a centre point, like a pie chart or colour wheel.

<code>css background: conic-gradient(red, orange, yellow, green, blue, violet, red); </code>

Conic gradients are perfect for progress rings, pie charts, and colour wheels.

Adding Multiple Colour Stops

Gradients aren't limited to two colours. Add as many stops as you need:

<code>css background: linear-gradient(135deg, #6c63ff 0%, #f43f8a 50%, #ff7700 100%); </code>

Stop positions can be percentages or lengths (px, em). If you omit positions, the browser distributes stops evenly.

Creating a Gradient Overlay on an Image

One of the most practical uses of gradients is overlaying them on photos to keep text legible:

<code>css .hero { background: linear-gradient(rgba(0, 0, 0, 0.6), rgba(0, 0, 0, 0.1)), url('photo.jpg') center / cover no-repeat; } </code>

The gradient is listed first so it renders on top. Replace the rgba values with a brand colour for a tinted overlay.

Rainbow Gradient

A full-spectrum rainbow uses all seven spectral colours as stops:

<code>css background: linear-gradient(90deg, #ff0000, #ff7700, #ffff00, #00cc00, #0000ff, #8b00ff); </code>

For a smoother transition, add more intermediate stops between primary colours.

Animating a Gradient

CSS can't directly interpolate between gradient stops, but you can simulate animation using background-size and background-position:

`css .animated {

background: linear-gradient(270deg, #6c63ff, #f43f8a, #6c63ff);

background-size: 400% 400%;

animation: gradientShift 4s ease infinite;

}

@keyframes gradientShift {

0% { background-position: 0% 50%; }

50% { background-position: 100% 50%; }

100% { background-position: 0% 50%; }

}

This creates a looping colour shift with pure CSS — no JavaScript required.

Applying a Gradient to Text

<code>css .gradient-text { background: linear-gradient(135deg, #6c63ff, #f43f8a); -webkit-background-clip: text; -webkit-text-fill-color: transparent; background-clip: text; } </code>

The -webkit- prefixes are still needed for Safari compatibility.

Using CSS Custom Properties with Gradients

`css :root {

--grad-start: #6c63ff;

--grad-end: #f43f8a;

}

.hero {

background: linear-gradient(135deg, var(--grad-start), var(--grad-end));

}

@media (prefers-color-scheme: dark) {

:root {

--grad-start: #3b1fa8;

--grad-end: #a0155a;

}

Mesh Gradients

<code>css .mesh { background: radial-gradient(at 20% 30%, #6c63ff 0px, transparent 50%), radial-gradient(at 80% 70%, #f43f8a 0px, transparent 50%), radial-gradient(at 50% 50%, #68d391 0px, transparent 60%); background-color: #0f172a; } </code>

Quick Reference: Linear Gradient Angles

| Angle | Direction | CSS Keyword |

|-------|-----------|-------------|

| 0deg | Bottom → Top | to top |

| 90deg | Left → Right | to right |

| 135deg | Bottom-left → Top-right | to top right |

| 180deg | Top → Bottom | to bottom |

| 270deg | Right → Left | to left |

Tools

Use the CSS Gradient Generator on SnappyTools — add colour stops, adjust the angle, switch between linear/radial/conic, and copy the ready-to-use CSS in one click. Free, no account needed.

Summary

Use linear-gradient for directional fades and hero sections
Use radial-gradient for spotlights, glows, and mesh effects
Use conic-gradient for charts and colour wheels
Animate with background-size + background-position` — no JavaScript needed
Use CSS custom properties for themeable gradients in design systems

Originally published at https://snappytools.app/gradient-generator/

CSS Gradient Animations: How to Animate Gradients That CSS Can't Directly Animate

Fri, 05 Jun 2026 10:12:20 +0000

CSS can't interpolate gradient colours directly — transition: background has no effect on gradients. Here are three practical techniques for animating CSS gradients.

Why Transitions Don't Work on Gradients

background: linear-gradient(...) is treated as an image value by CSS, not a colour. You can't transition between two image values, so the browser just snaps. Here are the workarounds.

Technique 1: Background-Position Shift (Pure CSS)

Make the gradient oversized and animate its position:

``css

.animated {

background: linear-gradient(270deg, #6c63ff, #f43f8a, #68d391, #6c63ff);

background-size: 400% 400%;

animation: shift 6s ease infinite;

}

@keyframes shift {

0% { background-position: 0% 50%; }

50% { background-position: 100% 50%; }

100% { background-position: 0% 50%; }

}

The gradient is 4× the element width. Animating the position creates a smooth looping effect. Duplicate the start colour at the end for seamless looping.

Good for: Hero sections, button hovers, card backgrounds.

Technique 2: Pseudo-Element Crossfade

Layer two gradients on pseudo-elements and fade between them:

`css .crossfade { position: relative; }

.crossfade::before,

.crossfade::after {

content: '';

position: absolute;

inset: 0;

border-radius: inherit;

}

.crossfade::before {

background: linear-gradient(135deg, #6c63ff, #f43f8a);

}

.crossfade::after {

background: linear-gradient(135deg, #f43f8a, #68d391);

animation: fade 3s ease-in-out infinite alternate;

}

@keyframes fade {

0% { opacity: 0; }

100% { opacity: 1; }

}

This looks like a true colour transition. No JavaScript needed, but uses both pseudo-elements.

Technique 3: CSS Custom Properties + JavaScript

For full control, use CSS variables and update them each frame:

<code>css .dynamic { background: linear-gradient( var(--angle, 135deg), var(--c1, #6c63ff), var(--c2, #f43f8a) ); } </code>

`javascript let hue = 0;

const el = document.querySelector('.dynamic');

function tick() {

hue = (hue + 0.5) % 360;

el.style.setProperty('--c1', hsl(${hue}, 70%, 60%));

el.style.setProperty('--c2', hsl(${(hue + 120) % 360}, 70%, 60%));

requestAnimationFrame(tick);

}

tick();

This gives you complete control over all gradient parameters every frame. Requires JavaScript but works in all modern browsers.

Animating the Angle (Houdini)

To animate the gradient angle with pure CSS, register the custom property:

`css @property --angle {

syntax: "";

initial-value: 0deg;

inherits: false;

}

.rotating {

background: conic-gradient(from var(--angle), #6c63ff, #f43f8a, #6c63ff);

animation: spin 4s linear infinite;

}

@keyframes spin {

to { --angle: 360deg; }

}

Without @property, the animation jumps instead of rotating smoothly. Currently supported in Chrome and Edge only.

Performance Tips

Gradient animations trigger repaints. Keep them fast:

Use will-change: background` on animated elements
Limit to a few animated elements per page
Prefer Technique 1 for simple loops — it's the most GPU-friendly

Start with the gradient CSS from the CSS Gradient Generator at SnappyTools, then wrap it in the animation code above.

CSS Minification: What Gets Stripped and What Stays

Tue, 02 Jun 2026 10:18:09 +0000

CSS minification is one of those optimisations that's easy to apply and genuinely makes a difference for page load speed. But it's worth knowing exactly what a minifier does — and doesn't — change about your stylesheet.

What a minifier removes

Comments

All / block comments / are stripped. The one exception: comments starting with /*! are preserved by convention — they hold licence notices that must appear in distributed files.

Whitespace

Every space, tab, and newline that CSS doesn't need for correctness is removed. That includes:

Spaces around :, {, }, ,, and ;
Line breaks between rules
Indentation

Trailing semicolons

The last property in any { } block doesn't need a semicolon. Minifiers remove it.

Redundant units on zero

margin: 0px becomes margin:0. The px is meaningless when the value is zero.

What a minifier keeps

All your CSS rules. Every selector, property, and value. Minification never removes live code — only syntax around it.

Vendor prefixes. -webkit-, -moz-, -ms- are kept exactly as written.

At-rules. @media, @keyframes, @import, @charset are all preserved.

Minification vs tree-shaking

These are different optimisations:

Minification — keeps all rules, compresses syntax
Tree-shaking (PurgeCSS, Tailwind JIT) — removes CSS rules that are never referenced in your HTML/JS

For utility-heavy frameworks like Bootstrap or Tailwind, tree-shaking produces much larger savings than minification alone. Do both: tree-shake first, then minify the result.

Typical savings

| Scenario | Typical reduction |

|----------|------------------|

| Handwritten CSS with comments | 25–40% |

| Already compact CSS | 5–15% |

| After Brotli on top | Additional 60–70% |

How to minify

Build tools: Vite, webpack (CssMinimizerWebpackPlugin), PostCSS + cssnano — all handle this automatically in production builds.

CLI: npx lightningcss --minify input.css -o output.min.css

One-off: The CSS Minifier on SnappyTools lets you paste CSS, see instant results with a bytes-saved counter, and copy the output. It also has a Beautify tab for when you receive minified CSS and need to read it. Runs entirely in your browser — nothing is uploaded.

Minification is the safest performance optimisation in the CSS toolbox. Knowing it only removes whitespace and comments (never logic) makes it a no-brainer step before every production deploy.

CSS Linear Gradient Angles: The Complete Reference

Tue, 02 Jun 2026 10:15:18 +0000

CSS gradients confuse a lot of developers because the angle system doesn't work the way you'd expect from school trigonometry. Once you understand the pattern, every gradient you see becomes readable — and every gradient you build becomes intentional.

The CSS angle system

In CSS, gradient angles measure direction from 12 o'clock (straight up), increasing clockwise. This is different from standard math angles, which measure from 3 o'clock increasing counter-clockwise.

The result:

0deg → bottom to top
90deg → left to right
180deg → top to bottom
270deg → right to left

The 8 standard angles

| Angle | Direction | CSS keyword equivalent |

|-------|-----------|----------------------|

| 0deg | Bottom → Top | to top |

| 45deg | Bottom-left → Top-right | to top right |

| 90deg | Left → Right | to right |

| 135deg | Top-left → Bottom-right | to bottom right |

| 180deg | Top → Bottom | to bottom |

| 225deg | Top-right → Bottom-left | to bottom left |

| 270deg | Right → Left | to left |

| 315deg | Bottom-right → Top-left | to top left |

Why 135deg is everywhere

Browse any modern SaaS landing page and you'll see 135deg gradients. It's the "default diagonal" — enough movement to feel dynamic, but balanced enough not to feel chaotic. Purple-to-pink, blue-to-teal, and orange-to-red gradients all look natural at 135deg.

``css

/ The classic /

background: linear-gradient(135deg, #6c63ff 0%, #f43f8a 100%);

Keyword vs degree

CSS keywords like to bottom right point toward the corner of the element, so the actual angle depends on the element's aspect ratio. A 100x100px element with to bottom right uses exactly 135deg, but a 200x100px element uses a different angle.

For consistency, especially in tight designs, use explicit degree values.

Practical examples

`css / Hero section — top to bottom /

background: linear-gradient(180deg, #1e3a8a 0%, #0f172a 100%);

/ Progress bar — left to right /

background: linear-gradient(90deg, #2f855a, #68d391);

/ Button — subtle diagonal /

background: linear-gradient(135deg, #276749, #2f855a);

Building gradients visually

If you prefer to experiment visually before writing CSS, the CSS Gradient Generator on SnappyTools has an angle slider, multi-stop colour pickers, and outputs ready-to-paste CSS for linear, radial, and conic gradients. It also exports Tailwind arbitrary-value classes directly.

Gradient angles become intuitive quickly — once you remember that 0deg points up and values go clockwise, the rest follows. Keep 135deg in your muscle memory as the go-to diagonal, and reach for 90deg and 180deg for UI bars and page sections.

Coder Legion - Recent posts tagged css

A hash-based CSP has no room for a syntax highlighter

What a hash can and cannot cover

Shiki was the first casualty

The rule that fell out of it

The test is on the built output, not the source

Worth checking on yours

Diagnose scroll snap failures: prerequisites, decision, result, limitation

Working example

Your Flex Child Won't Shrink, and overflow: hidden Isn't the Fix (It's min-width: 0)"

The Layout That Breaks

Why It Happens

Why overflow: hidden Looks Like a Fix (Sometimes)

Fix 1: min-width: 0 on the Flex Child

Fix 2: Grid's 1fr Has the Same Trap

Fix 3: Truncating Text With an Ellipsis Inside Flex

Fix 4: Long Words Need the Right overflow-wrap

Which One When

The Rule

min(), max(), and clamp() Will Replace 80% of Your Media Queries

FSCSS layout helpers: stack, hstack, center, size, rounded, ratio-fit(), etc

Why these exist

Spacing axes

stack and hstack

center

size and friends

rounded and surface chrome

Small composed example

Runtime note: fscss-props

When to use what

Try it

A Declarative Naming Layer for the View Transition API

Moving Transition Identity Out of CSS

First Attempt: Vue Directives

A Small Attribute Language

Hierarchical Names

Controlling Participation and Propagation

The $ Syntax Exists Only During Authoring

Runtime Orchestration

Keeping CSS Generic

Editor Tooling Became Part of the Design

Generating Transition Names and Types

The Real Production Case

This Is Not Fundamentally Vue-Specific

What I Learned From Building It

A Useful Side Effect: Agent-Friendly Transitions

Container queries: prefer the right container-type for the axis you query

Working example

Build a Pure CSS Radar Chart — Lightweight, Max Performance

Here’s how it works

1. Data is an array

2. One mixin writes coordinates

3. Renderers only read variables

4. Markup is plain HTML

Here’s how values can be displayed on the dot nodes

Option A — data-value + CSS ::after

Option B — nested label element

Option C — update labels from JS with the series

Here’s why it’s lighter

Here are some use cases of spider (radar) charts

Here’s how to do multi-series radar charts with still pure CSS

Quick start

Stop setting your dark mode background to #000000 and text to #FFFFFF

Debugging scroll anchoring when a prepended feed shifts

Reproduce the two states

Decide whether to keep anchoring

Halving Codebase Duplication in Static Site Generators

Architectural Decision and Trade-offs

Implementing Component Extraction and CSS Merging

Verification and Test Suite Integrity

Conclusion

Animating a 3D Gift Box with WebGPU

FOUC-Proof Retro Design Systems

The Pitfall of Retro Aesthetics on the Web

The Mathematics of Accessible Contrast

Eliminating FOUC with Synchronous Head Scripts

Maintaining a Single Source of Truth

FSCSS 1.2.5 ships property shorthands: size, px, inset-x, ratio-fit()

🚨 CSS Specificity — The Hidden Reason Your UI Breaks

The Production Incident That Started This

Why `overflow: hidden` Looks Like a Fix (Sometimes)

`stack` and `hstack`

`center`

`size` and friends

`rounded` and surface chrome

Runtime note: `fscss-props`

The `$` Syntax Exists Only During Authoring

Option A — `data-value` + CSS `::after`

1️⃣ `:is()`

2️⃣ `:not()`

3️⃣ `:where()`

3. Map your data to `--st-pN`

The core change: Array (`@arr`)