标签：#css

If you're starting a web project, you're probably starting with a CSS reset, and for most of us, that means reaching for a trusted community solution - dropping it in and moving on. If you're building a design system, though, that habit may be working against you. The existing solutions The community reset ecosystem is genuinely good. Each tool approaches the browser compatibility problem from a slightly different angle. Some examples include: Eric Meyer's Reset is a classic: it zeros out margins, padding, and font sizes across every element, giving you a completely blank slate. It's minimal and predictable, which made it influential. Normalize.css smooths over inconsistencies while preserving the ones that are actually useful. sanitize.css and modern-normalize continue that evolution - incorporating contemporary best practices like box-sizing: border-box , improved form element handling, and accessibility-aware defaults. The problem isn't that any of these are bad. The problem is that they're all deliberately, necessarily generic. They can't know anything about your typeface, your color palette, your spacing scale, or how your interactive elements should behave. That's by design - they're tools for everyone, which means they're perfectly tailored for no one. The problem If you're building a design system, generic is exactly what you don't want your reset to be. The moment you drop in one of these resets and start building, you find yourself doing a second round of work. You apply your typeface to body . You reset margins on headings. You make form elements inherit fonts. You define focus styles. You're re-resetting - applying your design language on top of a layer that just cleared out the browser's defaults and replaced them with... more defaults you'll override. Worse, that duplication doesn't stay in one place. Every component you build either re-declares these foundational styles or silently assumes they're already set upstream. You end up with either redundanc

Comparing the most feature-rich React data grids in 2026, from pivot tables and tree data to...

Originally published on danholloran.me The original Grimicorn was an exercise in restraint: muted pastels on a blue-gray base, tuned so nothing on screen ever burns your eyes. Grimicorn Neon is the opposite impulse. Same grim-reaper-meets-unicorn idea, except this one is plugged into the mains — saturated, glowing accents on a near-black base, dark-only, loud on purpose. What makes the pair interesting from an engineering angle is how little had to change to get there. Neon is not a new theme so much as the same theme with the volume knob turned all the way up. That only works because of a decision made back in the calm version: colors are defined by role, not by appearance. Eight roles, eight louder hexes Both themes share the exact same role map. Blue is keywords, links, and the primary accent. Green is strings, success, and the cursor. Yellow is types, decorators, and warnings. The accent hierarchy is still blue → purple → teal, and the semantic anchors still hold: green means good, the error color means wrong. What changes is only the values bound to those roles. Calm Grimicorn's blue is a soft #83AFE5 ; Neon's is an electric #2323FF . Calm green is a sage #A9CE93 ; Neon green is an acid #A3E635 . The error role even swaps identity, from a gentle salmon to a hot #FF2D9B pink. Lay the two palettes side by side and the structure is identical — only the saturation and brightness move: // same eight roles, two personalities const calm = { blue : " #83AFE5 " , green : " #A9CE93 " , error : " #DD9787 " , base : " #253039 " , }; const neon = { blue : " #2323FF " , green : " #A3E635 " , error : " #FF2D9B " , base : " #0A0A0B " , }; Because every one of the fourteen tool ports — VS Code, Ghostty, Obsidian, Claude Code, JetBrains, tmux, and the rest — is generated from a single palette.md , producing the neon set was mostly a matter of feeding the build a different eight values. The emitters that translate roles into VS Code scopes or ANSI slots never knew the difference.

