标签：#CSS

مرتين خلال أسابيع صار موقعنا يبدو سليمًا تمامًا ولا يستجيب للضغط. الصفحة تُحمَّل، والتصميم في مكانه، والكونسول نظيف، والزوار لا يستطيعون فتح أي رابط. في المرتين لم يكن السبب خطأً برمجيًا بالمعنى المعتاد. كان سلوكًا موثّقًا في المتصفح يعمل كما صُمّم تمامًا، لكنه انطبق على نطاق أوسع مما توقّعنا. والأخطر أن اختباراتنا الآلية مرّت بنجاح في الحالتين. الحادثة الأولى: إعداد واحد عطّل سبعين عنصرًا أضفنا ويدجت مساعد ذكي للموقع، وفيه إعداد يفتح نافذة المحادثة تلقائيًا عند دخول الزائر. فعّلناه. بعدها صارت الصفحة ميتة. الروابط لا تُفتح، والأزرار لا تستجيب، وحقول البحث لا تستقبل كتابة. السبب أن الويدجت يعتمد نمطًا شائعًا في نوافذ الحوار: عند فتح النافذة، يضع السمة inert على كل ما عداها حتى لا يتشتت التركيز ولا يهرب مؤشر لوحة المفاتيح خارجها. سلوك صحيح ومطلوب في الحوارات. المشكلة أن الفتح التلقائي يجعل هذه الحالة هي حالة الصفحة الافتراضية عند كل زيارة . سبعون عنصرًا في الصفحة ورثوا inert ، وبقوا كذلك حتى يغلق الزائر نافذة لم يطلب فتحها أصلًا. // ما يفعله الويدجت عند الفتح document . querySelectorAll ( ' body > *:not(.assistant-root) ' ) . forEach (( el ) => el . setAttribute ( ' inert ' , '' )); و inert ليست سمة تجميلية. الفحص السريع يوضح مداها: const el = document . querySelector ( ' a.main-cta ' ); el . offsetParent !== null ; // true — العنصر مرئي getComputedStyle ( el ). pointerEvents ; // 'auto' — لا شيء يمنع المؤشر el . getBoundingClientRect (). width ; // 180 — له مساحة حقيقية el . matches ( ' :disabled ' ); // false — ليس معطّلًا el . closest ( ' [inert] ' ) !== null ; // true ← هنا الجواب كل فحص اعتدنا عليه يقول إن العنصر سليم. inert تعمل في طبقة أخرى: تُخرج العنصر وكل أبنائه من شجرة الوصول، وتلغي استقباله لأحداث المؤشر والتركيز، بلا أي أثر في الأنماط المحسوبة . لماذا مرّت الاختبارات اختباراتنا كانت تسأل الأسئلة المعتادة: هل العنصر موجود في الـDOM؟ هل هو مرئي؟ هل نصّه صحيح؟ الإجابات كلها نعم. ما كشف العطل كان لقطة شاشة نظر إليها إنسان ، ثم محاولة ضغط واحدة. الفحوص البرمجية كانت تصف صفحة سليمة بينما الزائر يرى صفحة جامدة. إن كنت تستخدم أي مكوّن يطبّق inert ، أضف هذا التأك

La Abuela — Comfort Food from Madrid 🍲 A cozy, fully accessible landing page for an imaginary family restaurant in Madrid, built from scratch with vanilla HTML, CSS and JavaScript for the DEV Frontend Challenge: Comfort Food Edition. 🔗 Live demo: https://laabuela.bmops.tech 💻 Interactive pen (CodePen): The story La Abuela ("the grandmother") is a tiny four-table restaurant in Lavapiés, Madrid. In 1987, Abuela Carmen opened it with one rule: if it wouldn't be served at her Sunday table, it wouldn't be served here. Forty years later, the menu still has three dishes — caldo, croquetas, lentejas — and the pot still simmers for three hours. The page tells that story through a warm terracotta-and-cream palette and five illustrations drawn entirely in pure CSS — no images, no SVG, no canvas. What I built Hero — a clay pot in pure CSS: gradient body with layered inset shadows for volume, decorative band, handles, a two-tongued fire with a glowing core, a wooden table with grain, a light sweep across the heading, and animated organic steam Our story — a bowl of caldo with a wooden spoon and a terracotta heart, all divs and box-shadows The menu — three dish cards, each with its own pure-CSS illustration: a steaming bowl of caldo, three golden croquetas with crispy texture and a pool of salsa, and a dark bowl of lentils with nine individual grains The recipe — an accessible accordion unlocking Abuela's caldo, step by step Quotes — from regulars (including one from Osaka who cried into the caldo) Booking form — with inline validation, clear labels and a friendly confirmation Footer — hours, address, and a wink to Carmen The art is pure CSS — no images, no SVG Every illustration is built the way : nested absolutely-positioned divs, layered box-shadow (inset shadows give the clay its volume and the croquettes their crust), organic border-radius , and radial gradients for light. The pot alone uses four shadow layers to feel round instead of flat. The steam is animated with pure CS

