标签：#frontend

Priya was three paragraphs into rewriting a support ticket when the page flashed and her draft reverted to what it had looked like an hour earlier. She hadn't refreshed. Nobody had. The service worker had. It was running a cache-first strategy for ticket pages — fetch once, serve from cache after that, so the dashboard felt instant on a flaky connection. The intent was to cache /tickets/482 , the read-only view, and leave /tickets/482/edit alone, since an edit form is exactly the page you never want served stale. Here's the line that decided which was which: const isTicketView = /^ \/ tickets \/\d +/ . test ( pathname ); Spot it yet? Read it once more before you scroll. The missing character was $ /^\/tickets\/\d+/ anchors the start of the string — ^ — but never anchors the end. So it matches /tickets/482 . It also matches /tickets/482/edit , /tickets/482/history , and /tickets/482-anything-at-all , because "one or more digits after /tickets/ " is true of all of them. The regex was never wrong about what it checked. It just never checked enough. The one-character fix is obvious once you see it: const isTicketView = /^ \/ tickets \/\d +$/ . test ( pathname ); Ship that and you'll hit the next edge case within a week: a trailing slash ( /tickets/482/ ) now fails to match, because $ demands nothing comes after the digits — not even a slash. Add \/? before the $ and you've fixed that one. Then someone deep-links to /tickets/482?tab=history and the query string breaks the anchor again, because pathname on some code paths actually holds the full URL. Each fix is a patch on the last, and every patch is a chance to reintroduce the first bug in a new shape. This is the part nobody tells you about hand-rolled URL matching: it isn't hard because regex is hard. It's hard because "does this path match this shape" has a dozen boundary conditions, and a hand-written pattern only encodes the ones you happened to think of on the day you wrote it. The API built for exactly this job T

While working on a design system recently, I kept running into the same frustrating problem: I'd grab a color from Figma in HEX format, need it in HSL for a CSS variable, and end up bouncing between three different websites just to convert one value. Each site had its own UI quirks, some required JavaScript to be enabled, and none of them gave me a proper color scheme alongside the conversion. So I did what any reasonable developer would do — I built my own. Because apparently I enjoy reinventing wheels. The Problem With Existing Solutions The existing color converter tools online weren't bad, but they had a few issues that bugged me: They were slow — many loaded heavy JavaScript libraries just to do simple math They lacked context — I wanted to see complementary colors and schemes alongside the conversion They were ad-heavy — I don't want to dodge pop-ups while trying to match a shade of blue I wanted something that felt like a native tool: instant, offline-capable, and comprehensive. A single HTML file that I could open, use, and close without ceremony. The Architecture Decision The first decision was whether to use a library or write the conversion logic myself. Libraries like color (npm) are battle-tested, but they add weight. Since this is a browser-only tool with no build step, I decided to write the conversions in vanilla JavaScript. Here's the core conversion logic that handles the heavy lifting: function hslToRgb ( h , s , l ) { s /= 100 ; l /= 100 ; const k = n => ( n + h / 30 ) % 12 ; const a = s * Math . min ( l , 1 - l ); const f = n => l - a * Math . max ( - 1 , Math . min ( k ( n ) - 3 , Math . min ( 9 - k ( n ), 1 ))); return [ Math . round ( f ( 0 ) * 255 ), Math . round ( f ( 8 ) * 255 ), Math . round ( f ( 4 ) * 255 )]; } This is the most concise HSL-to-RGB conversion I know. It's a compact version of the standard formula that avoids the typical case-based approach. The math checks out for all edge cases, including grayscale (when s = 0 ). AI-Assi

The React state-management debate has produced more bad takes than any other frontend topic. "Just use Context." "Redux is dead." "Zustand for everything." "Jotai is the future." All four are partially right and partially dangerous, depending on what you're building. So instead of arguing, I built the same shopping cart — derived totals, async fetch, localStorage persistence, three subscribing components — in all four libraries , and benchmarked it. This is the condensed version; the full guide (all four implementations with real code, the complete matrix, and the decision flow) is on my site 👇 Full guide: https://prepstack.co.in/blog/react-state-management-context-redux-toolkit-zustand-jotai-comparison-guide The one benchmark that reframes everything 1,000 components subscribed to one store. Update one value. How many re-render? Library Components re-rendered Wall-clock Context (single value) 1,000 (all) 42 ms Context (split into 5) ~200 12 ms Redux Toolkit (selectors) 1 2.1 ms Zustand (selector) 1 1.8 ms Jotai (atom) 1 1.5 ms Context without splitting re-renders the world. The other three are within margin of each other — meaning the real differences are boilerplate and DX , not render speed. The four, in one line each Context API — built-in, 0 KB, but every consumer re-renders on any change. Right for theme/auth/locale; wrong for anything busy or with many subscribers. Redux Toolkit — ~22 KB, most boilerplate, but RTK Query (caching, dedupe, invalidation), middleware, and time-travel DevTools are best-in-class. Payoff scales with app complexity. Zustand — ~3 KB, no provider, selectors built in, a full store (state + async + persistence) in ~25 lines. The modern default for most 2026 apps. Jotai — state is many small atoms, each with its own subscriber list. Smallest blast radius per update; ideal for forms and derived graphs. Real production migration (same e-commerce app) Metric Context-everywhere Redux Toolkit Zustand Initial JS (gzipped) 412 KB 438 KB 390 KB A