Why Semantic HTML is a Superpower for Your Website As I’ve been building my personal portfolio during the IYF Season 11 program, I realized that writing code is about more than just making things look "right"—it’s about making them accessible for everyone. The secret is Semantic HTML. What is Semantic HTML? Semantic HTML uses tags that provide meaning to the web page rather than just layout instructions. Tags like , , , , and tell the browser and screen readers exactly what content they are interacting with. If you use for everything, you are handing a screen reader a blank map. Semantic tags act like a GPS, allowing users with visual impairments to navigate your site efficiently. Before vs. After The difference is clear when comparing structure: Before (Non-Semantic): HTML My Portfolio Home | About | Contact Welcome to my site... After (Semantic): HTML My Portfolio Home About Contact Welcome to my site... Fixing Accessibility Issues During my accessibility audit (Task 2.3), I identified three key areas to improve: Missing alt Attributes: I had images without descriptions. I fixed this by adding context, such as alt="Portrait of Gladwell Muthoni, web development student", ensuring screen readers can describe images to visually impaired users. Lack of Semantic Structure: My initial gallery relied on generic containers. Switching to and tags organized my project list logically, helping assistive technology categorize the content. Heading Hierarchy: I was using tags for visual styling rather than logical structure. I corrected this to follow a strict to hierarchy, which helps screen readers outline the page properly. My portfolios URL https://github.com/gladwellmuthoni/iyf-s11-week-01-gladwellmuthoni.git

Let's be honest — standard GitHub profiles are a bit... static. As a Full Stack Developer & AI/ML Specialist, I wanted a way to showcase my contributions that actually felt alive. I didn't just want a grid of green squares; I wanted a universe. So, I built GitPulse. What is GitPulse? GitPulse is a cinematic, interactive web application that transforms standard GitHub profiles and repository logs into glowing, animated contribution universes. Instead of just seeing numbers, you experience your code history visually. The Tech Stack I wanted this to feel premium, fast, and visually stunning without relying on heavy frontend frameworks if I didn't need to. Canvas API & GSAP: For buttery-smooth micro-animations and physics. Glassmorphism UI: Using CSS backdrop-filters to create a modern, deep aesthetic. Vanilla JavaScript: Keeping the core logic incredibly fast and lightweight. The "Stellar Duel" Feature One of the coolest features I added was the Stellar Duel mode. I thought: What if you could compare your GitHub activity with a friend, but instead of a boring chart, it looked like a sci-fi dashboard? Stellar Duel Using the GitHub API, GitPulse fetches the data and renders a live, side-by-side visual duel of your commit history, stars, and PRs. It’s highly interactive and honestly, just really fun to look at. The Biggest Challenge: Performance Rendering thousands of data points (commits) visually on a canvas can crash a browser if you aren't careful. To solve this, I had to heavily optimize the animation loop. Instead of manipulating the DOM for every star/commit node, I used HTML5 Canvas to batch render the visual elements. I also implemented requestAnimationFrame properly to ensure the animations pause when the user switches tabs, saving CPU cycles. See it in Action I've integrated GitPulse directly into my main portfolio. You can try it live here: GitPulse Live Demo And if you want to see more of the projects I build (especially in the AI/ML and Computer Vision space

— โคลงสี่สุภาพ ว่าด้วยสามภาษาแห่งการสร้างเว็บ — HTML — โครงสร้าง <html> เปิดทางฟ้า ประกาศ <head> ซ่อนนัยน์นาถ นามนี้ <body> ร่างกายปราศ ซึ่งชีวิต ทุกแท็กเปิดปิดที่ หล่อหล่อมความจริง CSS — ความงาม สีสันลอยลิบฟ้า แต่งแต้ม ตัวอักษรเรียงแถม ถ้วนถี่ ขอบเขตเว้นระยะแย้ม เผยโฉม ทุกพิกเซลที่ปรี่ ปรุงแต่งให้งาม JavaScript — ชีวิต เมื่อคลิกนิ้วหนึ่งครั้ง โลดแล่น ฟังก์ชันทำงานแย้ม ยามใช้ if else ตรรกะแจ่ม จักรกล ทุกบรรทัดที่ให้ ชีวิตแก่หน้าเว็บ สามภาษา — หนึ่งเดียว html คือร่างให้ โครงครัน css แต่งแต้มฝัน สวยหรู javascript พลิกผัน ให้เคลื่อนไหว สามภาษาคู่ฟู ฟื้นฟูโลกา — Nokka | มิถุนายน 2569 เชิงอรรถ: โคลงสี่สุภาพบทนี้ใช้ฉันทลักษณ์มาตรฐาน — บทละ 4 บาท บาทละ 2 วรรค วรรคหน้า 5 พยางค์ วรรคหลัง 2 พยางค์ สัมผัสบังคับระหว่างวรรคท้ายของบาทที่ 1, 2, 3 กับวรรคแรกของบาทถัดไป เนื้อหากล่าวถึงสามเทคโนโลยีหลักของการพัฒนาเว็บไซต์ในฐานะ "กาย — ใจ — วิญญาณ" ของทุกหน้าเว็บ

