feat(analytics+blog): web vitals + 2 more posts (#107)

nextlevelshit · Michael Czechowski · commit c44964cdab84 · 2026-05-10T03:06:48.000+02:00
Co-authored-by: Michael Czechowski &lt;mail@dailysh.it&gt;
Co-committed-by: Michael Czechowski &lt;mail@dailysh.it&gt;
diff --git a/blog/2026-05-10-cascade-layers-control-specificity.md b/blog/2026-05-10-cascade-layers-control-specificity.md
@@ -0,0 +1,148 @@
+---
+title: "@layer — Finally Control CSS Specificity Without `!important`"
+description: "Cascade layers let you decide which rules win, regardless of selector specificity. The end of utility-class arms races and `!important` graveyards."
+date: 2026-05-10
+slug: cascade-layers-control-specificity
+tags: [css, architecture]
+---
+
+Every large CSS codebase eventually accumulates `!important` declarations. Bootstrap utilities use them. Tailwind's `!` prefix exists for them. Frameworks add them defensively, then your overrides need their own `!important`, then someone else's reset wins anyway. Cascade layers stop the war.
+
+## The basic idea
+
+```css
+@layer reset, base, components, utilities;
+
+@layer reset {
+  * { margin: 0; padding: 0; }
+}
+
+@layer base {
+  body { font: 16px/1.5 system-ui, sans-serif; color: #1f2937; }
+}
+
+@layer components {
+  .button { padding: .75rem 1rem; border-radius: 6px; }
+}
+
+@layer utilities {
+  .mt-4 { margin-top: 1rem; }
+}
+```
+
+The first line declares an order. **Later layers always beat earlier layers**, regardless of selector specificity. So an unstyled `.mt-4` (one class) wins over `.button.button-primary[data-state="active"]` (huge specificity) — because it's in a layer declared later.
+
+Anything *outside* layers wins over *anything inside* layers.
+
+## Why this changes everything
+
+Before layers, the cascade was:
+
+1. !important
+2. inline styles
+3. id selectors
+4. class/attribute/pseudo-class selectors
+5. element selectors
+
+You "won" by being more specific. The arms race: `.btn` → `.btn.btn-primary` → `body .btn.btn-primary` → `!important` → end of conversation.
+
+With layers:
+
+1. !important (still nuclear)
+2. inline styles
+3. **Unlayered styles**
+4. **Layers, in declared order (last wins)**
+
+Inside a layer, normal specificity still applies — but only against other rules in the same layer. Cross-layer comparisons obey the order. Predictable.
+
+## Real example: third-party + your overrides
+
+```css
+/* In a single stylesheet */
+@layer vendor, components, utilities, overrides;
+
+@layer vendor {
+  /* Bootstrap dump goes here */
+  @import url("bootstrap.css");
+}
+
+@layer components {
+  .card { background: #fff; padding: 1.5rem; }
+}
+
+@layer utilities {
+  .p-0 { padding: 0; }
+}
+
+@layer overrides {
+  .card { background: #f3f4f6; }
+}
+```
+
+Your `.card` override in the `overrides` layer beats Bootstrap's, **without** needing `!important` or higher specificity. Even Bootstrap's `.card.card-primary[data-bs-toggle]` loses, because the layer order said so.
+
+## Three patterns I keep using
+
+**1. Reset that doesn't fight everything else**
+
+```css
+@layer reset, *;
+
+@layer reset {
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+}
+```
+
+The `*` in the layer-order means "every other layer goes after reset." Reset rules sit at the bottom, every named or unnamed layer wins.
+
+**2. Tailwind-style utilities that always win**
+
+```css
+@layer base, components, utilities;
+
+@layer utilities {
+  .text-center { text-align: center; }
+  .hidden { display: none; }
+}
+```
+
+Now `.hidden` works without the Tailwind `!` prefix or `!important`. It's just last in the order.
+
+**3. Theming**
+
+```css
+@layer theme.light, theme.dark;
+
+@layer theme.light {
+  :root { --bg: white; --text: #111; }
+}
+
+@layer theme.dark {
+  [data-theme="dark"] { --bg: #111; --text: #fafafa; }
+}
+```
+
+Dot-notation creates sublayers. Useful for organization; works the same as flat layers for ordering.
+
+## Caveats
+
+- **Anonymous unlayered styles win.** If a stylesheet is partially layered, the unlayered parts beat *all* layers. Not always what you want — declare a default layer like `@layer base { ... }` to avoid surprises.
+- **`@import` with layer**: `@import url("x.css") layer(vendor);` puts the whole imported sheet into one layer. Useful for wrapping legacy CSS.
+- **Nested layers** (`@layer components.card { ... }`) are cool but rarely needed. Keep it flat.
+- **`!important` STILL nukes everything.** Cascade layers don't replace `!important` — they replace the *need* for it.
+
+## Browser support (2026-05)
+
+[Caniuse](https://caniuse.com/css-cascade-layers): all major browsers since Q1 2022. Chrome 99, Safari 15.4, Firefox 97. Three years of universal support.
+
+## What this kills
+
+- **CSS-in-JS libraries that exist only to scope styles**. If you wanted styled-components for "components win over global," `@layer components` does it natively.
+- **The `!important` epidemic**. Most uses of `!important` are workarounds for "this should win." Layers express that intent declaratively.
+- **Shadow DOM as a "specificity hack"**. Layers don't replace Shadow DOM's encapsulation, but for simple "make my override win," they're cheaper.
+
+I removed every `!important` from a 2k-line stylesheet last quarter using nothing but cascade layers and shorter selectors. The cascade became readable again.
+
+---
+
+Hands-on CSS practice on [Code Crispies](/) — see the [`css-fundamentals`](/css-fundamentals/0/) module for selectors and specificity exercises with live preview.
diff --git a/blog/2026-05-10-scroll-driven-animations-css.md b/blog/2026-05-10-scroll-driven-animations-css.md
@@ -0,0 +1,150 @@
+---
+title: "Scroll-Driven Animations — Keyframes Triggered by Scroll, No JS"
+description: "animation-timeline lets CSS animations advance based on scroll position. Reading-progress bars, parallax, scrubbed reveals — all without IntersectionObserver."
+date: 2026-05-10
+slug: scroll-driven-animations-css
+tags: [css, animation, scroll]
+---
+
+Animations bound to scroll position used to mean GreenSock + ScrollMagic, or hand-rolled `IntersectionObserver` + RAF loops. CSS now ties any keyframe animation to scroll progress — declaratively, with no JavaScript.
+
+## Reading progress bar in 8 lines
+
+```css
+@keyframes grow {
+  from { width: 0; }
+  to   { width: 100%; }
+}
+
+.progress-bar {
+  position: fixed;
+  top: 0; left: 0;
+  height: 4px;
+  background: var(--accent);
+  animation: grow linear;
+  animation-timeline: scroll(root);
+}
+```
+
+That's it. The `animation-timeline: scroll(root)` ties the animation's progress to scrolling the root scroller (i.e. the page). Scroll 50% down → animation at 50% → bar at 50% width.
+
+No `requestAnimationFrame`, no scroll listener, no `e.preventDefault()`. The browser does the math.
+
+## Reveal on scroll with `view-timeline`
+
+```css
+@keyframes fade-in {
+  from { opacity: 0; transform: translateY(20px); }
+  to   { opacity: 1; transform: translateY(0); }
+}
+
+.card {
+  animation: fade-in linear;
+  animation-timeline: view();
+  animation-range: entry 0% cover 30%;
+}
+```
+
+`view()` ties the animation to **the element's own viewport progress**. `animation-range` says "play from when the element starts entering to when it's covered 30%." So as the card scrolls into view, it fades in over the first 30% of its travel. Scroll back up → animation reverses.
+
+This is the IntersectionObserver-fade-in pattern, in 4 lines of CSS, with butter-smooth performance (browser-paint-thread, not main-thread JS).
+
+## Animation ranges in plain English
+
+| Range keyword | Means |
+|---|---|
+| `cover 0%` | the element first touches the viewport |
+| `entry 0%` | element starts entering the viewport |
+| `entry 100%` | element is fully inside the viewport |
+| `contain 0%` | element is fully inside (same as entry 100%) |
+| `contain 100%` | element starts to leave |
+| `exit 0%` | element starts leaving |
+| `exit 100%` | element is fully out of view |
+| `cover 100%` | element no longer touches the viewport |
+
+You can mix: `animation-range: entry 0% exit 100%` runs the animation from "first appears" to "fully gone" — full-trip parallax.
+
+## Horizontal scroller that animates as it scrolls
+
+```css
+.gallery {
+  display: flex;
+  overflow-x: scroll;
+  scroll-snap-type: x mandatory;
+}
+
+.gallery img {
+  scroll-snap-align: center;
+  animation: zoom-in linear;
+  animation-timeline: view(inline);
+  animation-range: contain 0% contain 100%;
+}
+
+@keyframes zoom-in {
+  0%, 100% { transform: scale(0.85); opacity: 0.6; }
+  50%      { transform: scale(1); opacity: 1; }
+}
+```
+
+`view(inline)` watches the inline (horizontal) axis. Each image scales up at center, scales down at edges. Pure scroll-driven, no JS sync.
+
+## Multiple animations sharing one timeline
+
+```css
+.section {
+  scroll-timeline: --section-trip block;
+}
+
+.section h2,
+.section .icon,
+.section p {
+  animation-timeline: --section-trip;
+  animation-range: entry 20% entry 80%;
+}
+
+.section h2  { animation: fade-in; animation-delay: 0%; }
+.section .icon { animation: fade-in; animation-delay: 10%; }
+.section p   { animation: fade-in; animation-delay: 20%; }
+```
+
+`scroll-timeline` on the section names a timeline. Children attach to it via `animation-timeline: --section-trip`. Stagger via `animation-delay` (interpreted as % of the timeline). Choreographed reveals without orchestration JavaScript.
+
+## Performance notes
+
+- Scroll-driven animations run on the **compositor** thread. Doesn't matter how heavy your JS main thread is — these animations stay smooth.
+- `animation-timeline: scroll()` is essentially free. The browser already tracks scroll position; you're just listening.
+- `view()` is slightly more work because the browser has to track each element's intersection — but still cheaper than `IntersectionObserver` callbacks.
+
+## Browser support (2026-05)
+
+[Caniuse](https://caniuse.com/css-scroll-driven-animations):
+
+- Chrome / Edge 115 (July 2023)
+- Safari: in flight, behind a flag
+- Firefox: not yet shipped
+
+For unsupported browsers, the animation falls back to its initial state (or you can set sensible static styles via `@supports not (animation-timeline: view())`). No breakage, just no scroll-trigger.
+
+```css
+@supports not (animation-timeline: view()) {
+  .card { opacity: 1; transform: none; }
+}
+```
+
+## When NOT to use it
+
+- **Animations that need to react to non-scroll events** — clicks, hover, network state. Stay with `transition` or JS.
+- **Triggering side-effects** (analytics events, lazy-load) on scroll. The animation doesn't tell JS anything happened. Keep `IntersectionObserver` for that side of the work.
+- **Scroll-jacking effects** (snap to next section). Different concept; use `scroll-snap-type` for that.
+
+## What this replaces
+
+- `IntersectionObserver` setups for fade-in-on-scroll → scroll-driven CSS
+- ScrollTrigger / parallax libraries for simple effects → scroll-driven CSS
+- Hand-rolled scroll listeners for reading-progress bars → 8 lines of CSS
+
+I rewrote a marketing page's parallax + reveal effects last week. -47 KB JavaScript, +12 lines of CSS, smoother on mobile because everything moved off the main thread.
+
+---
+
+Animations live in the [`transitions-animations`](/transitions-animations/0/) module on [Code Crispies](/) — interactive practice with live preview.
diff --git a/src/app.js b/src/app.js
@@ -62,6 +62,73 @@ document.addEventListener("securitypolicyviolation", (e) => {
 	}
 });
 
+// Web Vitals — bucket the value (avoid noisy umami events with raw ms).
+// Buckets follow Google's good/needs-improvement/poor thresholds so the
+// dashboard can report % of sessions in each bucket.
+function _webVitalBucket(name, value) {
+	const t = {
+		LCP: [2500, 4000],
+		INP: [200, 500],
+		CLS: [0.1, 0.25],
+		FCP: [1800, 3000],
+		TTFB: [800, 1800]
+	}[name];
+	if (!t) return "unknown";
+	if (value <= t[0]) return "good";
+	if (value <= t[1]) return "needs-improvement";
+	return "poor";
+}
+function _emitVital(name, value) {
+	track("web_vital", {
+		metric: name,
+		bucket: _webVitalBucket(name, value),
+		value: Math.round(value),
+		path: window.location.pathname
+	});
+}
+try {
+	// LCP — largest paint within the viewport. Last entry before user
+	// interaction wins.
+	new PerformanceObserver((list) => {
+		const entries = list.getEntries();
+		_emitVital("LCP", entries[entries.length - 1].renderTime || entries[entries.length - 1].loadTime || 0);
+	}).observe({ type: "largest-contentful-paint", buffered: true });
+
+	// CLS — sum of all unexpected layout shifts in a 1s window
+	let clsValue = 0;
+	new PerformanceObserver((list) => {
+		for (const entry of list.getEntries()) {
+			if (!entry.hadRecentInput) clsValue += entry.value;
+		}
+	}).observe({ type: "layout-shift", buffered: true });
+	addEventListener("visibilitychange", () => {
+		if (document.visibilityState === "hidden" && clsValue > 0) {
+			_emitVital("CLS", clsValue * 1000); // 0.05 → 50, fits int rounding
+		}
+	}, { once: true });
+
+	// INP — slowest interaction-to-next-paint observed
+	let worstINP = 0;
+	new PerformanceObserver((list) => {
+		for (const entry of list.getEntries()) {
+			if (entry.duration > worstINP) worstINP = entry.duration;
+		}
+	}).observe({ type: "event", buffered: true, durationThreshold: 16 });
+	addEventListener("visibilitychange", () => {
+		if (document.visibilityState === "hidden" && worstINP > 0) _emitVital("INP", worstINP);
+	}, { once: true });
+
+	// FCP + TTFB from the navigation entry
+	const nav = performance.getEntriesByType("navigation")[0];
+	if (nav) _emitVital("TTFB", nav.responseStart);
+	new PerformanceObserver((list) => {
+		const fcp = list.getEntries().find((e) => e.name === "first-contentful-paint");
+		if (fcp) _emitVital("FCP", fcp.startTime);
+	}).observe({ type: "paint", buffered: true });
+} catch {
+	// PerformanceObserver missing in old browsers — silent skip.
+}
+
 // Simplified state - LessonEngine now manages lesson state and progress
 const state = {
 	userSettings: {
