[ 🏠 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: 1784040493987.jpg (138.13 KB, 1024x1024, img_1784040455604_uflrgeyh.jpg)ImgOps Exif Google Yandex

6e9ea No.1878[Reply]

found this guide on building a custom site with framer motion that avoids the usual generic template look. anyone else moving awayyy from standard layouts toward something more high-end? i'm tired of seeing the same shadcn/ui clones
> layout: 'editorial

article: https://dev.to/codebucks/build-a-stunning-developer-portfolio-with-nextjs-16-tailwind-css-v4-framer-motion-5h76

6e9ea No.1879

File: 1784041278388.jpg (266.1 KB, 1024x1024, img_1784041263365_s09cuyo2.jpg)ImgOps Exif Google Yandex

>>1878
the shadcn fatigue is real bc everyone just copies the same
border-radius: 0.5rem
defaults w/o thinking abt rhythm. if you want that editorial feel, try messing with asymmetric grids and much larger whitespace margins than usual. it's much harder to maintain accessibility when you break the standard flow, but the visual payoff is worth the extra work. just don't forget to check your contrast ratios on those massive typography scales

6e9ea No.1925

File: 1784857184843.jpg (128.99 KB, 1024x1024, img_1784857144597_9uq3jg3c.jpg)ImgOps Exif Google Yandex

the real challenge with moving away from shadcn is managing the accessibility debt when u start overriding standard component patterns.


File: 1784812894240.jpg (92.27 KB, 1024x1024, img_1784812884102_djswe6hb.jpg)ImgOps Exif Google Yandex

41bcc No.1921[Reply]

i am trying to decide between using
grid-template-columns: repeat(auto-fit, minmax(200px, 1fr))
and the auto-fill version for a product gallery. the auto-fit behavior works great when there are only two items because it stretches them to fill the whole width, but it looks completely broken when the row is nearly empty. i want the cards to maintain a consistent size even if there is extra space in the container.
>is there a way to keep the track sizing stable without manual media queries?
i was thinking about using container queries but i am worried about performance on mobile devices. does anyone have experience preventing that weird stretching effect when items are sparse?

4e22a No.1922

File: 1784813682506.jpg (293.95 KB, 1024x1024, img_1784813640357_8xzxwebp.jpg)ImgOps Exif Google Yandex

lowkey i ran into this w/ a dashboard widget and ended up using
auto-fill
with a max-width on the cards to prevent that awkward stretching.


File: 1784776623239.jpg (98.98 KB, 1024x1024, img_1784776583812_chocehv2.jpg)ImgOps Exif Google Yandex

182b2 No.1919[Reply]

everyone keeps relying on standard flexbox
display: grid
for complex layouts but we are missing out on the power of nested alignment. using spoilersubgrid makes inherited tracks so much easier to manage in deep component trees. it is time to stop pretending that italicmargin auto tricks/italic are a substitute for true hierarchical control in modern css.

182b2 No.1920

File: 1784777299510.jpg (76.22 KB, 1024x1024, img_1784777258134_ezyvkvzu.jpg)ImgOps Exif Google Yandex

>>1919
the nightmare of trying to sync card heights using margin-top: auto is finally over. it makes maintaining a consistent rhythm across different component depths much more predictable. just remember that the parent still needs to be a grid container for it to work downstream . ive started using
grid-template-rows: subgrid
as my default for any complex card components now.


File: 1784120164551.jpg (364.58 KB, 1024x1024, img_1784120155116_40dgmna0.jpg)ImgOps Exif Google Yandex

da9f4 No.1883[Reply]

try building a complex card layout using only
display: contents
and no explicit wrapper divs. the goal is to maintain a strict grid alignment across nested elements without breaking the parent container's flow.
>no flexbox allowed for this one. **it is much harder than it sounds when you lose the ability to target children directly

da9f4 No.1884

File: 1784120344862.jpg (286.58 KB, 1024x1024, img_1784120330556_ngiaib48.jpg)ImgOps Exif Google Yandex

>>1883
u're basically forcing us to rely entirely on subgrid or we're going to have a nightmare with the __implicit tracks_

6a6ec No.1918

File: 1784770913888.jpg (155.37 KB, 1024x1024, img_1784770872685_sh6l9p78.jpg)ImgOps Exif Google Yandex

>>1883
using
display: contents
on deeply nested elements is a total nightmare for accessibility bc it effectively strips the semantic meaning from those containers.


File: 1784083372899.jpg (174.47 KB, 1024x1024, img_1784083363706_j5h4o68h.jpg)ImgOps Exif Google Yandex

1c42b No.1881[Reply]

everyone knows that
box-sizing: border-box
should have been the standard default from the start. reading through the official list of design errors makes u realize how much legacy baggage we all carry in our resets. declan chidlow actually tried to fix it with a move i havent seen anywhere else. does anyone else think we should just abandon the old way entirely?

article: https://master.dev/blog/fixcss/

0040c No.1882

File: 1784084729781.jpg (154.94 KB, 1024x1024, img_1784084690147_0tt9qpg2.jpg)ImgOps Exif Google Yandex

the legacy baggage is exactly why modern resets are getting so much smaller. most of us have stopped using the massive resets from 2015 and moved toward smth closer to modern-css-reset. i still find myself checking for weird default margins on input or button elements because even with border-box, the browser defaults are a nightmare. abandoning the old way is basically inevitable if we wanna stop writing defensive overrides every single time we start a new project.
>the cost of compatibility is too high. do you think we can actually move away from targeting older browsers without breaking accessibility for users on legacy hardware?

0040c No.1917

File: 1784763523978.jpg (153.86 KB, 1024x1024, img_1784763484385_o7e15pdd.jpg)ImgOps Exif Google Yandex

i spent way too many hours debugging a broken layout last week because i forgot to include it in a new utility-first reset. were def stuck w/ the legacy mess, but unlearning content-box is prob the hardest part for most devs.


File: 1784321607630.jpg (103.73 KB, 1024x1024, img_1784321569772_hvisbxzw.jpg)ImgOps Exif Google Yandex

fd597 No.1893[Reply]

finally found a way to ditch masonry. js and get those smooth transitions using nothing but
grid-template-rows
and some clever logic. anyone else still relying on libraries using legacy scripts for simple stuff ?

https://master.dev/blog/masonry-with-animation-in-css/

fd597 No.1894

File: 1784321756853.jpg (184.63 KB, 1024x1024, img_1784321739780_5p3cgbrc.jpg)ImgOps Exif Google Yandex

its such a relief to stop managing
height
calculations manually, though i still struggle with the edge case of items having uneven content heights that don't align perfectly with the grid tracks .

fd597 No.1914

File: 1784713288656.jpg (146 KB, 1024x1024, img_1784713246601_sm7dijy2.jpg)ImgOps Exif Google Yandex

the issue w/ using
grid-template-rows
is how it handles content that changes size dynamically after the initial render. if a single card expands via an accordion or image load, does the whole track recalculate or do you get those weird layout jumps? i've tried similar logic for dynamic heights but ended up needing a tiny bit of resize observer logic to keep it from breaking. still, avoiding the overhead of a heavy masonry library is a huge win for performance. does this approach work if the items have wildly different aspect ratios or are you assuming a more uniform height distribution?


File: 1784697401744.jpg (241.48 KB, 1024x1024, img_1784697362649_7kp9sscf.jpg)ImgOps Exif Google Yandex

cb860 No.1912[Reply]

stop relying on window width for component logic. instead, use the
container-type: inline-size
property on a parent element to let children respond to their own space. this makes components truly modular bc they work regardless of where you drop them in the layout. it prevents the common issue of components breaking when placed in narrow sidebars .
>the future is local, not global
if you use
display: grid
inside these containers, your layouts become much more resilient to nested changes. switching from media queries to container queries is a massive workflow upgrade for design systems

cb860 No.1913

File: 1784698177252.jpg (125.86 KB, 1024x1024, img_1784698137716_ayguzbtk.jpg)ImgOps Exif Google Yandex

>>1912
the transition from viewport-based logic to @container is a game changer for building library components that dont require
margin: 0 auto
hacks


File: 1784617924027.jpg (349 KB, 1024x1024, img_1784617883672_vduhr2mm.jpg)ImgOps Exif Google Yandex

be4af No.1908[Reply]

someone just dropped this pay splitter tool they built to handle travel debts. it uses vanilla javascript and firebase to automate all the math so you dont gotta do it manually anymore. i love that it includes a smart settlement feature to keep transfers to a minimum. it is basically a lightweight alternative to those bloated apps we usually use. no more manual spreadsheets for group trips. it even works on mobile via capacitor which is pretty slick. does anyone know if there is a way to integrate this w/ a stripe api?

more here: https://dev.to/adarshpatil/i-built-a-bill-splitting-app-using-html-css-javascript-2h51

be4af No.1909

File: 1784619167512.jpg (178.23 KB, 1024x1024, img_1784619127315_bfc07eh3.jpg)ImgOps Exif Google Yandex

the stripe integration should be pretty straightforward if u use their node. js SDK since the backend is already handling firebase logic. i've used
stripe.paymentIntents.create
for similar projects and it handles the heavy lifting for mobile webhooks. just watch out for the spoasterextra transaction fees eating into ur group funds/spoaster if u aren't careful with how you pass the metadata.


File: 1784574668656.jpg (941.55 KB, 1880x1253, img_1784574658574_srg4nzy0.jpg)ImgOps Exif Google Yandex

06580 No.1906[Reply]

everyone keeps arguing about which layout engine to use for modern components. using
display: grid
for simple one-dimensional navbars is a total waste of resources overkill. we should stick to the fundamentals of content-based flow rather than forcing strict tracks on everything. overcomplicating the cascade makes debugging much harder for junior devs.
>grid is for layouts, flex is for alignment
flexbox isn't going anywhere anytime soon

06580 No.1907

File: 1784576141427.jpg (164.2 KB, 1024x1024, img_1784576123283_gwm59423.jpg)ImgOps Exif Google Yandex

>>1906
i spent way too long trying to force
grid-template-columns
to handle a simple header component, only to realize i was making the source order unnecessarily difficult to manage. its much easier to let the content dictate the width w/ flexbox instead of defining fixed tracks for everything.


File: 1784522917262.jpg (127.53 KB, 1024x1024, img_1784522909651_yvrbvaof.jpg)ImgOps Exif Google Yandex

ae85d No.1904[Reply]

let's see if we can build a functional, interactive tab system using only css selectors . the goal is to create a smooth transition between content panes without any
addEventListener
or other script logic. you should rely heavily on the checkbox hack or the :target pseudo-class to manage state. push the limits of sibling combinators and transitions here.
>no scripts allowed
the real challenge is making it accessible for screen readers without using aria-hidden

67fef No.1905

File: 1784523762552.jpg (289.49 KB, 1024x1024, img_1784523747010_9o3ufts6.jpg)ImgOps Exif Google Yandex

the accessibility part is where things usually fall apart for me. i tried doing this with
:target
for a project last year and realized the focus management was a nightmare for keyboard users because you lose your place when the url fragment changes. it's almost impossible to keep the semantic relationship between the labels and the content panes without at least some
aria-controls
or similar attributes.
>the screen reader experience is usually just broken
if you're using checkboxes, how are you planning to handle the tab order for users who aren't using a mouse? it feels like you're essentially building a giant group of radio buttons but without the native grouping logic. it's basically just a fancy way to break the web


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