getComputedStyle(element).fontFamily returns the CSS declaration: "Hiragino Kaku Gothic ProN", "Yu Gothic", "Noto Sans JP", sans-serif . That's not the font that rendered. It's a priority list. The browser picks the first one that's available and contains a glyph for the character being rendered. For Latin text, this distinction usually doesn't matter — Windows, macOS, and Linux have converged on a small set of common system fonts. For Japanese, it matters enormously. The visual weight, stroke contrast, and letterform style of Hiragino, Yu Gothic, and Noto Sans JP are genuinely different. A site designed on macOS (where Hiragino is the system Japanese font) looks different on Windows (where Yu Gothic is the fallback). Here's how to figure out what's actually rendering, and what I learned building Japanese Font Finder to automate it. Why getComputedStyle Doesn't Answer the Question getComputedStyle(el).fontFamily gives you the cascade result — what the browser received after applying all CSS rules. But it doesn't tell you which entry in the stack was selected. The underlying question is: does this font exist on this system, and does it have a glyph for this specific character? For Japanese, both conditions matter. A font might exist on the system but only cover a subset of kanji (common with CJK fonts that split across multiple files). The browser will use that font for characters it covers, and fall back for others. Canvas-Based Font Detection The classical technique uses a <canvas> element to measure text rendered with each font in the stack: function getFallbackWidth ( canvas , char ) { const ctx = canvas . getContext ( ' 2d ' ); ctx . font = `16px monospace` ; // known-available baseline return ctx . measureText ( char ). width ; } function testFont ( fontName , char ) { const canvas = document . createElement ( ' canvas ' ); const ctx = canvas . getContext ( ' 2d ' ); ctx . font = `16px " ${ fontName } ", monospace` ; return ctx . measureText ( char ). width ; }

Instagram/WhatsApp Stories have a signature UI: those segmented bars across the top, one filling at a time. It looks fancy but it's a simple pattern. Here's a live, tappable rebuild in vanilla JS + CSS. 📸 Try it (tap left/right, hold to pause): https://dev48v.infy.uk/design/day17-instagram-stories.html The segmented bar One bar per story. The rule: only the active segment animates its width 0→100%; segments before it are full, segments after are empty. When the active one completes, advance to the next and reset the rule. Driving the fill A single requestAnimationFrame loop tracks elapsed time vs the per-story duration (~4s) and sets the active bar's width. On completion → next story. The interactions that sell it Tap the right half = next, left half = previous (split the screen into two zones). Press-and-hold = pause ( pointerdown pauses the timer, pointerup resumes) — so users can actually read. Reset past/future segment states whenever you jump. Why rAF over CSS animation A timer loop makes pause/resume and tap-to-skip trivial — you control the clock. Pure CSS animations are harder to interrupt mid-fill. 🔨 Full build (segments → animate active → advance → tap zones → hold-to-pause) on the page: https://dev48v.infy.uk/design/day17-instagram-stories.html Part of DesignFromZero. 🌐 https://dev48v.infy.uk

Picking colors is the fun part. Wiring them into a codebase that stays maintainable is where most palettes fall apart. Here's the approach I use. 1. Name colors by role, not value Don't scatter hex codes everywhere: css .button { background: #6366f1; } .link { color: #6366f1; } Define them once as custom properties, referenced by role: :root { --color-bg: #f7f7f8; --color-surface: #ffffff; --color-text: #1f2937; --color-muted: #9ca3af; --color-accent: #6366f1; } .button { background: var(--color-accent); } .link { color: var(--color-accent); } Now re-theming the whole app is a few edits in one place. 2. Skip pure black and pure white #000 on #fff feels harsh on screens. Pull both back: --color-text: #1f2937; /* near-black */ --color-bg: #f7f7f8; /* off-white */ Most layouts instantly look more intentional. 3. Dark mode is almost free Because the colors are role-based variables, you just override the values: @media (prefers-color-scheme: dark) { :root { --color-bg: #0f1115; --color-surface: #1a1d24; --color-text: #e5e7eb; } } Every component using var(--color-bg) adapts automatically. A shortcut I got tired of hand-converting palettes into this, so I built a free tool, PaletteCSS, that copies any palette straight out as CSS variables, Tailwind or SCSS — and has a color palette generator if you need a starting point. But honestly, the three rules above matter more than any tool. What conventions do you use to keep a color system maintainable? PaletteCSS — a free tool to discover, create and share color palettes and CSS gradients. Copy any palette as hex, CSS variables, Tailwind or SCSS. No signup. https://palettecss.com**

Note : This article is one of a series demonstrating building a React navigational component from scratch while considering accessibility through the process. The articles are accompanied by a GitHub repository with releases tied to one or more articles; each builds on the previous one until a fully implemented navigation component is complete. Each release and its associated tag contain fully runnable code for the article. The code discussed in this article is available in the release. and may be downloaded at release 0.9.0 . A page showcasing these base components may be run locally through this release. While code examples are written in JavaScript for brevity, all actual code is written in Typescript and targets React 19.x, all while using vanilla CSS. Examples use Next.js v16.x, which is not required to run the navigation component.] The design requirements for this release are available . -— Content Links Introduction Layout Appearance <nav / > Generic Styling Reimagining Focus and Hover Achieving Parity aria-current Refinements Summary Introduction With only one more release coming up and the horizontal layout styling complete, now is the time to focus on completing vertical layout styling. Most of the layout itself was completed in an earlier release and described in the article Laying it all out on the vertical . When styling a component, care must be taken to ensure parity with the information provided by screen readers through some aria attributes. For instance, a navigation component must set the aria-current="page" attribute on a link whose href points to the current page. In the example being shown, the link in question is the "by Era" link, under Find Your Next Story and Tales. ) While screen reader users hear which button or link is the item currently capturing focus, styling is needed to achieve the same for screen users. Visual styling is necessary to guarantee that visual and auditory/tactile users have the same information. Layout @layer system-c

