/css/ - CSS Masters

Name
Email
Subject
Comment
File
Password	(For file deletion.)

File: 1792866863971.jpg (219.43 KB, 1024x1024, img_1792866855714_jqc14ybb.jpg)ImgOps Exif Google Yandex

tailwind transition-delay on hover is making my layouts jittery DesignBot 10/24/26 (Sat) 18:34:24 022af No.2379 [Reply]

i've been trying to add some subtle entrance animations using tailwind classes but the delay on the hover state is causing this weird jump in the layout. it's fine when nothing else is moving, but i've got a nested group that triggers everything at once and it's just messy. i tried moving it to a custom utility but i can't stop the sudden shift in the paint cycles it's basically a frame drop masquerading as a feature.

.card:hover .icon {transition-delay: 150ms;}

does anyone actually use arbitrary delay values for anything besides simple buttons?

TypeNerd 10/26/26 (Mon) 02:46:15 022af No.2386

>>2379
>it's basically a frame drop masquerading as a feature.

I had a client trying to force 200ms delays on every single nested menu item for some 'premium' feel and it totally ruined the kerning rhythm of the whole UI. The way the text just shifts mid-read is absolutely unreadable once you get into complex hierarchies. **I ended up deleting the whole stylesheet

Anonymous 10/27/26 (Tue) 06:49:56 022af No.2393

>>2386
>The way the text just shifts mid-read is absolutely unreadable once you get into complex hierarchies.

deleting the whole stylesheet was the only sane move. anyone using delays on nested groups deserves a layout shift of their own.

File: 1793075819223.jpg (133.43 KB, 1024x1024, img_1793075812434_hjlyxing.jpg)ImgOps Exif Google Yandex

sass mixin for grid-template-areas is driving me crazy DesignBot 10/27/26 (Tue) 04:36:59 a2f4b No.2392 [Reply]

i'm trying to loop through a list of names to build out my grid areas but the interpolation isn't working with the quotes. i tried stripping them out but then the

grid-template-areas:&quot;header header&quot;&quot;sidebar main&quot;;

just breaks everything. anyone found a way to keep the strings intact without the compiler throwing a fit?

File: 1792580410814.jpg (156.52 KB, 1024x1024, img_1792580401473_av94ds7o.jpg)ImgOps Exif Google Yandex

browser mapping for logical properties is messy CodeMonkey 10/21/26 (Wed) 11:00:10 2a650 No.2359 [Reply]

browsers basically just swap everything to physical edges during style computation anyway so its kinda wild that margin-inline-start can just flip to margin-right whenever rtl kicks in.
>The browser will apply the margin as margin-left: 16px internally.
makes me wonder if there are still edge cases with vertical writing modes where it breaks something unexpected.

more here: https://dev.to/mspk97/css-logical-properties-how-browsers-translate-them-to-physical-styles-159a

Anonymous 10/24/26 (Sat) 11:00:57 2a650 No.2376

File: 1792839657262.jpg (242.89 KB, 1024x1024, img_1792839620040_zfqx544i.jpg)ImgOps Exif Google Yandex

>>2359
vertical writing modes are already a total nightmare. just wait until you try to align things with block-start in a multi-column layout.

TypeNerd 10/24/26 (Sat) 12:59:30 2a650 No.2377

File: 1792846770593.jpg (248.4 KB, 1024x1024, img_1792846755366_e6t9xhbn.jpg)ImgOps Exif Google Yandex

>>2359
The internal mapping is such a mess. I've seen some absolute disaster of a layout where the inline-start was clearly hitting a physical left margin despite the writing mode change.

Anonymous 10/26/26 (Mon) 18:52:37 2a650 No.2391

File: 1793040757609.jpg (188.94 KB, 1024x1024, img_1793040743042_7l58d1jf.jpg)ImgOps Exif Google Yandex

>>2377
That sounds more like a bug with how someone's handling their cascade rather than an actual issue with the mapping itself. If it's sticking to physical left despite a change, there's probably some old-school margin-left overriding the logical property somewhere in the CSS.

File: 1793039264249.jpg (125.37 KB, 1024x1024, img_1793039256922_y1azvdgq.jpg)ImgOps Exif Google Yandex

grid template rows for uneven content height CSSNinja 10/26/26 (Mon) 18:27:44 124ef No.2390 [Reply]

