标签：#css

The @function at-rule defines CSS custom functions. These custom functions are reusable blocks of CSS that can accept arguments, contain complex logic, and return values based on that logic. @function originally handwritten and published with love on CSS-Tricks . You should really get the newsletter as well.

Recently, I started building a website for a local car showroom. The budget? 800,000 Indonesian Rupiah (around $50 USD). At first, it sounded impossible. But when working with small businesses in Indonesia, budgets are often very different from what many developers in the US or Europe are used to. Instead of building a complex custom platform, I focused on solving the showroom's real problems. What the client gets Vehicle Management Add and edit car listings Manage prices Vehicle specifications Featured inventory Vehicle Search & Filters Visitors can filter cars by: Brand Model Year Price Condition Built-in CMS The showroom can publish: Car buying guides Automotive news SEO articles Promotions Lead Generation Every car listing includes direct WhatsApp contact buttons to maximize inquiries. Extra Services Included For the same price: Free maintenance for simple issues Free consultation and support 3 free blog articles during the first month AI-powered statistics assistant Why WordPress? Many developers immediately think about Laravel, React, Next.js, microservices, and other modern stacks. For this project, WordPress was the right tool. The client needed: A website they could update themselves Better Google visibility A simple inventory system More WhatsApp leads WordPress delivered all of that quickly. A Lesson I've Learned Small businesses rarely care about technology. They care about outcomes. They don't ask: "Does it use React?" They ask: "Will this help me sell more cars?" And honestly, that's probably the better question. What would you include in a low-budget car showroom website?

📚 This is Part 1 (Opening) of the UtlKit Tech Series — Next: [Architecture & Trade-offs →] As a frontend developer, I've used countless online tools. And almost all of them suck: Sign-up required — just to format a JSON string? Ad overload — the actual tool gets squeezed into a corner Privacy concerns — your JSON might contain API keys, and the tool sends it to a server Fragmented — formatters on one site, Base64 on another, hashing on a third So I decided to build one that doesn't: no sign-up, no ads, pure client-side computation, data never leaves the browser. The goal was simple — if I need this tool, someone else does too. The result is utlkit.com : 150+ tools, 8 categories, zero server costs. Requirements Requirement Meaning Pure client-side All logic runs in the browser Zero server cost Static hosting, no Node.js backend 150+ pages One page per tool, SEO-friendly Bilingual (EN/ZH) i18n support Dark/Light mode User preference Mobile responsive Works on all devices Why Not Other Frameworks? Option Pros Cons Verdict Vanilla HTML/JS Simple Managing 150+ pages is painful Too slow VuePress / VitePress Fast Docs-oriented, not for interactive tools Not flexible enough Nuxt SSR Powerful Needs a server Violates zero-cost principle Next.js 15 + output: 'export' SSR SEO + client interactivity + static hosting Has pitfalls (covered later) ✅ Best balance The Key Decision: output: 'export' // next.config.js const nextConfig = { output : ' export ' , // Static export trailingSlash : true , // Required for static files images : { unoptimized : true }, // No image optimization server } This means: ✅ Build output is plain HTML/CSS/JS files ✅ Deployable to any static host (Cloudflare Pages, Vercel, GitHub Pages) ✅ Zero server cost ❌ No API Routes, no Server Components, limited dynamic routing Deployment: Zero Cost on Cloudflare Pages Build output : out/ directory, ~14 MB Hosting : Cloudflare Pages Domain : utlkit.com Monthly cost : $0 Build Pipeline npm run build → next build ( o