As a systems engineering student and frontend dev, I wanted a portfolio that looked professional without spending days fighting with design. So I built one — and ended up turning it into a reusable template. Here's what I focused on while building it: 1. Customization from a single file The biggest pain with most templates is digging through components to change your info. I put everything — name, bio, projects, skills, social links — into ONE config file. Edit that, and the whole site updates. 2. Light & dark mode Developers love dark mode, so I made it the default, with a smooth toggle for light mode. Both are fully themed. 3. Mobile-first & responsive Most people will view a portfolio on their phone, so I built it mobile-first and tested it down to small screens. 4. Easy deployment It works out of the box with Vercel or any static host, with a beginner-friendly setup guide in the README. The stack React + Vite Tailwind CSS Formspree-ready contact form You can see the live demo here: devfolio-template-vercel-app.vercel.app I also made it available as a template if it's useful to anyone: https://payhip.com/b/t1VUk Would love to hear your feedback — what do you look for in a developer portfolio? react #webdev #tailwindcss #showdev

The Tailwind CSS4 debate is everywhere right now. And honestly? Most people are arguing about the wrong thing. The real question isn't "inline styles vs. utility classes" — it's about where your styling decisions live and who pays the cognitive cost. Let me break down what's actually happening, with real code, real trade-offs, and a clear take at the end. What Changed in Tailwind CSS v4 Tailwind CSS v4 introduced a major shift: CSS-first configuration. Instead of a tailwind.config.js , you define everything in your CSS file using @theme : /* Before (v3) - tailwind.config.js */ module .exports = { theme : { extend : { colors : { brand : '#6366f1' , } , spacing : { 18: '4.5rem', } } } } /* After (v4) - main.css */ @import "tailwindcss" ; @theme { --color-brand : #6366f1 ; --spacing-18 : 4.5rem ; } This is cleaner for many workflows. But it's not what's causing the drama. The Real Flashpoint: Utility Density in JSX What's actually triggering the discourse is how v4 accelerates a pattern that was already polarizing — components that look like this: // The "inline styles but make it Tailwind" pattern function AlertBanner ({ type , message }) { return ( < div className = { ` flex items-center gap-3 px-4 py-3 rounded-lg border ${ type === ' error ' ? ' bg-red-50 border-red-200 text-red-800 ' : ' bg-blue-50 border-blue-200 text-blue-800 ' } ` } > < span className = "text-sm font-medium" > { message } </ span > </ div > ); } vs. the @apply approach many teams prefer: /* alert.css */ .alert { @apply flex items-center gap-3 px-4 py-3 rounded-lg border; } .alert--error { @apply bg-red-50 border-red-200 text-red-800; } .alert--info { @apply bg-blue-50 border-blue-200 text-blue-800; } // Cleaner component function AlertBanner ({ type , message }) { return ( < div className = { `alert alert-- ${ type } ` } > < span className = "text-sm font-medium" > { message } </ span > </ div > ); } Both work. Neither is objectively wrong. But they encode very different philosophies. The Philos