A teammate opened a PR titled "fix hero heading on small screens." The diff added a media query. Mine, reviewing it, found four more already in that file — one per breakpoint, added over eighteen months by four different people, each one patching the width the last person didn't think of: .hero-heading { font-size : 3rem ; } @media ( max-width : 1200px ) { .hero-heading { font-size : 2.5rem ; } } @media ( max-width : 992px ) { .hero-heading { font-size : 2.25rem ; } } @media ( max-width : 768px ) { .hero-heading { font-size : 1.75rem ; } } @media ( max-width : 480px ) { .hero-heading { font-size : 1.5rem ; } } Five rules to make one number — the font size of one heading — track the width of the screen it's on. And it still didn't work everywhere: resize the window to 850px and the heading is stuck at the 992px value, a little too big for the space it actually has. Every gap between breakpoints is a size nobody chose, it's just whatever the nearest rule left behind. Here's the part that stings: none of this has been necessary since 2020. The fix that isn't a breakpoint at all clamp() takes three values — a minimum, a preferred value, and a maximum — and returns whichever one the situation calls for: .hero-heading { font-size : clamp ( 1.5rem , 1rem + 2vw , 3rem ); } Read it as a sentence: never smaller than 1.5rem, never bigger than 3rem, and in between, scale with the viewport. The five media queries above collapse into that one line — and unlike them, it doesn't have gaps. clamp() recalculates the size continuously, every pixel the viewport moves, so there's no "850px value" that got left behind. It's a formula, not a lookup table. The middle value is where the "preferred" size lives, and it's 1rem + 2vw — a fixed part plus a viewport-relative part — not just 4vw on its own. That's not decoration. It's the one part of this pattern worth getting right, because the shortcut version quietly breaks something. The version that looks fine and isn't The formula you'll see

The bug ticket said "carousel feels broken on trackpad." It took me forty minutes to find the actual...

The Quest Begins (The "Why") I still remember the first time I tried to add login to a side‑project. I’d read a tutorial that said “just store a token in localStorage and you’re good,” slapped together a few fetch calls, and called it a day. A week later I got an email from a user: “Hey, I can’t log out, and someone else seems to be using my account.” My heart sank. I realized I’d bolted a flashy lock onto a screen door — it looked secure, but anyone with a screwdriver could walk right in. That moment kicked off a deep dive. I wanted to understand the trade‑offs between sessions , JSON Web Tokens (JWT) , and OAuth so I could pick the right tool for each job, not just the shiniest one. What followed felt like assembling a superhero squad: each member has a unique power, and knowing when to call on them makes the difference between saving the day and causing collateral damage. The Revelation (The Insight) Sessions – The Trusty Sidekick Sessions are the classic, server‑side approach. When a user logs in, the server creates a random identifier (the session ID), stores it in a database or cache (Redis, Memcached, etc.), and sends it back to the browser as an HttpOnly cookie. On every request, the browser automatically includes that cookie, the server looks up the ID, and pulls the associated user data. Why I love it: The secret never leaves the server, so stealing a cookie only gives an attacker a session ID that’s useless without the server’s store. Revoking a session is trivial — just delete the row from the store. Works great for traditional web apps where you control both front‑ and back‑end. Where it stumbles: Horizontal scaling requires a shared session store; otherwise each instance forgets who the user is. Every request does a database/lookup, which can add latency if the store isn’t fast enough. JWT – The Lone Wolf with a Signed Badge A JWT is a compact, URL‑safe string that contains claims (like sub , exp , roles ) and is cryptographically signed (HMAC or RSA).

