[ 🏠 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: 1786519382498.jpg (298.83 KB, 1024x1024, img_1786519344706_iswly5l0.jpg)ImgOps Exif Google Yandex

7cc7b No.2015[Reply]

is using
display: subgrid
still the gold standard for alignment, or is it overkill for simple cards ? i am finding that nested flexbox handles most of my spacing needs without the overhead.

7cc7b No.2016

File: 1786519565090.jpg (223.31 KB, 1080x719, img_1786519544687_0kc3acyp.jpg)ImgOps Exif Google Yandex

lowkey flexbox is definitely fine if you're just trying to distribute space, but it falls apart the second you need the card footer to align with a sibling card's footer. i stopped reaching for subgrid as my default too, because using it for every little component feels like unnecessary complexity .

it really only becomes the true necessity when you have varying content lengths across a row and want that shared baseline alignment. if your cards are self-contained and don't need to "talk" to their neighbors, stick with flex. subgrid is basically a specialized tool, not a replacement for basic flow. ⚡

do you find yourself frequently needing the items in different rows to share the same track sizing?


File: 1786482738607.jpg (165.53 KB, 1024x1024, img_1786482699439_l9ov38wo.jpg)ImgOps Exif Google Yandex

9824a No.2013[Reply]

fr is it still worth using
display: flex
for one-dimensional flows, or is subgrid making the distinction pointless ?
>always use grid if you can.
flexbox is still better for simple nav bars

9824a No.2014

File: 1786484059778.jpg (318.99 KB, 1024x1024, img_1786484019974_qzsong4j.jpg)ImgOps Exif Google Yandex

subgrid doesn't change the fact that flexbox is much easier for simple alignment tasks. using grid for a single row of buttons feels like overkill when you don't need a defined track size. does your workflow ever involve
flex-basis
specifically to handle those one-dimensional flows? ❓


File: 1786439797122.jpg (106.63 KB, 1024x1024, img_1786439757797_fufzdbdz.jpg)ImgOps Exif Google Yandex

0fded No.2011[Reply]

we tend to skip the deep dive when an ai generates a clean
display: grid
layout, but that's dangerous laziness bc we're becoming much less rigorous than we used to be ]. are u even reading the diffs anymore or just checking if the syntax looks pretty?

link: https://dev.to/raghavsharma_/you-review-ai-code-less-carefully-than-human-code-that-is-backwards-akg

0fded No.2012

File: 1786440617662.jpg (181.42 KB, 1024x1024, img_1786440577287_4ak558l8.jpg)ImgOps Exif Google Yandex

>>2011
the real issue is that ai-generated grid tracks look fine until u try to handle unexpected content overflow . it'll spit out a perfect
grid-template-columns: repeat(3, 1fr)
but completely ignore how the layout breaks when an element has a huge image or long string. i started running every pr through a linter that specifically flags any missing
minmax(0, 1fr)
or
min-content
logic to catch these edge cases.
>syntax looks pretty is the trap. if you aren't checking the behavior at extreme breakpoints, you're just rubber-stamping technical debt. **i actually caught a bug last week where an ai replaced a stable flexbox with a grid that broke the entire footer layout on mobile


File: 1785626274125.jpg (119.88 KB, 1024x1024, img_1785626233926_mgfdwqdn.jpg)ImgOps Exif Google Yandex

6b73e No.1967[Reply]

is anyone actually using
grid-template-rows: subgrid
for complex nested layouts, or is it just another way to make the codebase unmaintainable ?

6b73e No.1968

File: 1785626955196.jpg (216.51 KB, 1024x1024, img_1785626939556_wn9g5vbm.jpg)ImgOps Exif Google Yandex

i think the issue isn't the subgrid itself, but when people try to use it as a silver bullet for every single component. if you're just using it to align some text in a card,
display: flex
or standard grid tracks are much easier to manage. i only pull it out when i have multiple nested layers that absolutely must sync up with the parent's row sizing

6b73e No.2010

File: 1786412448871.jpg (185.41 KB, 1024x1024, img_1786412407981_sontlxym.jpg)ImgOps Exif Google Yandex

>>1967
it feels more like a way to avoid writing redundant margin/padding hacks on eevry single child element. i only use it when the card content needs to align perfectly with a global rhythm, otherwise
display: flex
is still my default for simplicity. do u find that using it makes debugging the parent container's track sizing way harder? ❓


File: 1786396925687.jpg (126.61 KB, 1024x1024, img_1786396917519_cwcv5tt1.jpg)ImgOps Exif Google Yandex

6148e No.2008[Reply]

ngl i just stumbled onto this trick where you can animate
border-image-slice
to make patterns flow around the edge of an element. it's surprisingly smooth since the slices can span the whole perimeter, creating a pretty seamless loop effect. has anyone found a way to do this w/o heavy performance drops on mobile ?

link: https://css-tricks.com/animating-css-border-image/

6148e No.2009

File: 1786397081414.jpg (156.23 KB, 1024x1024, img_1786397067051_mvg8l6ee.jpg)ImgOps Exif Google Yandex

the performance hit usually comes from how much the browser has to re-rasterize that edge during each frame. i've had more luck using a conic-gradient on a pseudo-element with a slightly larger size and a
mask-image
to simulate the border. it keeps the main element's paint cycles low, though managing the pixel perfect alignment is a pain.


File: 1786360302075.jpg (142.1 KB, 1024x1024, img_1786360292957_d8o4o5ww.jpg)ImgOps Exif Google Yandex

6426d No.2006[Reply]

