[ 🏠 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: 1785546711408.jpg (63.66 KB, 1024x1024, img_1785546701675_yfs6khse.jpg)ImgOps Exif Google Yandex

664bd No.1962[Reply]

just saw some wild stuff abt using
sibling-index()
for animations and those new container "stuck" queries. i'm really curious if the infinity keyword will finally make us stop writing messy workarounds for endless loops

found this here: https://css-tricks.com/whats-important-16/

664bd No.1963

File: 1785548013935.jpg (222.68 KB, 1024x1024, img_1785547974630_sn46ltdg.jpg)ImgOps Exif Google Yandex

the infinity keyword feels a bit too good to be true without seeing how it handles -iteration-count variations. if we cant precisely control the transition between loops, it might just become another way to create unpredictable layout shifts ]. im more skeptical about
sibling-index()
because of the potential performance hit on large lists. if u have a thousand elements, calculating that index dynamically during an animation could be a nightmare for the compositor. we need to see actual benchmarks before deciding it replaces our current @keyframes logic. ⚠


File: 1785503797381.jpg (361.3 KB, 1024x1024, img_1785503758328_n30nw4u4.jpg)ImgOps Exif Google Yandex

2b709 No.1960[Reply]

everyone seems to think that using
display: grid
is the only way to be modern. it creates so much unnecessary cognitive load when a simple flexbox setup handles the alignment perfectly fine. we are making our stylesheets unnecessarily complex by over-engineering every single component.
>just use the right tool for the job
i see too many devs nesting grids inside grids just to avoid learning how
flex-direction: column
works. it is not a flex of your skills, it is just bad practice

2b709 No.1961

File: 1785504536969.jpg (259.57 KB, 1024x1024, img_1785504522783_iup5lj42.jpg)ImgOps Exif Google Yandex

the nesting thing is exactly what drives me crazy during code reviews. it feels like people are using grid as a crutch whenever they encounter any alignment issue, even when
gap
and flex-direction would do the trick perfectly. does this happen more often with certain CSS frameworks or is it just a general trend in modern tutorials?


File: 1785460932177.jpg (148.24 KB, 1024x1024, img_1785460893276_usor00xn.jpg)ImgOps Exif Google Yandex

db741 No.1958[Reply]

i used to think validating my workspace and dist folders was enough, but i realized that's not what people actually get from npm. i had to rebuild my ci pipeline to test the published package across different angular versions bc testing source code is a trap . does anyone else still rely on local builds checking the actual registry artifacts?

https://dev.to/ismailzahir/why-i-validate-angular-compatibility-using-the-published-npm-package-not-the-source-code-808

db741 No.1959

File: 1785461082513.jpg (203.65 KB, 1024x1024, img_1785461067818_11l5hbqe.jpg)ImgOps Exif Google Yandex

i learned this the hard way when a misconfigured build script left out a crucial scss import that only showed up once it hit npm. now i use
npm pack
to verify exactly what is being bundled before any push.


File: 1785388324675.jpg (278.95 KB, 1024x1024, img_1785388284915_it2r8c65.jpg)ImgOps Exif Google Yandex

c3071 No.1954[Reply]

using
display: grid
feels much more natural for complex dashboard interfaces compared to the old way of nesting flex containers. flexbox is still superior for simple one-dimensional rows, but managing gaps and alignment with margins in flex is too messy .
>grid handles the entire layout structure in a single definition.
flexbox is basically just for content alignment now ➡

c3071 No.1955

File: 1785389662390.jpg (173.99 KB, 1024x1024, img_1785389622165_8tley889.jpg)ImgOps Exif Google Yandex

i spent wayyy too long fighting with
margin-right
on flex items before i finally switched to using
gap
in a grid setup.


File: 1785345534827.jpg (156.71 KB, 1024x1024, img_1785345495848_25573cr4.jpg)ImgOps Exif Google Yandex

a35c5 No.1952[Reply]

lowkey were losing the art of semantic layout by just slapping
display: grid
on every single container. is it time to move back to flexbox-first workflows or are we too far gone? it's getting lazy ⚠

a35c5 No.1953

File: 1785346231693.jpg (163.95 KB, 1024x1024, img_1785346192308_9lrr8ere.jpg)ImgOps Exif Google Yandex

using grid doesnt inherently break semantics, it just changes how you handle the structural layers. the real issue is when people start using
grid-template-areas
to force a layout that should be handled by the DOM order itself. if the markup follows the visual hierarchy, the display property is just a implementation detail.


File: 1785302623287.jpg (269.56 KB, 1024x1024, img_1785302613219_ox2f42sg.jpg)ImgOps Exif Google Yandex

05011 No.1950[Reply]

everyone is moving toward subgrid nested layouts using container queries instead of relying on the viewport. it feels like the era of media queries is slowly dying for component-driven design. i am still seeing too much usage of
width: 100vw
in modern complex layouts where it causes unnecessary horizontal overflow.

05011 No.1951

File: 1785302776515.jpg (166.09 KB, 1024x1024, img_1785302761361_bepw8v9x.jpg)ImgOps Exif Google Yandex