A browser preview can look correct while the downloaded image is wrong. The usual failure is timing: CSS eventually applies the custom font to the preview, but Canvas draws once. If the font is not ready at that exact moment, fillText() can silently use a fallback face. The user sees one design and downloads another. I ran into this while building GraffForge, a browser-based graffiti text tool. The free editor compares the same user-entered word across multiple bundled styles, then exports the selected result as a transparent 2048 × 2048 PNG. That gave the export path a clear contract: preserve the exact text; use the selected font; keep spacing, outline, shadow, and skew; fit inside a safe area; preserve real transparency; never upload the user's text or image. Here is the approach that made the output deterministic. 1. Treat export as a separate rendering target Do not enlarge the preview DOM and take a screenshot. Create a fresh Canvas with explicit bitmap dimensions: const EXPORT_SIZE = 2048 ; const canvas = document . createElement ( ' canvas ' ); canvas . width = EXPORT_SIZE ; canvas . height = EXPORT_SIZE ; const context = canvas . getContext ( ' 2d ' ); if ( ! context ) { throw new Error ( ' Canvas rendering is unavailable. ' ); } The width and height attributes define the actual PNG pixel dimensions. CSS sizing and devicePixelRatio are useful for an on-screen preview, but neither should determine the export contract. A fixed bitmap size also makes automated verification straightforward. 2. Load the font before measuring anything Canvas does not redraw automatically when a font finishes loading. Load the exact family, weight, size, and text before calling measureText() : await document . fonts . load ( `400 160px " ${ fontFamily } "` , text ); Passing the actual text is useful because the browser can confirm that the required glyphs are available. After this point, set the Canvas font explicitly: context . font = `400 ${ fontSize } px " ${ fontFamily } "` ;

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built Warm Hearth — a landing page for a comfort food restaurant built around one idea: everything on the menu comes from the same wood-fired hearth in the back. Instead of treating "comfort food restaurant" as a generic brief, I anchored the whole page to that single hearth: An interactive hearth centerpiece. Right after the hero, there's a hand-drawn CSS/SVG fire pit you can click to "stoke." The flame flares, embers burst upward, and a small honest counter tracks how many times you've stoked it this visit — no fake global numbers, just a real, session-based response to your click. Four dishes, each with real cultural identity. Ramen, warm pies, a cheesy pasta bake, and gulab jamun — each with its own hand-drawn SVG illustration and a border motif pulled from its own cuisine (a jade-and-gold double line for the ramen, a scalloped pastry edge for the pies, an Italian tricolor accent for the pasta, gold paisley tones for the gulab jamun) rather than one generic card style stretched across all four. Living detail, not static photos. Steam rises off the ramen, pies, and pasta bake using the same wisp animation as the hero's hearth, so the whole page reads as one consistent "warmth" language. The gulab jamun gets a syrup shimmer and drip instead, since steam isn't the right detail for a syrup-soaked sweet. Price tags that hang like real kitchen tickets — pinned by a string, swaying gently, and giving a small "flicked" swing on hover instead of sitting flat on the card. Mira, an illustrated host in the corner who offers a rotating table tip when you click her — a small personal touch instead of a static "contact us" widget. Built for actual use, not just to look good in a screenshot: keyboard-focusable tab filters, a skip-to-content link, aria-live regions on the interactive parts, and full prefers-reduced-motion support that disables every animation without breaking the page. Dem

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built I created Balan Coffee & Roastery , a polished landing page for a fictional Vietnamese comfort café in Saigon. The concept is inspired by the quiet comfort of slow phin coffee, butter toast, and small sweet treats. Rather than treating coffee as a quick purchase, I wanted the site to feel like a calm daily ritual: slow, warm, familiar, and personal. Visitors can explore the menu, learn the café story, find visiting information, and interact with a small pixel-art coffee brewing experience. Highlights: Responsive editorial-style coffee shop landing page Vietnamese coffee-inspired menu, story, ritual, and visit sections Clear navigation and accessible interactive controls Consistent number and price typography throughout the site A lightweight interactive mini-game: Pixel Phin Brew Dose beans into the phin Grind the beans Bloom the coffee Let the phin drip Serve the finished cup Built without heavy UI, game, or animation libraries Demo Live demo: Balan Coffee & Roastery Source code: GitHub repository Journey I wanted to create something that felt more like a coffee ritual than a typical restaurant landing page. The visual direction uses warm cream tones, deep coffee browns, generous spacing, subtle texture, and an editorial layout inspired by a slow morning at a Saigon café. I paid attention to small details such as consistent tabular numerals for prices and opening hours, responsive layouts, visible interaction states, and reduced-motion support. The feature I enjoyed building most was Pixel Phin Brew . I wanted the interaction to be understandable instead of just decorative, so each button clearly explains the next brewing action. Every correct step updates the pixel scene, progress indicator, and feedback message until the final cup is served. The project was built with React, TypeScript, Vinext/Vite, and custom CSS. I kept the implementation lightweight and avoided add