\shadcn/ui and Material UI optimise for opposite priorities. Choose shadcn/ui to own your component code, ship a near-zero runtime, and control every pixel; choose Material UI (MUI) for breadth — 90+ components and a paid data grid — behind Google's Material Design. shadcn/ui has ~116,000 GitHub stars and ships copy-paste components; MUI has ~98,000 stars and ~7.3M weekly npm downloads. Both are MIT-licensed and free for commercial use. This guide covers the parts you only learn by shipping both: how each behaves in the Next.js App Router, the runtime cost, real theming and dark-mode code, forms, data tables, and migration mechanics. What's the real difference between shadcn/ui and Material UI? The difference is ownership, and it decides everything downstream. MUI is an npm dependency ( @mui/material ) you install and import from node_modules — you never touch the source. shadcn/ui is a copy-paste registry: you run a CLI, the component lands in your repo, and it is now your code. shadcn/ui is unstyled, built on Radix UI primitives and Tailwind CSS. MUI ships Material Design and an Emotion (CSS-in-JS) runtime. With MUI you install and import: bash npm install @mui/material @emotion/react @emotion/styled cta.tsx import Button from " @mui/material/Button " ; export function Cta () { return < Button variant = "contained" > Get started </ Button >; } With shadcn/ui the CLI copies the source into your project and you import from your own path — there is no library to upgrade or override: bash npx shadcn@latest add button cta.tsx import { Button } from " @/components/ui/button " ; export function Cta () { return < Button > Get started </ Button >; } That ownership changes how you customise. shadcn's button.tsx lives in your repo and uses class-variance-authority (cva) for variants — you add one directly: components/ui/button.tsx // components/ui/button.tsx — this file is yours const buttonVariants = cva ( " inline-flex items-center justify-center rounded-md ... " , { varia

The main idea of a Carousel isn't just about moving a bunch of elements from left to right because there must be a smoothly infinite movement, this can be done by duplicating the element, but wouldn't it be a waste of time and resources to do so. So the best solution would be rather than moving the whole element, we just move each element on a time based manner, all elements will have the animation but each element will have a unique (incremented) index, by which we will delay its start, and if we made this delay negative, we will have a smooth movement without any lagging adding a will-change will make a separate compositing layer to make the animation run on gpu rather than cpu below is a demo by which, you can understand the effect You can reach me (if you had any problems with the effect): X / twitter "where I post a lot!" LinkedIn