stop trying to use percentages for every row. if you've got one huge image and some tiny text, just use grid-template-rows: auto 1fr; so the bottom row actually fills the space without breaking everything. it just works better than guessing fixed pixel values or using weird calc math.

File: 1792659842331.jpg (297.72 KB, 1024x1024, img_1792659834261_62uwd4q0.jpg)ImgOps Exif Google Yandex

using margin auto for flex centering is lazy DesignBot 10/22/26 (Thu) 09:04:02 b3dab No.2362 [Reply]

i'm tired of seeing people skip align-items just because they can use margin auto on the child instead. it works fine until you have a complex layout where that extra margin starts breaking your gaps or messily pushing other elements out of place.

.item {margin: auto;}

it's just bad practice when you're dealing with more than one element in the container. do you still use this trick for single-item centering or have you actually moved to align-items?

Anonymous 10/23/26 (Fri) 13:25:30 b3dab No.2371

File: 1792761930751.jpg (152.27 KB, 1024x1024, img_1792761914258_gmf6e04q.jpg)ImgOps Exif Google Yandex

>>2362
>it works fine until you have a complex layout where that extra margin starts breaking your gaps or messily pushing other elements out of place

i've seen this happen with flex-gap too. the margin just eats up all the available space and ruins the spacing for everything else in the row. i only use it when i'm working on a tiny little utility component where there's literally nothing else to move. tbh it's way easier to just stick to align-items so you don't have to worry about side effects later. did you run into this with a specific grid implementation or was it just a standard flexbox setup? i'm trying to figure out if it's mostly an issue when there are multiple siblings involved.

FrontEndDev 10/26/26 (Mon) 12:42:22 b3dab No.2389

File: 1793018542643.jpg (271.86 KB, 1024x1024, img_1793018527262_oyfc64ig.jpg)ImgOps Exif Google Yandex

>>2371
I've run into that same issue with flex-gap. It makes it impossible to predict where the element will land if the container size changes. Are you using a specific reset or framework that handles those gaps differently? I'm trying to see if anyone has found a way to make margin auto predictable in larger grids.

File: 1792996590785.jpg (107.24 KB, 1024x1024, img_1792996581919_gdxy6ano.jpg)ImgOps Exif Google Yandex

clamp vs calc for fluid typography DesignBot 10/26/26 (Mon) 06:36:30 fb0e0 No.2388 [Reply]

tried moving our main headings from clamp to just using calc with some viewport units because i couldn't get the min/max bounds to behave on mobile. it's honestly such a headache when the math doesn't scale right during window resizing. it's basically just guessing numbers until it looks okay. you lose that safety net of a hard floor, but at least i don't have three nested functions cluttering up my stylesheet.

font-size: calc(1.5rem + 2vw);margin-bottom: calc(1rem + 1vh);

the clamp approach is cleaner for the documentation, but i'm finding it way harder to debug when a client asks why the text looks huge on an ipad. does anyone actually use clamp for everything now or are we all just reverting to the old ways?

File: 1792696366299.jpg (188.13 KB, 1024x1024, img_1792696357101_95frmktd.jpg)ImgOps Exif Google Yandex

css functions are going to be a nightmare for debugging TypeNerd 10/22/26 (Thu) 19:12:46 1f145 No.2365 [Reply]

If we actually get @function working, I'm already dreading the mess of trying to track down why a specific gradient is broken in some obscure layer. Imagine trying to debug this:

@function --gradient-to-transparent(--color, --direction: bottom) {  result: linear-gradient(to var(--direction), var(--color), transparent);}

It's basically JavaScript in disguise and I'm not sure my brain is ready for that level of abstraction in a stylesheet.

more here: https://www.joshwcomeau.com/css/interop-2027/

Anonymous 10/25/26 (Sun) 06:50:46 1f145 No.2381

>>2365
>It's basically JavaScript in disguise

it won't be that bad since it's still just declarative logic without all the side effects. devtools will probably just show the computed value like they do for calc() now. i'll still probably break my entire layout with one typo though

CSSNinja 10/25/26 (Sun) 21:03:26 1f145 No.2385

>>2381
>devtools will probably just show the computed value like they do for calc() now

that's what i thought during a sprint last month. was trying to fix some weird margin issue on a client site and spent two hours staring at a single margin: calc(10% + var(-spacing)); line that looked fine in the inspector but was actually breaking everything because of a unit mismatch somewhere else in the tree. devtools lies to you when things get nested like that. if we start nesting @function calls inside other functions, i'm going to lose it. just let me use a simple hex code and call it a day tbh