If you've been developing WordPress websites for several years, there's a good chance you've spent a lot of time working with files like: header.php footer.php single.php page.php archive.php functions.php That's certainly where most of my WordPress development experience has been. But WordPress has been changing. With the Block Editor, Site Editor, block themes, patterns, and theme.json , WordPress now offers a very different approach to theme development. So I decided to take a closer look at the question: If you're already comfortable building classic WordPress themes, is it worth moving toward block themes in 2026? This isn't an article written from the perspective of someone who has spent years exclusively building block themes. Most of my own WordPress work has traditionally involved classic themes . Instead, I'm looking at block themes from the perspective of an experienced WordPress developer who is exploring how the platform is evolving—and where the newer approach fits alongside the architecture I've used extensively. Classic Themes vs Block Themes WordPress currently identifies two primary theme types: Classic themes Block themes According to the official WordPress Theme Developer Handbook, classic themes primarily use PHP, JavaScript, and CSS and can make extensive use of WordPress functions, hooks, and filters. Block themes, on the other hand, are built around block markup and HTML-based templates and allow users to edit more areas of the website through the Site Editor. A simplified comparison looks like this: Classic Theme Block Theme PHP templates HTML block templates single.php templates/single.html header.php parts/header.html footer.php parts/footer.html Template hierarchy Block-based templates Custom PHP logic Blocks + APIs + plugins Customizer / theme options Site Editor / Styles theme.json optional theme.json commonly used This doesn't mean classic themes are obsolete. They aren't. WordPress continues to maintain documentation for classic theme

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . Inspiration My other two entries were about a moment and a ritual. This one is about the opposite: the dish you fall back on when you have no skill, no energy and no plan. Boiled eggs are what you make when you cannot cook. Six minutes, one pan,and the comfort is precisely that it is not possible to get it wrong . Two choices made it worth drawing rather than just worth eating. A glass bowl, so you can see the boil. In a steel pan the interesting half of this is hidden. Glass also turned out to be the exact opposite problem to the terracotta in my chai piece — unglazed clay is matte and forgives a sloppy gradient, glass shows you every single one. An induction hob, for the light. I finished the fridge piece saying the one piece of advice I'd give is pick a scene with a light source in it . So I did it again on purpose. The element ring is the only warm thing in an otherwise cold grey kitchen, and it lights the water from underneath. Everything here is a div , a gradient or a shadow. No SVG, no images, no canvas. Demo Press Turn off the heat and give it a few seconds. The ring dies back, the bubbles thin out, and the eggs slowly stop moving — then put it back on and watch the pan come to the boil in stages. That build-up is the part I'd most like you to see, and it's the whole subject of this post. Journey Nothing in this picture is transparent The obvious way to draw a glass bowl is backdrop-filter . I'd advise against building a picture on it — support is uneven enough that the piece falls apart somewhere, and it's expensive. So the transparency is painted. The water is drawn first as its own element, and then a front wall of highlights sits over the top of it: two vertical speculars down the sides for the curve of the glass, a soft wash across the middle for the thickness of the pane, and a rolled lip at the top, which is the one place glass is genuinely opaque enough to draw as a solid.

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What...

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built This is a blast from the past, but it's so lovely I couldn't resist submitting it for this challenge. Kitchen-Sune is a community-driven international recipe book built in collaboration with Front-End Foxes members when we pivoted our nonprofit's efforts from in-person workshops to an international online boot camp during the pandemic. It brings together comfort food recipes from around the globe into a sleek, accessible, and user-friendly Vuepress web application where food lovers and developers alike can discover new dishes. We were happy to host recipes from Ukraine, Kenya, Nigeria, and everywhere in between. Between Jalebi Babies, Moin-Moin, Puff Puff, and Strawberry Mush, we've got you covered for comfort food! Demo Live Demo: Kitchen-Sune App GitHub Repo: https://github.com/FrontEndFoxes/kitchen-sune Check out a preview of the recipe book (this recipe for maple syrup candy came with a video): Journey Revisiting and showcasing this project was a nostalgic process. Working on a community recipe project taught me the importance of building inclusive, easy-to-navigate web interfaces for diverse content as an educatioal tool. We used to use this repo as a way to train boot camp enrollees in how to use GitHub and make a PR to a repo. What I Learned: No matter where we are in our journey, food brings us together. What I'm Proud Of: How timeless and clean the aesthetic remains, making it easy for anyone to find a warm, cozy meal to cook or a snack to throw together (Pandemic Cookies, anyone?). What's Next: Let's keep going! Add your recipe via a PR to the GitHub repo. And I'd love to have more photos to show off your work.

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built For the Perfect Landing prompt, I built Masala Dosa House , a warm and modern landing page inspired by one of my favorite comfort foods — South Indian Masala Dosa . 🇮🇳 The idea was to create a fictional restaurant website that feels like stepping into a familiar neighborhood dosa spot. The landing page focuses on: 🍽️ Hero section featuring Masala Dosa 🥞 Signature dishes 🥥 Chutneys and sambar 🌿 Traditional South Indian food experience ❤️ A warm, welcoming visual design 📱 Responsive layout for desktop and mobile ✨ Smooth interactions and animations 🎨 Food-inspired colors, typography, and visual elements 📍 Restaurant-style call-to-action sections Rather than creating a generic restaurant landing page, I wanted the entire experience to communicate the feeling behind comfort food — warmth, familiarity, and home . Demo 🍽️ Live Project: Masala Dosa House — A Taste of Home View the Masala Dosa House project on CodePen Journey I started by thinking about what makes a food website feel different from a regular landing page. For me, comfort food isn't only about the food itself. It's about the experience around it — the aroma, the warmth, the familiar presentation, and the feeling of sitting down for a meal that you already know you'll enjoy. That became the design direction for Masala Dosa House . I used a warm visual palette inspired by dosa, banana leaves, spices, chutneys, and traditional South Indian dining. The layout was designed to keep the food as the main focus while making the page easy to navigate. Building the experience I structured the landing page around a simple restaurant journey: Discover → Explore → Choose → Visit The hero section introduces the restaurant and immediately establishes the comfort-food theme. The menu section highlights signature dishes, while supporting sections provide more context about the restaurant and its food. I also focused on making the

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . Inspiration For my CSS Art submission, I wanted to create something that represents comfort food from South India — Masala Dosa . 🇮🇳 A crispy, golden dosa served with potato masala, coconut chutney, tomato chutney, and a warm bowl of sambar is more than just a meal. It's one of those dishes that immediately feels familiar and comforting. I decided to recreate the entire plate using HTML and CSS , without using food images or external graphics. The goal was to turn a simple plate of masala dosa into a small CSS illustration while keeping the focus on CSS techniques such as: CSS gradients Radial and repeating gradients Border-radius based shapes Box shadows Pseudo-elements CSS animations Responsive layouts Layering and positioning The project is called "CSS Masala Dosa — A Plate of Comfort" . Demo 🍽️ Live CodePen Project: CSS Masala Dosa — A Plate of Comfort View the CSS Masala Dosa project on CodePen Journey I started with the idea of creating a single plate entirely from CSS . Instead of using an image for the dosa, I built the main shape using layered gradients and rounded shapes. The different colors and textures help create the crispy, golden appearance of the dosa. Then I added the individual elements of the meal: 🥞 Masala Dosa — built using multiple gradients, shadows, and layered shapes. 🥔 Potato Masala — represented using small CSS shapes for potato pieces, onions, and curry leaves. 🥥 Coconut Chutney — created using a circular CSS shape with subtle texture details. 🌶️ Tomato Chutney — another CSS-only circular element with layered gradients. 🥣 Sambar — built as a small bowl using nested circular elements and gradients. 🌿 Banana Leaf — created with gradients, shadows, and a CSS vein to give it a natural appearance. ♨️ Steam — animated using CSS @keyframes to give the dosa a freshly-served feeling. One of the things I particularly enjoyed was creating the food textures without images

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built Karachi Ki Raatein ("Karachi's Nights") — a single-page love letter to the street food that keeps my city awake after dark. Instead of a restaurant or a recipe box, I built it around a real pattern from home: Karachi basically runs on an unofficial food schedule. Maghrib means chai and something fried. Bun kabab happens standing up, mid-errand. Nihari is what you sit down for after Isha. Seekh kabab shows up wherever there's smoke. And halwa puri at 3am is for the people who never went to sleep in the first place. The whole page is built around that rhythm instead of a menu. A few things I'm happy with on the frontend side: A signboard hero with a flickering neon-style headline and hand-drawn CSS/SVG steam rising from a cup — no stock photography anywhere on the page, everything is drawn. A canvas-based particle steam system that replaces the static SVG once JS is available — real particles with drift, turbulence and upward acceleration, and they physically scatter when you move your cursor through them, like waving your hand through actual steam. A live "Night Clock" that reads your real local time ( Date , your timezone, nothing hardcoded) and marks whichever stall is "in season" right now with a pulsing "you are here" badge — so the page behaves differently depending on when you actually open it. A theme built for the medium : dark ink background, ember/turmeric accent colors, a hand-lettered chalk font for the "voice" of the thela-wala mixed with a bold display face for the signage, instead of the usual cream-and-terracotta food-site look. Respects prefers-reduced-motion everywhere (falls back to a static SVG steam loop and skips the canvas sim), keyboard-focusable throughout, fully responsive. Demo Journey I wanted to avoid the obvious comfort-food landing page — cream background, terracotta accents, a hero photo of a steaming bowl. It's a solid look but I see it ev