Hello Dev Community! 👋 It is officially Day 45 of my non-stop run toward full-stack engineering! Yesterday, I learned how to serve static HTML pages using Express routing. Today, I took a major step toward building premium, clean, and minimalist UI/UX styles by installing and mastering Tailwind CSS via the Tailwind CLI ! Instead of writing massive, chaotic external CSS stylesheet files, today I shifted to the industry-standard utility-first workflow to speed up my design iterations. 🧠 Key Learnings From Day 45 (Tailwind CSS Architecture) Tailwind doesn't give you pre-built components; it gives you atomic utility classes that let you build completely custom, high-end layouts directly inside your HTML structure. Here is the engineering breakdown: 1. Tailwind CLI Installation & Initialization I learned how to integrate Tailwind from scratch using npm packages instead of lazy CDN links. Installed the tailwindcss compiler core ( npm install -D tailwindcss ). Initialized the configuration hub using npx tailwindcss init . 2. Crafting the Content Map inside tailwind.config.js Understood how Tailwind optimizes final file weights using tree-shaking. I configured the structural template paths so the compiler knows exactly which files to scan for dynamic styling classes: javascript /** @type {import('tailwindcss').Config} */ module.exports = { content: ["./public/**/*.{html,js}"], // Scanning static folders cleanly theme: { extend: {}, }, plugins: [], }

Hello Dev Community! 👋 It is Day 32 of my continuous web development run, and today I jumped into a project that pushed my array manipulation and conditional logic to a whole new level: A complete Snake and Ladder Board Game using HTML5, CSS3, and Vanilla JavaScript! After building Rock Paper Scissors yesterday, I wanted to tackle a game that requires tracking persistent coordinate states across a 100-cell mathematical grid. 🛠️ The Game Architecture & Logic Breakdown Building this wasn't just about random numbers; it was about managing spatial transitions on a dynamic interface. Here is how I structured the core backend mechanics: 1. The 100-Cell Grid Layout Instead of manually hardcoding 100 divs inside my index file, I engineered the grid programmatically. I mapped out a loop running from 100 down to 1, building individual cell elements and using CSS Grid properties to wrap them perfectly into a standard 10x10 layout matrix. 2. Mapping Snakes & Ladders (The Jump Engine) To build the shortcuts and traps, I didn't write massive, messy if-else trees. Instead, I utilized a clean JavaScript Object Map tracking key-value pairs where the key is the trigger tile and the value is the destination tile: javascript const gameModifications = { // Ladders (Climbing up) 4: 14, 9: 31, 21: 42, 28: 84, 51: 67, 72: 91, 80: 99, // Snakes (Sliding down) 17: 7, 54: 34, 62: 19, 64: 60, 87: 36, 93: 73, 95: 75, 98: 79 };

So you have heard about the Tailwind CSS and want to incorporate into your new project. But those...

UI IP Toolkit - A standalone static visual catalog for CSS/JS components I built UI IP Toolkit to solve my own workflow problem: I kept losing useful UI snippets (buttons, loaders, CTA blocks, glassmorphic cards, layout grids) across old projects and directories. Live site: https://ui-ip-toolkit.vercel.app/ GitHub Repository: https://github.com/ikerperez12/UI-IP-Toolkit-v4.0 Design Philosophy Zero dependencies: Raw HTML, CSS, and vanilla JS. No NPM packages, framework configurations, or build steps required. Copy-paste ready: Visual preview cards with one-click copy buttons for immediate use in any stack. Light/Dark mode: Clean design system focusing on micro-interactions, sleek gradients, and responsive layouts. Visual catalog: Catalog of gradients, buttons, fonts, loading states, hover treatments, glass surfaces, layout fragments, and UI patterns. How do you manage your personal code/CSS snippet collections? Hope this is useful to others!

Eight years ago (a geological epoch or two ago in Internet terms) Nicholas Jitkoff released itty.bitty.site - a website which could render whole websites just based on what was in the link, something like: itty.bitty.site?SOMEBASE64ENCODEDVALUE== et voilà! Free web-hosting if you could make it fit ;) At the time, I was rather obsessed with qr-codes thanks to developing QRGoPass and was working with aster plots a lot, so I developed an app that could fit into a qr-code! Today itty.bitty.site no longer exists so I can't do that any more... But I did make it 80% smaller without "cheating" and using modern CSS instead of d3.js ;)

In times when people believe that "AI can code a website in 2 days" (see: how to leverage AI as a...