Animations can make an application feel faster, smoother, and more polished. However, many developers think animations are only useful for things like: page transitions modals enter/leave effects But Vue provides another powerful pattern - State-driven animations. Instead of animating when elements are added or removed from the DOM, you animate changes in reactive state. This allows you to create rich interactive experiences while keeping your code declarative and easy to maintain. In this article, we'll explore: What state-driven animations are How they differ from regular Vue transitions What problems they solve How to implement them in Vue Best practices for creating smooth UI interactions Let's dive in. 🤔 What Are State-Driven Animations? Most Vue developers are familiar with the <Transition> component. Example: <Transition> <Modal v-if= "isOpen" /> </Transition> This animates an element when it enters or leaves the DOM. But what if the element already exists and only its state changes? For example: a progress bar grows a card expands a chart updates a panel changes size a value changes position This is where state-driven animations shine. Instead of animating DOM insertion or removal, you animate changes caused by reactive state. 🟢 What Problem Do State-Driven Animations Solve? Without animations, state changes can feel abrupt. Example: <div :style= "{ width: progress + '%' }" ></div> When progress changes: progress . value = 80 The width instantly jumps. This works technically... but it doesn't feel great. 🟢 A Simple Example Let's create an animated progress bar. < script setup lang= "ts" > const progress = ref ( 20 ) function increase () { progress . value += 20 } </ script > < template > <button @ click= "increase" > Increase Progress </button> <div class= "progress-container" > <div class= "progress-bar" :style= " { width: `${progress}%` }" /> </div> </ template > CSS: .progress-container { width : 100% ; height : 12px ; background : #eee ; } .progress-bar

You build a tournament bracket with a popular React library. In Chrome it's perfect — neat columns, clean connector lines. Then you open it on an iPhone, or in Safari, or inside your Capacitor app… and every match is crammed into the top-left corner, stacked on top of the round headers. If you've ever shipped a bracket to iOS, you've probably seen this exact bug. Here's why it happens — and a tiny library that fixes it for good. The symptom It looks fine everywhere Chromium runs (Chrome, Edge, Android WebView) and completely broken everywhere WebKit runs: Safari (macOS and iOS) iOS WKWebView Capacitor / Cordova apps Electron-on-WebKit The matches don't just shift a little — they all render at coordinate (0,0) of the bracket, piling on top of each other and the headers. The cause: SVG <foreignObject> in WebKit Most React bracket libraries — @g-loot/react-tournament-brackets , react-tournament-bracket , and friends — render the bracket as an SVG and place each match's HTML inside a <foreignObject> positioned with x / y attributes. WebKit has a long-standing bug: it ignores x , y , and transform on <foreignObject> and positions the content relative to the top-level <svg> instead of the foreignObject's own coordinates. Every match therefore collapses to the origin. And there's no CSS escape hatch — x , y , and transform are all ignored on foreignObject in Safari, so you can't nudge the content back into place. I even tried patching a library to wrap each match in a <g transform="translate(x,y)"> instead of a nested <svg x y> ; WebKit ignores ancestor transforms for foreignObject positioning too. The SVG approach is simply a dead end on WebKit. The fix: don't use SVG at all A bracket is really just columns of cards joined by connector lines — and both are expressible in plain CSS. Here's the key insight. Put each round in a flex column where every match sits in an equal flex: 1 slot. Because each round has half the matches of the previous one, a match's slot spans exactl

CSS @function - DEV Community CSS just got its biggest quality-of-life upgrade since custom properties. For years, if you wanted... dev.to

CSS just got its biggest quality-of-life upgrade since custom properties. For years, if you wanted reusable logic in CSS, you had two choices: wrestle with custom properties that couldn't do real computation, or reach for a preprocessor like Sass. That era just quietly ended. CSS now has native custom functions — and they're as powerful as you'd hope. 1. What Exactly Is @function ? Think of it exactly like a JavaScript function — but living inside your stylesheet. You give it a name (always prefixed with -- ), define some parameters, and write a result: descriptor that determines what it returns. /* BASIC SYNTAX */ /* Define it once */ @function --double ( --x ) { result : calc ( var ( --x ) * 2 ); } /* Call it anywhere */ .box { width : --double ( 20px ); /* → 40px */ height : --double ( 50px ); /* → 100px */ } No var() wrapper needed to call it. No build step. No Sass import. Just define and use — as many times as you like, across your entire stylesheet. Note: Unlike Sass, native CSS functions don't evaluate math automatically. You must wrap mathematical operations in calc() inside your result descriptor. 2. The Syntax in Full Detail Parameters with Default Values You can make parameters optional by giving them a fallback — the function still works even if you don't pass a value. @function --spacing ( --size : 16px ) { result : calc ( var ( --size ) * 1.5 ); } .card { padding : --spacing (); /* → 24px (uses default) */ margin : --spacing ( 20px ); /* → 30px */ } Type-Safe Parameters You can declare the expected type of each parameter — and the return type too. The browser will validate this at parse time, preventing weird cascading bugs. @function --fade ( --color < color > , --alpha < number > : 0.5 ) returns < color > { result : color-mix ( in srgb , var ( --color ), transparent calc ( var ( --alpha ) * 100% ) ); } .overlay { background : --fade ( royalblue , 0.3 ); /* 70% opaque blue */ } Logic Inside Functions This is where @function gets genuinely exciting. Y

TL;DR I got tired of writing HTML and chasing global CSS rules. I had a hunch: what if you could write a page the same way you write an app — same declarative tree, same modifier chains, scoped style per node? I spent a year quietly testing the bet on my own side projects. It... seems okay? I've open-sourced it as DraftOle ( npm / live demo ). page() writes plain static HTML + scoped CSS — zero runtime JavaScript shipped. app() adds reactive state() and event handlers — TypeScript arrow functions get serialized into a minimal runtime at build time. Same DSL, same modifiers, in both cases. No bundler, no JSX, no template language, zero production dependencies. pnpm add draft-ole # or npm install draft-ole # or yarn add draft-ole This is the 0.9.0 pre-1.0 release. The API surface is essentially settled and 1.0 is the next tag, but I'm intentionally holding back the 1.0 promise until I hear from real users. If you try it and it feels great or terrible, please tell me — both signals are useful. (Yes, AI can generate HTML/CSS now. I'm not making a claim about how DraftOle compares — that's a separate experiment I haven't run. This article is just about what I built and why.) ## Honestly? I just don't want to write HTML or global CSS anymore Let me be candid about the motivation. It's not a refined "type safety extends to the leaves" pitch. It's two embarrassingly small frustrations I kept hitting on every side project. 1. I don't want to write HTML I'm building logic in TypeScript — typed values, typed functions, typed data flow — and then at the last mile I have to drop into stringly-typed HTML. Attribute names are strings. Class names are strings. Five levels of nesting and I can't tell which element carries which style anymore. The logical layer is type-safe, and then the presentation layer reverts to "paste these strings together carefully." That mismatch grates every time. 2. I don't understand global CSS CSS-in-JS, CSS Modules, Tailwind — pick your weapon, eventual

A clever use of CSS to calculate and display a discounted product price by providing a base price and discount amount, featuring modern CSS features like attr() , mod() , and round() . Computing and Displaying Discounted Prices in CSS originally handwritten and published with love on CSS-Tricks . You should really get the newsletter as well.