If you've only ever shipped linear-gradient(to right, blue, red) , you're using about one-third of what CSS gradients can do. There are only three functions, and the mental model for each is small. Here's the whole thing in one read. The one fact that makes everything click A gradient is not an image file. Per MDN , a <gradient> is a special kind of <image> that the browser generates at render time . So it: scales to any size without blurring (it's drawn, not sampled) weighs zero bytes (no file, no HTTP request) edits with one hex value instead of a re-export That's why gradients exist. Everything below is just how to steer them. Three functions, three shapes Function Shape Reach for it when linear-gradient() straight line along an axis backgrounds, buttons, overlays radial-gradient() outward from a center point spotlights, glows, vignettes conic-gradient() rotational sweep around a center pie charts, color wheels, spinners Linear - the workhorse background : linear-gradient ( to right , #ff7e5f , #feb47b ); /* orange→peach */ background : linear-gradient ( 135 deg , #6366 f1 0 %, #ec4899 100 %); /* indigo→pink */ Direction is an angle ( 45deg ) or a keyword ( to right , to top right ). Stops are a color plus an optional position. Radial - when the fade should read as light background : radial-gradient ( circle , #fff , #000 ); Shape ( circle vs ellipse ), center position, and sizing keywords ( closest-side , farthest-corner ) do the work. Because the fade tracks distance from a point, radial reads as depth - perfect for glows, vignettes, and spotlight effects. Conic - the one most people skip background : conic-gradient ( #f00 0 25 %, #0 f0 25 % 50 %, #00 f 50 % 75 %, #ff0 75 %); Conic sweeps by angle , not distance. That single difference makes it the right tool for pie charts and color wheels - effects that were hacky before conic-gradient() shipped. The rule that surprises everyone Two color stops at the same position don't fade - they make a hard edge: backgrou

