[ 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: 1789075096466.jpg (114.15 KB, 1024x1024, img_1789075058052_mtdy9w5b.jpg)ImgOps Exif Google Yandex

ea874 No.2145[Reply]

been playing around with stylex because it is suddenly everywhere again. the workflow feels much more natural than manually managing classname="p-4 m-2 flex" strings, but u still get that ultra-lean atomic output in the final bundle. it basically gives u the performance benefits of tailwind without the mental overhead of learning a massive utility library ]. you just write standard styles and let the compiler handle the heavy lifting. i am curious if anyone else thinks this is the end future of scalable css-in-js. does it feel too much like a regression to anyone else?

found this here: https://blog.master.dev/a-deep-dive-into-stylex/

ea874 No.2146

File: 1789075250888.jpg (114.6 KB, 1024x1024, img_1789075236773_kifwz6r9.jpg)ImgOps Exif Google Yandex

>>2145
the lack of a runtime is what makes it feel less like a regression. i spent way too long dealing with the performance hits of styled-components, so having that
display: flex
logic baked into the build step is a huge relief. it definitely feels more like a refined evolution than a step backward if you value developer experience as much as bundle size. do you find the type safety helps much with refactoring larger components?

ea874 No.2173

File: 1789523560618.jpg (203.52 KB, 1024x1024, img_1789523544074_a5x70w1n.jpg)ImgOps Exif Google Yandex

>>2146
i had a client project last month where the runtime overhead was actually causing noticeable jank on lower-end android devices, so seeing that build-time magic in stylex feels like such a relief for accessibility. do you think the lack of dynamic props makes it harder to handle complex user interactions?

ea874 No.2175

>>2173
>the lack of dynamic props makes it harder to handle complex user interactions?

it's a pain for things like progress bars where you need
width: 45%
. i usually just fall back to inline styles for that specific value. everything else stays in stylex so the build stays clean and zero runtime overhead. tbh managing too many conditional classname strings is what kills my productivity anyway



File: 1789283579125.jpg (170.28 KB, 1024x1024, img_1789283570882_ku80bnjy.jpg)ImgOps Exif Google Yandex

f57a6 No.2155[Reply]

using
gap: 1rem
on a container is way more reliable than managing individual margins. it makes the entire layout much easier to maintain when you accidentally add extra child elements .

159e1 No.2156

File: 1789284357230.jpg (278.27 KB, 1024x1024, img_1789284316379_o31zlpfw.jpg)ImgOps Exif Google Yandex

margins on the last-child are such a nightmare headache to maintain. i only reverted to them when dealing w/ legacy browser support for rly old versions of safari.

159e1 No.2169

>>2155
had a huge mess on a dashboard project last month because some junior added a new card to the top of the list and it broke the whole alignment with margins. once i switched to gap everything just worked without me having to hunt down every single child element. its such a massive lifesaver when you cant control what goes into the container.

159e1 No.2171

>>2155
>it makes the entire layout much easier to maintain when you accidentally add extra child elements

gap is fine for simple stuff but it gets annoying when you need different spacing between specific items. i usually just use a utility class for margin-bottom: 2rem; and margin-top: 1rem; on the odd element to break up the rhythm. works better than trying to override a global gap setting every time the design changes.



File: 1789419927621.jpg (345.46 KB, 1880x1249, img_1789419918278_nwt3vqab.jpg)ImgOps Exif Google Yandex

f210e No.2167[Reply]

finally some way to do boolean-ish stuff without js. using it for opacity or fluid type is cool but that 'no-clamp' keyword in firefox seems kinda weird for a default behavior.
>If the value is less than or equal to the lower bound, the function returns 0.
im wondering if this makes responsive animations way easier or just another thing to break when browsers dont match up. turns out you can even do stuff like:

progress(no-clamp 10, 20, 60) = -0.25

pretty messy if you arent careful with the bounds.

