[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/css/ - CSS Masters

Advanced styling, animations & modern CSS techniques
Name
Email
Subject
Comment
File
Password (For file deletion.)
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

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

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

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.

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.

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: 1792996590785.jpg (107.24 KB, 1024x1024, img_1792996581919_gdxy6ano.jpg)ImgOps Exif Google Yandex

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

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/

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

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

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

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.

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

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.

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: 1792916833270.jpg (291.93 KB, 1024x1024, img_1792916825542_lj1egwnw.jpg)ImgOps Exif Google Yandex

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?


File: 1792494740879.jpg (115.68 KB, 1024x1024, img_1792494732625_3slhcekq.jpg)ImgOps Exif Google Yandex

7e694 No.2350[Reply]

im tired of manually repeating grid templates in every single subcomponent. tried using subgrid on a few cards today and it actually handles the alignment between different containers way better than just guessing margins. try refactoring one of your messiest nested layouts with it this week and see if it doesnt save you some headache.

7e694 No.2360

>>2350
>it actually handles the alignment between different containers way better than just guessing margins

I used this on a massive dashboard build last month and it saved my life. Spent hours trying to force the baseline alignment for those tiny labels using weird padding hacks, but subgrid just made everything snap into place perfectly. My eye was twitching every time a text line drifted even one pixel out of sync with its neighbor.

7e694 No.2370

>>2360
>the baseline alignment for those tiny labels using weird padding hacks
I've been struggling with that exact same thing on a recent project involving some Figma exports. It works great until you have to deal with varying line heights though, which can still throw the whole grid off if you aren't careful.

7e694 No.2380

>>2370
>It works great until you have to deal with varying line heights though

Just force a single line-height on those elements via a utility class. It breaks the natural flow if you need text wrapping, but for those tiny labels in the grid, it keeps everything pixel perfect. I usually just set line-height: 1.2; or something similar to keep the bounding boxes predictable across the whole card.



File: 1792818826056.jpg (175.95 KB, 1024x1024, img_1792818817532_yjaufx3b.jpg)ImgOps Exif Google Yandex

d66af No.2374[Reply]

been thinking about this vertical codebase thing all morning. moving everything like hooks, types, and queries into one dashboard folder instead of spreading them out sounds nice until you see a massive project. co-locating html/css/js for components was already enough of a headache for some people. grouping by conceptual areas seems fine for small apps but it's going to get messy fast once the folder depth gets ridiculous. i don't see how this scales without making the file tree impossible to navigate. wouldn't that just make finding shared logic even harder?

https://blog.master.dev/the-vertical-codebase/


File: 1792372503548.jpg (244.79 KB, 1024x1024, img_1792372495237_cphfxsw7.jpg)ImgOps Exif Google Yandex

5d8f6 No.2343[Reply]

stop using fixed heights on headers when you can use auto rows with minmax. works great if your content is dynamic and you don't want to manually update a pixel value every time the copy changes.

grid-template-rows: minmax(60px, auto) 1fr;


tbh it's way better than setting some arbitrary height and praying the text doesn't wrap onto two lines and break everything

5d8f6 No.2356

File: 1792545512880.jpg (169.69 KB, 1024x1024, img_1792545497745_2nvu5h1d.jpg)ImgOps Exif Google Yandex

>>2343
The praying part is too real because I've definitely broken a layout by adding a single padding tweak. Just keep an eye on how it behaves with huge logos though. If the image scales weirdly, that minmax might still give you some unexpected gaps.

5d8f6 No.2357

>>2356 yeah huge logos are a nightmare for this. i once had a client swap out a png for a much taller svg and it basically pushed the whole nav into the content area. definitely use max-height on the img itself to keep things from going rogue.

5d8f6 No.2373

>>2343
>>2356 I don't think it'll create gaps if you set a proper object-fit on the logo. Just use object-fit: contain and it'll stay within the bounds of that minmax regardless of the original file size.



File: 1792292805453.jpg (102.46 KB, 1024x1024, img_1792292794871_kgajtxe4.jpg)ImgOps Exif Google Yandex

6d29b No.2338[Reply]

I hate when people try to use margins to fix alignment issues in a flex row. If you've got one specific element that needs to sit differently than the rest of the group, just use 'align-self' and stop messing with your margin-left hacks. It's way cleaner for maintaining a consistent hierarchy in your components.
.container {display: flex;align-items: flex-start;}.special-item {align-self: center;}

It keeps the layout logic much more predictable unless you're using it to hide your messy CSS architecture.

6d29b No.2369

>>2338
The margin-left hacks are a nightmare for anyone trying to maintain a clean component library. I just started using CSS grid for some of my bigger layouts and it's making the alignment stuff so much easier.



File: 1792335690479.jpg (336.08 KB, 1024x1024, img_1792335680258_zarfv6ox.jpg)ImgOps Exif Google Yandex

86ed5 No.2342[Reply]

Sometimes you're stuck with a specific design spec that doesn't play nice with standard rem scales. If your designer is obsessed with a particular letter spacing for a header, don't waste time adding more stuff to the config file when you can just use an arbitrary value.
<h1 class="text-4xl tracking-[0.025em]">Tight typography looks better.</h1>

It's much cleaner than defining a whole new utility for one single headline. Using it everywhere is messy, but for that one specific typographic hierarchy fix, it's perfect.

86ed5 No.2352

>>2342
just another way to bloat the html with magic numbers
still better than hunting through a 500 line tailwind config for one tracking value tbh

86ed5 No.2358

File: 1792567128609.jpg (135.87 KB, 1024x1024, img_1792567112238_quqh9on0.jpg)ImgOps Exif Google Yandex

>>2352
>just another way to bloat the html with magic numbers

I'm with you on the bloating, but it's a lifesaver when dealing with pixel-perfect Figma files that use weird decimals. I just try to keep them limited to the big hero sections so I don't end up with a mess.

86ed5 No.2368

>>2342
I had a client last month who insisted on this exact same thing for their brand identity. The Figma file was just full of these random decimals that made my eyes bleed. I ended up using the bracket notation for like three different headers because I didn't want to touch the config at all. How do you keep track of which ones you've used when you're deep in a project?



Delete Post [ ]
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
| Catalog
[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]