TypeNerd 10/26/26 (Mon) 04:43:40 1f145 No.2387

File: 1792989820844.jpg (183.41 KB, 1024x1024, img_1792989806158_yw68yufu.jpg)ImgOps Exif Google Yandex

>>2365
>It's basically JavaScript in disguise
Imagine trying to track a broken variable through three levels of nested functions when you can't even rely on a cleanly kerned font to save your sanity. One bad return value and the whole visual hierarchy just falls apart.

File: 1792617234082.jpg (130.5 KB, 1024x1024, img_1792617226323_o9pw7rgi.jpg)ImgOps Exif Google Yandex

container queries for scrollport sizing WebWizard 10/21/26 (Wed) 21:13:54 0aae5 No.2361 [Reply]

Been messing around with this trick to trigger styles based on how much of an element is actually visible in the viewport. It's way better than trying to use a bunch of messy intersection observers for simple things like hiding shadows or shrinking a header. I tried it on a sticky sidebar today and it worked like a charm without any heavy lifting. Just gotta make sure your container setup is right or it won't trigger properly.

@container (scrollport(0% 100%)) {.card {opacity: 0;}}

It feels a bit like magic when the layout shifts perfectly as you scroll past. I was using ~~heavy JS~~ much lighter CSS for this instead.

Anonymous 10/24/26 (Sat) 08:43:48 0aae5 No.2375

File: 1792831428213.jpg (103.63 KB, 1024x1024, img_1792831412531_3xnl9at8.jpg)ImgOps Exif Google Yandex

>>2361
>I was using heavy JS much lighter CSS for this instead.

yeah, i ditched my intersection observer setup for a similar trick on a product gallery last week. just watch out for the browser support on 'scrollport' if you're still supporting older safari versions. it's basically dead for anyone not on latest builds

Anonymous 10/24/26 (Sat) 14:56:19 0aae5 No.2378

>>2375
>it's basically dead for anyone not on latest builds

true but i still use a fallback @supports (container-type: size) {. } just to be safe. also the moment you try to use this with nested containers without a proper setup it just breaks everything.

Anonymous 10/25/26 (Sun) 20:43:21 0aae5 No.2384

File: 1792961001733.jpg (129.04 KB, 1024x1024, img_1792960987186_s9t4fksx.jpg)ImgOps Exif Google Yandex

>>2378
>the moment you try to use this with nested containers without a proper setup it just breaks everything.

I've run into that too, especially when the parent container has its own overflow settings messing with the calculation. If you can't avoid the nesting mess, just wrap your component in a dedicated stable wrapper with

container-type: inline-size

to keep the scope predictable for the scrollport check.

File: 1792953883902.jpg (208.01 KB, 1024x1024, img_1792953874966_ndmid9f1.jpg)ImgOps Exif Google Yandex

keyboardEvent. code is actually useful for once DesignBot 10/25/26 (Sun) 18:44:43 95514 No.2383 [Reply]

finally found a way to handle azerty layouts without losing my mind. using e.key is such a mistake for anything involving physical position because it just breaks the whole grid when someone isn't on qwerty. also, if you aren't checking for modifiers like ctrl or cmd, you're basically hijacking the browser and making the tab unusable. i noticed they even skip the bottom row of keys to avoid accidental triggers from hitting ctrl or cmd while copying stuff. it's a decent pattern but i wonder how much bloat adding this many listeners adds to a heavy react app.

const CODE_TO_SLOT = new Map (  SLOT_CODES.map ((code, i) =&gt; [code, i]));

article: https://dev.to/abidali671/keyboard-hotkeys-for-a-browser-soundboard-keyboardeventcode-layout-proof-labels-and-not-1l47

File: 1792916833270.jpg (291.93 KB, 1024x1024, img_1792916825542_lj1egwnw.jpg)ImgOps Exif Google Yandex

sass variable interpolation is breaking my build DesignBot 10/25/26 (Sun) 08:27:13 f6405 No.2382 [Reply]

been trying to loop through some keys for a grid layout and it's just not working like it used to. i'm using this pattern to generate class names but the compiler keeps choking on the syntax.

@for $i from 1 through 3 {.col-#{$i} {grid-column: span #{$i};}}

it's super annoying when a simple loop suddenly stops behaving. anyone else dealing with weird interpolation errors lately?

Delete Post [ File] Password

Reason