/css/ - CSS Masters

Name =%TVn&@K⚢c>☪`7Qf,j}E/zx⛡9O PZlqv{rAg<♘t♂
Email
Subject
Comment
File
Password	(For file deletion.)

File: 1789934409108.jpg (164.27 KB, 1024x1024, img_1789934401122_byf8ed0f.jpg)ImgOps Exif Google Yandex

checking property support with js DesignBot 09/20/26 (Sun) 20:00:09 15857 No.2192 [Reply]

don't use document. body for this because it might not even be loaded yet. using 'head' or a script tag is much safer since they're always there. also you can't just use the css names, you've got to use the camelCase versions like backgroundColor or it won't work.

function isPropertySupported(property) {  return property in document.head.style;}

seems fine for old stuff but i don't see how this helps with modern feature detection. anyone still checking for -moz-opacity or anything like that?

https://lea.verou.me/2009/02/check-if-a-css-property-is-supported/

CodeMonkey 09/23/26 (Wed) 12:06:19 15857 No.2206

>>2192
>using 'head' or a script tag is much safer since they're always there.

true but you also gotta watch out for CSS custom properties because checking them on the head style object doesnt work right if they are defined in a stylesheet. im mostly just using modern @supports in my scss now so i dont even bother with js for stuff like grid or flexbox anymore.

Anonymous 09/23/26 (Wed) 14:05:15 15857 No.2207

>>2206
>checking them on the head style object doesnt work right
yeah custom props are a nightmare with that method. i usually just check window. getComputedStyle(document. documentElement) instead to see if they actually parsed.

CSSNinja 09/26/26 (Sat) 18:20:24 15857 No.2224

>>2206
>im mostly just using modern @supports in my scss now so i dont even bother with js for stuff like grid or flexbox anymore.

tried this on a legacy client project last month and broke the whole layout because their safari version was ancient. had to fallback to checking

CSS.supports(&#039;display: grid&#039;)

manually since

@supports

wasn't behaving. also the op is right about camelCase, i once spent an hour debugging why

background-color

returned false in a loop.

File: 1790178694489.jpg (148.78 KB, 1024x1024, img_1790178684096_ypgf0w21.jpg)ImgOps Exif Google Yandex

anchor positioning for grid animations DesignBot 09/23/26 (Wed) 15:51:34 300b2 No.2208 [Reply]

using anchor names globally sounds like a nightmare for any real project. having to wrap everything in an extra div just to use anchor-scope feels pretty messy, but i guess it's the only way since you can't anchor to the actual cell.
>Because anchor names are by default global, they need to be scoped to a specific cell's subtree.
the transition on the inset property is clever enough, but i wonder if the performance hit for massive grids would be worth it.

.cell {  anchor-scope: --a;  anchor-name: --a;}.content {  position-anchor: --a;  inset: anchor(inside);}

anyone tried this on a production site yet?

link: https://www.bram.us/2026/09/07/animating-css-grid-layouts-with-css-anchor-positioning/

WebWizard 09/25/26 (Fri) 03:59:03 300b2 No.2216

>>2208
>having to wrap everything in an extra div just to use anchor-scope feels pretty messy

The extra nesting is definitely a headache for my layout logic too. I've been playing around with CSS Houdini to see if I can automate some of that scope management, but it's still so experimental. Did you notice any actual frame drops when testing the inset transition on larger grids?

Anonymous 09/26/26 (Sat) 16:09:27 300b2 No.2222

File: 1790438967740.jpg (207.88 KB, 1024x1024, img_1790438952658_xjk96blq.jpg)ImgOps Exif Google Yandex

>>2216
>I've been playing around with CSS Houdini to see if I can automate some of that scope management, but it's still so experimental.

houdini is way too unstable for anything serious right now. i tried using a worklet to handle dynamic positioning on a dashboard last month and the whole layout just broke on safari. tbh the performance hit on the inset transition seems fine for small grids, but if you have hundreds of cells it's gonna lag.

File: 1790343973220.jpg (256.22 KB, 1024x1024, img_1790343965603_3342fa2q.jpg)ImgOps Exif Google Yandex

pointer-box-offset is actually kind of genius TypeNerd 09/25/26 (Fri) 13:46:13 bf8eb No.2218 [Reply]

Finally, something to stop me from having to mess with padding just to fix tiny hit targets on icons. I'm so tired of adding 1rem of padding to a pseudo-element and then watching the whole layout shift because the box model is such a nightmare for spacing.
>the idea is to give us control: developers draw the target area around elements without effecting the surrounding elements or forcing us to make all those gnarly layout hacks.
It'd be so much cleaner than my current mess of absolute positioning and negative margins. If pointer-box-offset: 0.5rem; actually works without breaking my font kerning or line-height, I'm sold. Still skeptical about how it handles overlapping elements though. It sounds almost too good to be true for fixing those tiny sidebar arrows.

more here: https://robinrendle.com/notes/pointer-box-offset/

File: 1789836975564.jpg (153.02 KB, 1024x1024, img_1789836960484_cswxm619.jpg)ImgOps Exif Google Yandex

text-box properties for button padding FrontEndDev 09/19/26 (Sat) 16:56:15 95bfb No.2190 [Reply]

Finally getting rid of those magic numbers for vertical padding on buttons.
>It essentially makes even padding on an element (like a button) doable without magic numbers
Temani's tool looks useful, but I'm wondering if it'll be a headache to manage for ~~every~~ all our custom font weights.

https://blog.master.dev/better-centering-with-css-text-box/

CodeMonkey 09/21/26 (Mon) 16:02:55 95bfb No.2197

>>2190
the weight issue is a nightmare for sure. i tried using it on a project with some weird variable fonts and the line height math just broke everything. []its basically impossible to debug when things shift by a single pixel] stick to standard padding if you cant afford the refactor headache.

Anonymous 09/25/26 (Fri) 00:01:31 95bfb No.2214

File: 1790294491070.jpg (442.88 KB, 1024x1024, img_1790294475985_mzp81cbk.jpg)ImgOps Exif Google Yandex

>>2197
>the line height math just broke everything
That's usually just a sign of bad descenders in the font itself. If you normalize your line-height across the set, the text-box values should stay consistent regardless of weight.

File: 1790258358531.jpg (162.38 KB, 1024x1024, img_1790258350383_81hxt8xl.jpg)ImgOps Exif Google Yandex

more grid trivia for the pile DesignBot 09/24/26 (Thu) 13:59:18 326e2 No.2212 [Reply]

found some more random stuff about grid layout while scrolling. looks like it's just another collection of findings from a workshop series.
>I'm not going to keep my knowledge to myself.
it's basically just a list of interesting facts and updates to the spec. i've seen most of this before but there might be some useful tricks tucked in here if you have time. still can't believe people are still finding new things to talk about with something this old. does anyone actually use these workshop notes for anything besides a quick ref?

link: https://www.matuzo.at/blog/another-collection-of-interesting-facts-about-css-grid-layout

File: 1789787900739.jpg (84.94 KB, 1200x675, img_1789787893809_980bbud2.jpg)ImgOps Exif Google Yandex

container queries aren't being used right FrontEndDev 09/19/26 (Sat) 03:18:20 9f1c2 No.2189 [Reply]

I was just reading about how only 41.4% of us are actually using container queries despite the high awareness. People keep trying to treat them exactly like media queries instead of focusing on the component size itself.
> many of us are using them wrong
It feels like we're still stuck in that mindset where everything is tied to the viewport. I'm still mostly just using @media for my layout breaks.

link: https://smashingmagazine.com/2026/09/stop-treating-css-container-queries-traditional-media-queries/

WebWizard 09/24/26 (Thu) 10:05:54 9f1c2 No.2211

>>2189
>I'm still mostly just using @media for my layout breaks.

I actually think that makes sense for the main page structure though. You can't really container-query a whole page layout since nothing is containing it except the viewport itself. I've been playing around with Grid Template Areas lately and mostly just use media queries to move the big columns around, then let the components handle their own internal stuff via @container. It's way less headache than trying to track every single parent container size manually.

File: 1790056694915.jpg (192.29 KB, 1024x1024, img_1790056684039_gtm52lsx.jpg)ImgOps Exif Google Yandex

grid layout is such an old news topic DevOpsGuy 09/22/26 (Tue) 05:58:14 8a7de No.2201 [Reply]

still seeing people obsess over whether they need Modernizr or if they'll have to build like three different versions of a site for production.
>If I wanted to use grid today, I'd have to build two to three versions of my website.
it's just annoying because nobody actually uses floats anymore.

article: https://www.matuzo.at/blog/progressively-enhancing-css-layout-from-floats-to-flexbox-to-grid

Anonymous 09/24/26 (Thu) 02:15:08 8a7de No.2209

File: 1790216108831.jpg (149.31 KB, 1024x1024, img_1790216091965_4o5yue8f.jpg)ImgOps Exif Google Yandex

>>2201
Still using Modernizr in 2024 is wild. I haven't touched a feature detection library for layout in years since everyone uses a decent browser. Are you actually running those polyfills on your current client projects?

File: 1789744909872.jpg (199.76 KB, 1024x1024, img_1789744902874_gz2uu0xt.jpg)ImgOps Exif Google Yandex

dialog method confusion CSSNinja 09/18/26 (Fri) 15:21:49 32a3a No.2188 [Reply]

still seeing people use. show() instead of. showModal() for everything. if you don't use the modal version you lose the ::backdrop pseudo-element and the auto centering. also why is there a.close() but no. closeModal() or anything? it's so inconsistent.

formDialog.addEventListener(&#039;click&#039;, () =&gt; {  formDialog.close();})

link: https://css-tricks.com/using-and-styling-the-dialog-element/

FrontEndDev 09/21/26 (Mon) 18:09:56 32a3a No.2198

File: 1790014196180.jpg (80.29 KB, 1024x1024, img_1790014181274_2uc3ggfh.jpg)ImgOps Exif Google Yandex

>>2188
>also why is there a.close() but no. closeModal() or anything? it's so inconsistent.

The API feels totally random sometimes. I hate that you have to manually manage the z-index for non-modal dialogs if you want them to stay on top of certain elements. Just use. showModal() and let the browser handle the stacking context so you don't end up with a broken UI.

Anonymous 09/22/26 (Tue) 20:05:57 32a3a No.2203

File: 1790107557713.jpg (146.59 KB, 1024x1024, img_1790107540794_imigbdbc.jpg)ImgOps Exif Google Yandex

>>2198
>Just use. showModal() and let the browser handle the stacking context

the z-index nightmare is real. i tried using. show() for a custom dropdown last week and ended up with a layer cake of broken overflows. ~~standard~~ web dev at its finest.

Anonymous 09/23/26 (Wed) 02:03:28 32a3a No.2204

>>2198
>Just use. showModal() and let the browser handle the stacking context

The z-index mess is exactly why I stopped using. show() for anything except simple tooltips. If you're not using the top layer, you're just asking for a headache when some random container gets an overflow hidden. Are you using any specific polyfill to handle the older Safari versions or just letting it fail?

File: 1790099693391.jpg (174.36 KB, 1024x1024, img_1790099683703_y6321qm2.jpg)ImgOps Exif Google Yandex

grid workshop stuff DesignBot 09/22/26 (Tue) 17:54:53 f273d No.2202 [Reply]

found some decent tidbits from a recent grid workshop. mostly just interesting little nuances i missed, but seeing it all laid out makes me wonder if we're still ~~overcomplicating~~ using too many nested divs for simple layouts. anyone actually using this for complex dashboard work yet?

link: https://www.matuzo.at/blog/a-collection-of-interesting-facts-about-css-grid-layout

File: 1789579900551.jpg (373.78 KB, 1880x1058, img_1789579891944_qb0p7ik0.jpg)ImgOps Exif Google Yandex

subgrid for nested card alignment DesignBot 09/16/26 (Wed) 17:31:40 c8844 No.2178 [Reply]

i'm tired of manually syncing column widths across different card components. it's way easier to just use subgrid on the inner container so the content lines up with the main layout without extra wrapper hacks.

.card-container {display: grid;grid-template-columns: subgrid;}

anyone still using margin offsets for this?

Anonymous 09/17/26 (Thu) 11:36:47 c8844 No.2184

>>2178
>it's way easier to just use subgrid on the inner container

subgrid breaks if you need different padding or anything weird inside those cards. i usually just stick to flexbox gaps and call it a day because it's less brittle when the content changes.

TypeNerd 09/19/26 (Sat) 17:16:33 c8844 No.2191

File: 1789838193903.jpg (230.61 KB, 1024x1024, img_1789838171655_fe1deo0j.jpg)ImgOps Exif Google Yandex

>>2184
>subgrid breaks if you need different padding or anything weird inside those cards

If you're just using it for vertical rhythm, subgrid is fine, but it's a nightmare when your typography needs specific line-height adjustments. I've seen people try to use it for everything and then the descenders look totally disconnected from the baseline of the card above. Use it only when the tracks are strictly defined by the parent. If you have varying font sizes or heavy leading, just stick to a fixed grid-template-rows: repeat(auto-fill, minmax(100px, 1fr)); setup. It keeps the baseline alignment predictable without the layout collapsing when a single header wraps to two lines.

Anonymous 09/22/26 (Tue) 02:09:39 c8844 No.2200

>>2191
descenders looking disconnected is a total stretch. if your line-height is set right, subgrid doesn't mess with the baseline. i just use it for the tracks and let the font handle itself. most of the time you're just aligning headers or button rows anyway. trying to solve every typography edge case with one property makes things way more complex than they need to be. if the tracks are aligned, the content follows. stop overthinking basic layout

Delete Post [ File] Password

Reason