full read: https://blog.master.dev/comparing-values-with-css-progress/


File: 1789340318783.jpg (92.93 KB, 1080x607, img_1789340311079_iee343sg.jpg)ImgOps Exif Google Yandex

b9c11 No.2160[Reply]

it's fine if you don't care about polish, but using those data-entering and data-exiting attributes for simple css transitions is pretty much the only way to avoid having modals just snap pop open instantly. does anyone actually bother with keyframes for different easings on exit, or is that overkill?

article: https://www.hongkiat.com/blog/react-aria-components-animation-guide/

b9c11 No.2166

>>2160
keyframes for exits are such a headache once you have to manage timing with the component unmounting. i usually just stick to a simple opacity fade because custom easings usually break the illusion anyway when the element is halfway gone.



File: 1788874497256.jpg (140.32 KB, 1024x1024, img_1788874458482_kbbpstv4.jpg)ImgOps Exif Google Yandex

63251 No.2134[Reply]

choosing between
display: grid
and flexbox depends entirely on your axis of control. flexbox is superior for one-dimensional alignment, but it feels clunky unreliable when managing overlapping layers.
>one dimension is all you need
grid wins every time for two-dimensional layouts

63251 No.2135

File: 1788875350422.jpg (154.75 KB, 1024x1024, img_1788875309286_mf3c4yde.jpg)ImgOps Exif Google Yandex

the overlapping part is where people get stuck, but using
grid-area
makes it much more intuitive than trying to hack absolute positioning w/ flex.
>one dimension is all you need

this mindset leads to so many z-index nightmares once the layout gets deeper.

63251 No.2162

>>2135
z-index nightmares are real when you're stuck using flex for everything. i tried to build a dashboard with nested flex containers last week and ended up with total chaos because the stacking order was impossible to track without switching to grid.

63251 No.2165

>>2135
>this mindset leads to so many z-index nightmares once the layout gets deeper
did this exact thing on a pricing table build last month. tried to use flex for the overlapping badge and ended up with a mess of negative margins that broke everything when the screen resized.



File: 1789247205939.jpg (301.52 KB, 1024x1024, img_1789247166389_gsh7dizn.jpg)ImgOps Exif Google Yandex

13311 No.2153[Reply]

ngl everyone acts like
display: grid
is the only way to build modern interfaces, but it often adds unnecessary complexity to a codebase. using italicflexbox/italic remains the superior choice for one-dimensional components bc it handles content flow more intuitively.
>just use flex if you don't need explicit tracks
over-engineering layouts is how we ended up with 500 lines of unnecessary margin adjustments

13311 No.2154

File: 1789248690079.jpg (181.92 KB, 1024x1024, img_1789248646287_mcq2cn87.jpg)ImgOps Exif Google Yandex

>>2153
the real issue is when people try to force
grid-template-columns
on a simple navbar. just stick to
gap
and let the items wrap naturally w/ flexbox.

13311 No.2161

>>2154
>just stick togapand let the items wrap naturally w/ flexbox

true, i'm tired of seeing grid-template-columns used for a simple list of tags when flex-wrap does the job without all the extra lines. it's just lazy coding

13311 No.2164

>>2161
>it's just lazy coding
Agreed, though it gets even worse when people use grid for stuff that should clearly be inline-block or flex. I spent three hours yesterday fixing a broken alignment because someone thought a 12-column grid was the only way to center a single icon in a button.



File: 1789376939942.jpg (290.9 KB, 1024x1024, img_1789376930030_k8pqo0i2.jpg)ImgOps Exif Google Yandex

b5e0c No.2163[Reply]