Floating labels. Inline validation. Custom checkboxes, radios, and a toggle switch. A gradient button with a press-down micro-interaction. Every bit of it below is CSS — no form library, no useState , no event listener wiring up a class toggle. That's form.fscss — the module in the FSCSS ecosystem. Same philosophy each time: solve the hard visual problem once, ship it as importable mixins, let the browser do the actual work. <script src= "https://cdn.jsdelivr.net/npm/fscss@1.1.24/exec.min.js" defer ></script> <style> @import (( * ) from form ) @ form-root () @ form-group (. form-group ) @ form-input (. form-input ) @ form-label (. form-label ) @ form-float (. form-group , . form-input , . form-label ) @ form-checkbox (. form-checkbox ) @ form-btn (. form-btn ) @ form-btn-primary (. form-btn-primary ) </style> <div class= "form-group" > <input class= "form-input" type= "text" placeholder= " " > <label class= "form-label" > Full name </label> </div> <label class= "form-checkbox" > <input type= "checkbox" checked ><span></span> I agree to the Terms </label> <button class= "form-btn form-btn-primary" > Create account </button> The two tricks doing all the work Forms feel like they need JavaScript because most tutorials reach for it immediately. Two native CSS mechanisms cover almost everything a "modern" form needs. Floating labels run entirely on :placeholder-shown . Give the input placeholder=" " — a literal space, not empty — and the browser now knows, purely in CSS, whether the field is empty and unfocused: .form-input :focus + .form-label , .form-input :not ( :placeholder-shown ) + .form-label { top : -9px ; font-size : 11px ; color : var ( --form-accent ); } No state, no class toggling on keyup. The label just reacts to what the browser already knows about the input. Checkboxes, radios, and the switch all use the classic checkbox-hack: the real <input> stays in the DOM (so it keeps native keyboard support and form submission) but is visually hidden, and a sibling

Introduction Positioning a tooltip sounds simple. Put a small box next to a button. Done. But anyone who has built one knows that it can quickly turn into: position: absolute calculating coordinates listening for resize events handling scrolling checking whether the tooltip fits on screen and sometimes pulling in an entire positioning library Modern CSS is starting to change that. CSS Anchor Positioning lets us position one element relative to another directly in CSS. Let's look at what that means with a very simple tooltip. What Is CSS Anchor Positioning? CSS Anchor Positioning allows one element to act as an anchor and another element to position itself relative to that anchor. Think about UI components such as: Tooltips Dropdown menus Popovers Context menus Floating labels These elements usually need to appear next to another element. Instead of calculating where they belong with JavaScript, we can now describe that relationship in CSS. Conceptually, we're saying: "This button is my anchor. Position this tooltip relative to it." A Simple Example Imagine we have a button: <button class= "info-button" > More info </button> <div class= "tooltip" > Your changes are saved automatically. </div> We want the tooltip to appear directly below the button. First, let's make the button an anchor. .info-button { anchor-name : --info-button ; } We've now given the button an anchor name. Next, connect our tooltip to it. .tooltip { position : absolute ; position-anchor : --info-button ; top : anchor ( bottom ); left : anchor ( left ); margin-top : 8px ; } That's the interesting part. top : anchor ( bottom ); tells the browser: Position the top of the tooltip at the bottom of the anchor. And: left : anchor ( left ); aligns its left side with the button. No getBoundingClientRect() . No coordinate calculations. No resize listener just to figure out where the tooltip belongs. Why Is This Useful? Before Anchor Positioning, we often had to manage positioning ourselves. A simplified Jav

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art. ...

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art. ...