Every glassmorphism snippet I've seen is backdrop-filter: blur() plus a white overlay. That's a blurred rectangle. Real glass bends what's behind it, hardest at the edge — and that part is missing everywhere. Built it for a production Angular app, pulled it out as a Claude Code plugin: https://github.com/stormaref/LiquidGlassSkill /plugin marketplace add stormaref/LiquidGlassSkill /plugin install liquid-glass@stormaref-skills The refraction: bake a displacement map into a canvas, wire up feImage → feDisplacementMap → feGaussianBlur , point the element at it with backdrop-filter: url(#filter) . Since it's a backdrop filter, the input is the live page behind the element — so it tracks scroll, theme and content changes with nothing to invalidate. Field ported from liquid-glass-js (MIT, credited), minus its html2canvas snapshot. Why it's a skill and not a gist — four rules, each of which fails as plausible-looking output: Glass needs a backdrop. Over a flat page it reads as a gray box, which sends you reaching for more blur — the exact move that kills it. The tint is colorless. Hue in the tint fights the hue coming through; the surface goes muddy. Children of a glass panel paint no surface. An opaque fill covers the refracted backdrop, which is the whole effect. You can't feature-query it. Safari parses backdrop-filter: url(#…) and paints nothing, so @supports says yes and your panel is blank. Gate on engine. The CSS is 200 lines. Knowing that #1 is why your glass looks nths of things looking subtly wrong. MIT. Happy to talk displacement math — the 128/255 ≠ 0.5 decly long to find.

This is a submission for Frontend Challenge - Comfort Food Edition Perfect Landing. What I...

A user reports that they keep getting logged out. Not immediately — after a while, randomly, always...