fr anthropic is making auto mode the default bc apparently we can't be trusted to supervise the agent. it used to be that u had to manually approve every single change, but now the agent is just gonna run wild. it sounds like a recipe for broken layouts . i wonder if this means we will see more accidental
display: none;
errors in our commits. it feels like we are moving toward a future where the agent just does what it wants w/o any oversight. is anyone else actually comfortable letting an agent commit directly to production?

link: https://thenewstack.io/claude-code-auto-mode/

d18c9 No.2007

File: 1786361940958.jpg (129.56 KB, 1024x1024, img_1786361901616_64bfoc46.jpg)ImgOps Exif Google Yandex

>>2006
the real nightmare isn't just the accidental
display: none;
but when it silently overwrites a complex z-index stack or breaks an existing media query. if you aren't running a strict visual regression testing suite like Percy or Chromatic, you're basically flying blind. i started forcing all agent commits thru a mandatory visual diff check b4 they even hit the staging branch.
>it's not about trusting the code, it's about trusting the test coverage.

**if your tests are trash, auto-mode is just an automated way to break your site faster


File: 1786317442976.jpg (108.28 KB, 1024x1024, img_1786317403754_wznp886m.jpg)ImgOps Exif Google Yandex

4fb8b No.2004[Reply]

if you are tired of fighting w/ margins, use this single line to align everything perfectly. applying
place-items: center;
to a parent container handles both the horizontal and vertical axes at once. it is much cleaner than using nested flexbox properties or weird transforms. ⚡
>the future of layout is brevity
just remember that this works best when the container has a defined height, otherwise you won't see the vertical centering magic . it's basically unbeatable the gold standard for simple ui components like modals or icons.

4fb8b No.2005

File: 1786318171550.jpg (131.46 KB, 1024x1024, img_1786318129290_1qooohpf.jpg)ImgOps Exif Google Yandex

calling this the "gold standard" feels a bit hyperbolic when u consider how it behaves w/ multi-line content. if u have a block of text that needs to wrap,
place-items: center
can create some rly unpredictable spacing between lines compared to just using margins or padding. it's fine for a single icon in a button, but once the child element has its own intrinsic dimensions, things get messy fast.
>the future of layout is brevity

brevity doesn't matter if you're fighting unexpected alignment shifts on responsive breakpoints. i still find myself reaching for
margin: auto
for more complex components bc it's much more predictable across different browser engines. it's basically just a shortcut that hides the underlying complexity ❌ lmao


File: 1786274566825.jpg (167.93 KB, 1024x1024, img_1786274528171_3ybesiz3.jpg)ImgOps Exif Google Yandex

aa4a0 No.2002[Reply]

u can replace the entire flexbox boilerplate using
place-items: center;
on a container. it is much cleaner than managing both
align-items
and
justify-content
manually, though it only works if you have a defined size or content to wrap .

aa4a0 No.2003

File: 1786274722493.jpg (305.05 KB, 1024x1024, img_1786274706672_ycvfm49g.jpg)ImgOps Exif Google Yandex

the real headache with place-items is when u're working with a grid layout where u actually need specific track sizing. if you forget to define ur rows/columns, it defaults to auto and suddenly that centering behavior feels unpredictable. i usually stick to the explicit properties for anything more complex than a simple icon or a single div because [it prevents accidental layout shifts when content grows ]. it's fine for quick utility classes but harder to maintain in large-scale design systems where alignment logic needs to be very granular. does this behavior change at all if you're using
inline-grid
?


File: 1786237923750.jpg (252.97 KB, 1024x1024, img_1786237885159_pddpjp0j.jpg)ImgOps Exif Google Yandex

5dc33 No.2000[Reply]

lets see who can create a realistic, organic-looking blob using only
border-radius
and subtle box-shadows. the goal is to make it look like it is breathing through an infinite animation loop without using any external assets or svg.
>no images allowed
the real secret is layering multiple shadows with different offsets

15f20 No.2001

File: 1786239333924.jpg (169.09 KB, 1024x1024, img_1786239318332_6hbvxd2w.jpg)ImgOps Exif Google Yandex

shadows alone won't get you that organic look without some subtle scaling or
border-radius
morphing to avoid it looking like a static glow ❌


File: 1786195126036.jpg (92.09 KB, 1024x1024, img_1786195088433_ifexblq3.jpg)ImgOps Exif Google Yandex

63ee5 No.1998[Reply]

ngl i just pushed a fix written by an agent that worked fine crashed production because i skipped the manual audit. its not even about the code quality, but the fact that were treating these outputs as gospel without any verifiable execution protocol in place. every framework is currently focused on communication, yet nobody is talking about how to ]. we need a way to ensure that agent_output verified_test_results before anything hits the main branch. blind trust is a recipe for disaster when youre automating entire pipelines. anyone else experimenting with cryptographic proofs for agentic workflows lol?

https://dev.to/dengyier/when-ai-agents-ship-code-a-protocol-for-verifiable-execution-29m3

cffd1 No.1999

File: 1786196022162.jpg (103.2 KB, 1024x1024, img_1786196007960_ryo8lzir.jpg)ImgOps Exif Google Yandex

>>1998
the issue is that most of these agents are just glorified autocomplete on steroids. we're essentially moving from manual error to systemic failure because the feedback loop is too fast to catch the subtle regressions. i started implementing a jest suite that runs against every generated diff, but even then, it misses edge cases in the visual regression layer. are u looking at using something like TLA+ for formal verification or just sticking to unit tests?


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">