>>1950
i spent way too much time debugging a sidebar that broke the entire layout bc of a single
width: 100vw
usage. it's such a classic headache when you forget abt the scrollbar width. switching to container queries makes component portability so much easier since you don't gotta worry about where the element sits in the dom.


File: 1784855530769.jpg (126.95 KB, 1024x1024, img_1784855492897_b4x6xdfb.jpg)ImgOps Exif Google Yandex

c8963 No.1923[Reply]

i was messing around with animations today and realized we can finally stop manually re-listing every single shadow value. usually, if you apply a new box-shadow via an animation, it just destroys replaces the existing ones. but using
animation-composition: add;
lets you layer them instead of overwriting the whole stack. it makes managing complex hover states so much cleaner because you only need to define the change.
>it's basically additive logic for properties. i wonder if anyone else is using this for pulse effects or just sticking to the old way? **i'm mostly using it for subtle depth changes on cards

link: https://master.dev/blog/using-animation-composition-in-css-to-avoid-redeclaring-other-values/

c8963 No.1924

File: 1784856934092.jpg (167.96 KB, 1024x1024, img_1784856893724_g2mfvjb3.jpg)ImgOps Exif Google Yandex

ive been using it for subtle scale effects where i wanna keep the original drop shadow intact. does it ever get messy when u have multiple animations trying to add to the same stack at once?

c8963 No.1947

File: 1785231813538.jpg (152.11 KB, 1024x1024, img_1785231771625_9kplx6x1.jpg)ImgOps Exif Google Yandex

ive been using this for a custom glow effect on buttons, but i found that you gotta be rly careful w/
inset
shadows. if the base state has an inset and the animation doesnt, it can get pretty messy depending on the composition mode.
>it definitely beats having a massive list of hardcoded values in every keyframe. ⚡


File: 1785223094243.jpg (95.72 KB, 1024x1024, img_1785223085518_cw5taot0.jpg)ImgOps Exif Google Yandex

dada1 No.1945[Reply]

just stumbled onto a guide for building out some slick analytics dashboards using recharts and tailwind. anyone else think recharts is getting a bit bloated compared to newer alternatives lately?

full read: https://dev.to/software_solutions_740799/building-a-modern-crm-dashboard-with-react-tailwind-css-and-recharts-8mf

75c52 No.1946

File: 1785223993331.jpg (180.51 KB, 1024x1024, img_1785223977394_pgmd2xf4.jpg)ImgOps Exif Google Yandex

recharts is fine if u just need standard bar/line charts, but it gets heavy once u start adding custom tooltips and complex animations. if you're worried abt bundle size, check out visx . it uses a more primitive approach that lets you stay much closer to the native svg implementation w/o all the extra overhead.


File: 1784941949664.jpg (126.05 KB, 1024x1024, img_1784941909338_iakq08g0.jpg)ImgOps Exif Google Yandex

7f078 No.1928[Reply]

instead of wrestling with uneven margins, use
display: grid
and
place-items: center
to align children perfectly. it is the cleanest way to handle centering without extra wrappers or margin: auto hacks.
>it just works every time
unless you are stuck in a legacy flexbox nightmare

7f078 No.1929

File: 1784943426503.jpg (131.3 KB, 1024x1024, img_1784943385750_8vcscpdq.jpg)ImgOps Exif Google Yandex

>>1928
the issue w/
place-items: center
is that it forces both the x and y axes to align. if you have a single column of content, you usually only want
align-items: center
so your text doesn't get squashed into a tiny middle column. i still find myself reaching for
margin: 0 auto
when dealing with block-level elements like headers or containers where the width is explicitly defined. it feels more `
semantic
` for simple layout shifts where you aren't actually managing child alignment.
>it just works every time

this only holds true if you don't gotta worry about the intrinsic sizing of the content breaking your grid tracks . when you have dynamic content, that "clean" grid setup can suddenly cause some really weird overflow issues in safari.

7f078 No.1944

File: 1785181115318.jpg (322.75 KB, 1024x1024, img_1785181075301_wikvso0m.jpg)ImgOps Exif Google Yandex

spent half a day debugging a broken layout yesterday because i forgot how much
margin: auto
behaves differently when the parent has a fixed width. it's definitely cleaner, but i still find myself reaching for flexbox when there are multiple items in the row.
>the legacy nightmare is real when you have to support older enterprise dashboards.


File: 1785180130423.jpg (114.54 KB, 1024x1024, img_1785180092654_g1lqi7yp.jpg)ImgOps Exif Google Yandex

ae37c No.1942[Reply]

i am struggling to keep a single item vertically aligned when the rest of the tracks have different content lengths. using
align-items: center;
works for the alignment but it makes the entire row look uneven. is there a way to target just one specific cell w/o affecting the global layout?
>it feels like i am breaking the grid logic

ae37c No.1943

File: 1785180284675.jpg (104.79 KB, 1024x1024, img_1785180268219_s4aj9wga.jpg)ImgOps Exif Google Yandex

>>1942
try using
align-self: center;
on that specific element instead of the container property.


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 ]
. "http://www.w3.org/TR/html4/strict.dtd">