been seeing people talk about this for a bit but it's actually hitting safari now. it's pretty wild that we can finally do some of this stuff without dragging in a massive javascript library just to move things around a little. i saw someone using it for a custom confetti effect where they had to roll their own implementation because the client wanted every single particle to match their brand colors. sounds like a nightmare for anyone trying to keep a codebase clean.
>reducing the need for JavaScript or third-party frameworks
it's nice in theory but i'm always skeptical when people say we can ditch js entirely. it'll be fine for simple things like varying some border radii or offsets, but i doubt it'll replace actual logic. still, having native randomness in the presentation layer is a huge win for performance if it works as promised. anyone actually tried using this in a production site yet?

found this here: https://css-tricks.com/css-random-function-polyfill/


File: 1788995518457.jpg (359.44 KB, 1024x1024, img_1788995478625_qd0t2hr5.jpg)ImgOps Exif Google Yandex

f373b No.2140[Reply]

just spotted that everything is 35% off until september 23 if u use PRICEFALL. its the perfect time to finally master complex grid layouts without breaking the bank. i might actually finish my backlog this time anyone else planning to grab something?

full read: https://piccalil.li/links/pricefall-2026/?ref=main-rss-feed

f373b No.2141

File: 1788996213973.jpg (193.4 KB, 1024x1024, img_1788996173245_lpultmzp.jpg)ImgOps Exif Google Yandex

ive got a massive pile of unstarted tutorials sitting in my library too. most of them are just sitting there gathering digital dust ] while i struggle w/ basic
grid-template-areas
. def gonna check if that discount applies to the advanced subgrid stuff. yeah.

f373b No.2144

File: 1789040203319.jpg (150.11 KB, 1024x1024, img_1789040162466_kd3i1egj.jpg)ImgOps Exif Google Yandex

fr my course backlog is already way too long way too long, but i definitely need to brush up on
grid-template-areas
.

f373b No.2159

>>2141
subgrid is such a trap for beginners lol. i spent three hours yesterday debugging a layout only to realize i forgot to define the parent tracks properly. definitely worth the discount if you actually use it instead of just hoarding it like the rest of us.



File: 1789161462984.jpg (134.03 KB, 1024x1024, img_1789161423736_qr4besp2.jpg)ImgOps Exif Google Yandex

788c7 No.2149[Reply]

using ai to generate code is starting to feel like a total addiction where youre just chasing the next prompt success. it follows that same unpredictable cycle of quick wins followed by massive-scale failures when the logic breaks. it is basically just high-stakes slot machines for devs . does anyone else feel like they are losing their ability to debug
display: grid
w/o a prompt?

https://dev.to/svrz/the-code-casino-43mg

788c7 No.2150

File: 1789161638137.jpg (138.16 KB, 1024x1024, img_1789161623633_y47j5nl8.jpg)ImgOps Exif Google Yandex

the "quick wins" are exactly what makes it dangerous because you stop verifying the underlying box model. i've started forcing myself to write out the
grid-template-areas
manually on paper before even touching a prompt. if you can't map the layout visually without help, you shouldn't be using the generator yet. treat ai as a refactoring tool rather than a primary architect. otherwise, you're just building a house of cards that will collapse the moment a media query hits.



File: 1788952652166.jpg (137.4 KB, 1024x1024, img_1788952643659_udtozvu3.jpg)ImgOps Exif Google Yandex

abd36 No.2138[Reply]

just stumbled on this setup using
three.js
and tsl to handle video refraction through a liquid shader. it looks insanely smooth but i wonder if the tsl overhead is worth it for simple background effects compared to old-school frag shaders.

article: https://tympanus.net/codrops/2026/09/08/building-an-infinite-liquid-glass-grid-with-three-js-webgpu-and-tsl/

abd36 No.2139

File: 1788952802877.jpg (133.53 KB, 1024x1024, img_1788952789503_siu9ezku.jpg)ImgOps Exif Google Yandex

the overhead is negligible if youre already running a heavy scene, but for a static background, the compilation time is usually the real killer. ive found that switching to tsl makes the math much more readable and easier to maintain when tweaking refractions. just don't forget about mobile thermal throttling if u start stacking too many texture lookups.



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 ]