For as long as I've been writing CSS, there's been one direction it refused to look: up. You could style a child based on its parent all day long, but the second you wanted a parent to react to something happening inside it — a checked checkbox, an invalid field, a filled-in input — you were reaching for JavaScript. Every time. It didn't matter how small the interaction was. :has() breaks that rule on purpose, and it's been safe to use in production for a while now — it's supported across Chrome, Edge, Firefox, Safari, and Opera, no polyfill required. I didn't fully appreciate what that meant until I rebuilt a form I'd been maintaining for two years and deleted most of the JavaScript in it. Not all of it — I'll get to where it still earns its place — but most. The rule CSS used to have /* This has always worked: style a child based on the parent */ .card.featured .title { color : gold ; } /* This has never worked, until :has(): style the parent based on a child */ .card :has ( .badge--sold-out ) { opacity : 0.6 ; } :has() reads as "select this element, if it contains a match for whatever's inside the parentheses." Once that clicks, a huge category of things people were writing classList.toggle() calls for turns into a single selector. Styling a label when its input is focused This used to mean a focus and blur listener on the input, toggling a class on the label. Now: .field :has ( input :focus ) { border-color : var ( --accent-color ); box-shadow : 0 0 0 3px color-mix ( in srgb , var ( --accent-color ) 25% , transparent ); } Wrap the label and input in a .field container, and the whole field lights up the moment the input inside it gets focus — no listener, no class toggle, and it can never drift out of sync with the actual focus state, because it is the actual focus state. Required-field indicators that can't go stale I've fixed this bug more times than I want to admit: a form gets a field added, and someone forgets to also add the little red asterisk that's suppo

What is a Media Query? A media query is basically a condition in CSS. You tell the browser: IF the screen satisfies this condition, THEN apply these CSS rules. For example: @media (min-width: 768px) { .container { display: flex; } } Meaning: "If the viewport is at least 768px wide, make .container a flex container." So think: IF condition is TRUE ↓ apply these CSS rules 2. Why do we need Media Queries? Because users don't have one fixed screen. Your website could be opened on: 📱 Phone 375px wide 📱 Large phone 430px wide 📱 Tablet 768px wide 💻 Laptop 1366px wide 🖥️ Desktop 1920px wide You don't want to create five completely different websites. Instead: ONE HTML + BASE CSS + MEDIA QUERIES ↓ Responsive website 3. What does "Responsive" mean? Responsive means: The website adapts its layout and appearance according to the available screen/device size. `For example: Mobile [ Card ] [ Card ] [ Card ] [ Card ] but on desktop: [ Card ][ Card ][ Card ][ Card ]` Same HTML. CSS changes the layout. 4. The basic Media Query syntax The basic structure is: ``` @media media-type AND (condition) { /* CSS rules */ } For example: @media screen and (max-width: 600px) { body { background: lightblue; } } There are three important pieces: @media ↓ screen ↓ and ↓ (max-width: 600px) ↓ { CSS } Let's understand each one. 5. What is @media? @media tells CSS: "I'm about to write a media query." Example: @media (...) { } It's an at-rule in CSS. Similar CSS at-rules you'll eventually see: @media @import @font-face @keyframes For now, just remember: @media = start a media query 6. What are Media Types? You mentioned: screen / speech etc. YES. 👍 A media type tells CSS what kind of output/device the document is being presented on. Common media types include: screen For screens. Examples: 📱 Smartphone 📱 Tablet 💻 Laptop 🖥️ Desktop Example: @media screen and (max-width: 600px) { ... } print For printed documents / print preview. For example, your webpage looks like: Website [Header] [Navigation] [Button

If you build a full-screen mobile editor as a position: fixed overlay with a fixed toolbar on top and a nav bar on the bottom , iOS Safari will happily scroll your entire chrome off-screen the moment the soft keyboard opens — but only when the content is short . The fix isn't a JavaScript viewport dance. It's one line: .editor .ProseMirror { padding-bottom : 60vh ; } Give the inner scroll container something to scroll , and iOS keeps the scroll inside it instead of falling back to scrolling the document (which drags your "fixed" elements along). No html / body locking required. I hit this while building the mobile editor for PenPage , a local-first WYSIWYG markdown notes app (React + TipTap/ProseMirror). Everything below is verified on a real iOS device. The setup Picture a mobile note editor that takes over the whole screen: ┌──────────────────────────┐ │ Toolbar (absolute,top) │ ← stays put ├──────────────────────────┤ │ │ │ Editable content │ ← scrolls │ (overflow-y: auto) │ │ │ ├──────────────────────────┤ │ Nav bar (absolute,bottom)│ ← stays put └──────────────────────────┘ The outer container is position: fixed; inset: 0 . The toolbar and nav bar are position: absolute inside it. The middle is the only thing that scrolls. Standard app-shell layout. Works great on desktop and Android. The symptom Tap into the editor, the iOS keyboard slides up, and: Long document (taller than the viewport): perfect. The content scrolls under the keyboard, the toolbar and nav bar stay nailed in place. Short document (shorter than the viewport): broken. Trying to scroll drags the whole screen — toolbar and nav bar included — as if the entire fixed overlay were a normal scrolling page. That "only when short" detail is the whole story. The root cause This is the long tail of WebKit bug #191204 : when the soft keyboard appears, iOS Safari's layout viewport gets shorter than the visual viewport , and the document itself becomes scrollable by the keyboard's height. Worse, in that stat

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . 🍩 Inspiration I write about WordPress plugins and PHP standards for a living, so when DEV dropped a "Comfort Food" theme for their Frontend Challenge, I didn't need to think twice about what to build. Not ramen, not pancakes — a donut. Specifically, the kind of donut that shows up on your desk right when a deploy breaks and somehow fixes everything. The twist I gave myself: don't just draw a static donut. Let people build one — pick a glaze, pile on toppings, then serve it — and do almost all of it in CSS, with JavaScript kept firmly in the back seat where the challenge rules ask for it to stay. That's how Donut Panic was born. 🎬 Demo Pick a glaze, load it up with sprinkles, drizzle, or powdered sugar, then hit Serve and watch it animate off the plate. 🛠️ Journey No JavaScript is driving the donut — :has() is Here's the part I'm most excited to talk about: every visual change in Donut Panic — the glaze swap, the toppings appearing, the donut lifting off the prep station and landing on the plate — is driven by plain checkbox/radio inputs and the :has() selector. Something like .kitchen:has(#serve:checked) .donut lets a parent element react to the checked state of an input buried somewhere inside it, which means the "Serve" button, the topping toggles, and the glaze picker are all just styled <label> s wired to hidden inputs. No click handlers, no state management — the checkbox is the state. JavaScript only shows up once, and it's not touching the art at all: it smooth-scrolls the stage into view on mobile after you hit Serve, because on a stacked mobile layout the donut can animate off-screen. That's the "sprinkle" of JS the challenge rules allow, used exactly the way it's meant to be — a UX nicety, not a rendering engine. Building the donut from the inside out The donut itself is layered rings, not a single flat shape: A base dough circle with a radial gradient doing double duty as both c

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . Inspiration In an Indian tech office, no product release, critical bug fix, or late-night deployment is complete without a 5-minute pantry chai break. A steaming clay Kulhad of Ginger Adrak Chai paired with crisp Garma-Garam Samosas is the ultimate comfort food that powers developers through endless coding sprints. This authentic workplace culture and rich street-food nostalgia inspired me to build a pure-CSS interactive art and corporate pantry scene. Demo Live Interactive Demo : Corporate Chai & Samosa Experience CodePen Embed : codepen.io GitHub Repository : Sayista-Yazdani/corporate-chai What I Built Adrak Chai & Samosa is an interactive web experience featuring: Pure CSS Hero Artwork : Handcrafted clay-textured Kulhad Chai cup with a shimmering tea surface, malai rim, and layered rising steam animations. Golden-brown samosas with crisp crimped edges, served on a traditional plate alongside mint and tamarind chutneys. Interactive Corporate Pantry Corner : Fully detailed tea kitchen equipped with a glowing gas stove, boiling tea saucepan with foam, spice jars ( Adrak , Elaichi , Chai Patti ), and stacked clay cups. 4 Distinct Characters : Rohan (Frontend Dev), Amit (Tech Lead), Priya (Product Manager), and Kaka (Pantry Specialist). Web Speech API & Audio Narration : Real voice speech synthesis with gender-matched voice profiles for each character. Character Gaze & Mouth Choreography : Characters automatically look toward whoever is currently speaking with dynamic gaze shifting, listening poses, and animated mouth movements. Journey & Tech Stack Technical Implementation CSS Artwork : Built entirely with CSS gradient meshes, polygon shapes, keyframe animations, and layered pseudo-elements ( ::before / ::after ). Audio Engine : Powered by native window.speechSynthesis with dynamic voice selection and text cleaning. State Management : Reactive data-speaker HTML attributes driving multi-char

Border images are an overlooked feature. One neat fact is that border image slices can run across entire borders on an element, and animating it creates beautiful effects. Animating CSS border-image originally handwritten and published with love on CSS-Tricks . You should really get the newsletter as well.

Responsive CSS: From Mobile-First Design to Modern Styling Responsive design is about creating websites that work well across mobile, tablet, and desktop screens. In this post, I learned some important techniques for building responsive and maintainable CSS. 1. Mobile-First Media Queries Mobile-first means writing the base CSS for smaller screens first and then enhancing the layout for larger screens. /* Mobile */ .card { width : 100% ; } /* Tablet */ @media ( min-width : 768px ) { .card { width : 70% ; } } /* Desktop */ @media ( min-width : 1024px ) { .card { width : 50% ; } } The main idea is: Mobile → Tablet → Desktop min-width is commonly used for mobile-first development because styles are progressively added as the screen gets larger. min-width vs max-width min-width : applies styles when the screen is at least the specified width. max-width : applies styles when the screen is at most the specified width. For example: @media ( max-width : 768px ) { h1 { font-size : 20px ; } } One important lesson I learned: CSS media queries belong inside <style> or a CSS file, not inside <script> . 2. Fluid Typography Fixed font sizes don't always work well across different screen sizes. Fluid typography allows text to adapt to the viewport. rem rem is relative to the root font size. h1 { font-size : 2rem ; } If the root size is 16px, 2rem is 32px. vw vw is relative to the viewport width. h1 { font-size : 5vw ; } However, using only vw can make text too small or too large. clamp() clamp() provides a minimum, flexible value, and maximum: h1 { font-size : clamp ( 1.5rem , 4vw , 3rem ); } This allows the font size to grow smoothly while keeping it within limits. 3. Responsive Images Images can consume a lot of bandwidth, so responsive images help browsers choose an appropriate image for the device. srcset <img src= "small.jpg" srcset= " small.jpg 400w, medium.jpg 800w, large.jpg 1200w" sizes= "100vw" alt= "Mountain" > srcset provides multiple image sizes, allowing the browser to

I shipped a page that reported zero axe violations . It had button text at a contrast ratio of 1.04:1 — which is, for practical purposes, invisible text. The scan wasn't broken. It was answering a narrower question than I thought I was asking. The bug I had a theme system built the ordinary way. Tokens on :root , overridden in a prefers-color-scheme media query, and overridden again by an explicit [data-theme] attribute so a manual toggle wins in both directions. Buttons came in two flavours: a solid primary and a bordered secondary. .btn { background : var ( --accent ); color : var ( --panel ); } .btn.sec { background : transparent ; color : var ( --ink ); } In dark mode the accent goes light green, so white-on-accent stops working. I patched it the way you patch things at 1am: :root [ data-theme = dark ] .btn { color : #10241b } @media ( prefers-color-scheme : dark ) { :root:not ([ data-theme = light ]) .btn { color : #10241b } } Now count the specificity. Selector Specificity .btn.sec 0,2,0 :root[data-theme=dark] .btn 0,3,0 :root:not([data-theme=light]) .btn 0,3,0 :not() doesn't add specificity of its own, but its argument does. So :root (0,1,0) + [data-theme=light] (0,1,0) + .btn (0,1,0) lands at 0,3,0. My theme patch outranks the component modifier. In dark mode, every secondary button — transparent background, sitting on a #1a1c1f panel — got painted #10241b . Dark green on near-black. 1.04:1. The nasty part is that this class of bug is invisible in review. The rule looks correct. It is correct, for the buttons it was written for. It just also matched buttons it was never meant to touch, in one theme only. Why the scan didn't catch it axe-core evaluates the DOM as currently rendered . It reads computed styles, and computed styles resolve exactly one colour scheme: whichever one the browser is in right now. So npx axe https://example.com is not "does this page pass contrast." It's "does this page pass contrast in the scheme this headless browser happened to boo

<!DOCTYPE html> Steam & Soul — A Bowl Written in CSS * { box-sizing: border-box; margin: 0; padding: 0; } :root { --wood1: #3b1710; --wood2: #71351f; --wood3: #a9572d; --red1: #43050c; --red2: #86101a; --red3: #d72b28; --broth1: #721006; --broth2: #c9330d; --broth3: #ff9228; --noodle1: #fff2ad; --noodle2: #ffd35c; --noodle3: #a95e1d; --gold: #ffbe42; } body { min-height: 100vh; overflow: hidden; display: grid; place-items: center; background: radial-gradient( circle at 50% 32%, #fffdf4 0%, #ffe9c7 28%, #e9a269 65%, #864029 100% ); font-family: Inter, Arial, sans-serif; } /* ===================================================== SCENE ===================================================== */ .scene { position: relative; width: 800px; height: 800px; perspective: 1100px; cursor: pointer; animation: floatingScene 7s ease-in-out infinite; } @keyframes floatingScene { 0%,100% { transform: translateY(0); } 50% { transform: translateY(-5px); } } /* ===================================================== TITLE ===================================================== */ .title { position: absolute; top: 30px; left: 0; width: 100%; text-align: center; color: #641f12; font-size: 36px; font-weight: 950; letter-spacing: 10px; text-shadow: 2px 2px 0 #ffd99e, 0 8px 20px rgba(70,20,0,.15); z-index: 200; } .subtitle { position: absolute; top: 82px; width: 100%; text-align: center; color: #8b4a2d; font-size: 11px; font-weight: 700; letter-spacing: 5px; z-index: 200; } /* ===================================================== LIGHT ===================================================== */ .light { position: absolute; left: 50%; top: 170px; width: 550px; height: 420px; transform: translateX(-50%); background: radial-gradient( ellipse, rgba(255,220,150,.4), transparent 68% ); filter: blur(20px); animation: lightPulse 5s ease-in-out infinite; z-index: 0; } @keyframes lightPulse { 0%,100% { opacity: .55; } 50% { opacity: .9; } } /* ===================================================== TABLE =======

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . Inspiration Egusi soup with pounded yam. Jollof gets the headlines, but egusi is the quiet one that actually holds Nigerian homes together. Melon seeds, ugu, palm oil, and a dome of pounded yam you eat with your hands. I already sent this challenge a love letter to jollof for the Perfect Landing prompt. This is the companion piece, and it targets a different audience: not a flat poster, but a photograph with real depth. The entire table sits in a single CSS perspective plane, so the bowl is genuinely a bowl. You look down into it. Demo A morsel of pounded yam is resting on top of the dome. Press "Dip the yam" and watch it lift off, cross the table, drop into the soup and come back stained. No JavaScript anywhere near it. Journey The rule I set myself: zero JavaScript. The one interactive moment runs on a checkbox and a sibling selector. The checkbox stays keyboard focusable, the label carries a visible focus ring, and if you've asked your system for reduced motion, the morsel skips the flight and just shows up stained. The whole scene is sized in container query units, so it scales as one object from a phone to a desktop without a single media query for layout. Some of the tricks I'm proud of: The table is one plane with transform-style: preserve-3d and a rotateX , so everything standing on it uses translateZ to mean "up off the table" The bowl is six rings flaring up the Z axis. The top two are masked hollow, otherwise, they paint straight over the soup, and the whole thing reads as a solid disc. That bug is what taught me the technique The soup sits below the rim on the Z axis, so you see the inner wall and the shadow it throws across the curds The pounded yam is six contours stacked into a dome, each one a little brighter as it climbs toward the light The egusi curds are eleven stacked radial gradients, the palm oil pools at the rim through an inset shadow, and the oil sheen is a blurre

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art. ...

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . Inspiration I chose to build a classic Dum Biryani — the ultimate comfort food! 🍛 There is nothing quite like opening a steaming handi of biryani and seeing the rich, saffron-colored rice dotted with fried onions, mint, and spices. It's a dish that brings people together and feels like a warm hug, making it the perfect inspiration for the Comfort Food challenge. Demo Here is my CSS Art representation of a traditional Biryani Handi! I built this primarily using vanilla CSS to create the realistic clay texture of the pot, the individual grains of rice, the steam animations, and the garnishes. I added a tiny bit of JavaScript just for a subtle mouse-parallax tilt effect and a saffron sparkle when you click the pot. https://github.com/pandeynitish23/dev_css_chalange/ https://dev-css-chalange.nitishkumar-nk-np.workers.dev/ Journey Building this was a really fun exercise in CSS gradients and positioning! What I'm most proud of: The Clay Handi: I used layered radial and linear gradients along with inset box shadows to give the pot a realistic, 3D clay texture with lighting highlights. The Rice & Garnishes: Creating individual rice grains, mint leaves, and onion crisps using CSS border-radius and positioning was tedious but incredibly rewarding when it all came together. The Atmosphere: Adding animated steam and floating background spice particles helped bring the scene to life and make it feel hot and fresh. It was a great challenge keeping the JavaScript minimal and relying on pure CSS for the heavy lifting of the art itself!

Change an SVG's color by editing fill and stroke , either as attributes or through CSS. Simple in theory. In practice there are three places a color can be declared in the same file, they follow the normal CSS cascade, and if you don't know that, "I changed the fill and nothing happened" turns into a twenty-minute debugging session. Here's the part of SVG color handling that usually doesn't get spelled out. fill and stroke are separate properties Every shape has an inside ( fill ) and an outline ( stroke ), set independently: <circle cx= "50" cy= "50" r= "40" fill= "#3366ff" stroke= "#000" stroke-width= "2" /> Unset fill defaults to black. Unset stroke defaults to none. If an icon is pure fill with no stroke at all (most converted icon-font SVGs are), editing stroke-width is never going to do anything visible, and that's usually the first dead end people hit. The cascade is the actual bug source A color can come from three places, and they don't have equal priority: A presentation attribute: <path fill="red" /> An inline style attribute: <path style="fill: red;" /> A <style> block or external stylesheet: path { fill: red; } Normal CSS specificity applies: style attribute beats stylesheet, stylesheet beats presentation attribute. Edit the fill="red" attribute directly, and if a <style> block elsewhere in the same file also targets that path, your edit is overridden and nothing changes on screen. No error, no warning, it just loses. If a color edit isn't sticking, grep the file for <style before assuming your tool, or your edit, is broken. This one thing accounts for most "the SVG editor is buggy" reports that are actually the cascade working exactly as designed. currentColor: SVG's inheritance trick Set fill="currentColor" and the shape stops carrying its own color and instead inherits whatever color is set to on an ancestor element, the same mechanism that makes text inherit color: <path fill= "currentColor" d= "..." /> .icon { color : #ff0000 ; } <span class= "icon

If you've opened a <path d="..."> string and had no idea what you were looking at, here's the short version: it's a tiny drawing language. A pen moves around a coordinate space, and each letter in the string is an instruction telling it what to do next. TL;DR M / m moves the pen, L / l draws a straight line, C / c and Q / q draw bezier curves, A / a draws an arc, Z / z closes the shape. Uppercase is absolute coordinates, lowercase is relative to the pen's current position. A visual path editor drags the exact same numbers you'd type by hand, it just shows you the curve instead of making you compute it. Reading a path string <path d="M10 10 L90 10 L90 90 Z" /> Broken down: move to (10, 10), draw a line to (90, 10), draw a line to (90, 90), close the path back to the start. That's a right triangle. Every path, no matter how complex, is this same pattern: a command letter followed by however many numbers that command needs, repeated. The command set Command Name What it takes M / m Move to x, y L / l Line to x, y C / c Cubic bezier control1 x/y, control2 x/y, end x/y Q / q Quadratic bezier control x/y, end x/y A / a Arc rx, ry, rotation, large-arc-flag, sweep-flag, end x/y Z / z Close path none C and Q are both bezier curves, the difference is one control point ( Q ) vs two ( C ). Two control points give you more independent influence over each end of the curve; one control point gives you a simpler, more symmetric curve. There are also shorthand continuations ( S / s , T / t ) for chaining smooth curves without repeating a control point, but the six above are what you'll hit constantly. A is the one people avoid writing by hand. Six parameters, two of which are flags (0 or 1) that determine which of four possible arcs you get for the same radii and endpoints. Flip one and you're not slightly off, you're on the opposite side of the ellipse. Absolute vs relative is the part that bites Every command above has an uppercase and lowercase form, and it's not cosmetic: <!-- a