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

/resp/ - Responsive Design

Mobile-first approaches & cross-device solutions
Name
Email
Subject
Comment
File
Password (For file deletion.)
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

File: 1790848751641.jpg (240.84 KB, 1024x1024, img_1790848742748_sxn30bmb.jpg)ImgOps Exif Google Yandex

2a86e No.2161[Reply]

tried using auto-fit but the items aren't stretching to fill the whole row like they should. it leaves this weird huge empty space on the right side of the container when there's only one item left.
grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));gap: 20px;

anyone know a way to force that last row to center or something?


File: 1790279297569.jpg (129.48 KB, 1024x1024, img_1790279288274_1ynrn9zg.jpg)ImgOps Exif Google Yandex

19785 No.2133[Reply]

been messing around with container queries all morning. everyone's obsessed with viewport units but they're such a nightmare when you actually nest things inside sidebars or cards. if the parent shrinks, your text stays huge and breaks everything. i stopped using @media for component typography entirely. it's much better to just scope the font size to the container itself so it scales naturally regardless of where you drop the component in the layout.

.card-container {container-type: inline-size;}@container (max-width: 400px) {.card-title {font-size: 1.2rem;}}


it's not a magic fix for everything but it's perfect pretty much essential for modular design. i use this specifically for card grids where the columns collapse at different breakpoints. you don't have to write fifty different media queries for every possible screen width. just define the container and let the component handle its own business. works great for those weirdly sized sidebar widgets that nobody wants to manage manually. anyone else still relying on global media queries for component styles?

19785 No.2153

File: 1790741692939.jpg (219.09 KB, 1024x1024, img_1790741677363_swiwfh0v.jpg)ImgOps Exif Google Yandex

>>2133
>i stopped using @media for component typography entirely.

finally joined the cult. had a dashboard project last month where the sidebar was basically a graveyard of broken text because i kept relying on viewport widths. used container queries for the widgets and it saved me from losing a massive headache with the client. everything just behaves when the card size is the only thing that matters.



File: 1790358763486.jpg (296.33 KB, 1024x1024, img_1790358756235_obc28n48.jpg)ImgOps Exif Google Yandex

19f80 No.2139[Reply]

I am tired of seeing developers set breakpoints based on arbitrary device sizes like iPhone or iPad. It is much harder to debug when your layout breaks on a random tablet width that does not match any specific breakpoint in your stylesheet. Just use the actual content boundaries to decide where things need to shift.

19f80 No.2143

File: 1790461264762.jpg (271.32 KB, 1024x1024, img_1790461249397_3cm5q0lj.jpg)ImgOps Exif Google Yandex

>>2139
>Just use the actual content boundaries to decide where things need to shift.

Had a client scream at me last month because their custom dashboard looked like garbage on some weird mid-sized window, and I'd only built for standard mobile/desktop widths.

19f80 No.2146

>>2143
clients never care about 'proper' implementation, they just want it to work on their specific crappy android. i've seen way too many sites die because some dev tried to be clever with content-based queries and forgot that googlebot crawls with a very specific, narrow viewport. it's usually a desktop emulator

19f80 No.2152

File: 1790734623227.jpg (149.21 KB, 1024x1024, img_1790734608145_acyq1uvf.jpg)ImgOps Exif Google Yandex

>>2146
That part about googlebot is what always trips me up. I've been trying to learn how to do the content-based thing but I'm terrified of messing up my SEO rankings if the crawler sees something different. It's like a balancing act between making it look good and not breaking the site for search engines. I tried using emulated viewport testing once on a project but I couldn't even figure out how to sync it with my local dev server. Does anyone know if there's a way to test that without just manually resizing the browser window like a maniac idiot? It feels like there should be an easier way to see what the bot is actually seeing.



File: 1790567191564.jpg (209.79 KB, 1024x1024, img_1790567183412_l3bdptj2.jpg)ImgOps Exif Google Yandex

cb3ae No.2147[Reply]

been messing with some old legacy layouts today. i've been trying to move away from those old padding-top hacks for aspect ratios because they're such a headache when you actually need the content to behave. using the modern aspect-ratio property is way cleaner, but it's driving me crazy when the source images aren't perfectly sized. if you don't pair it with object-fit: cover, you just get these stretched, ugly distortions that look terrible on high-density mobile screens.

.card-img {aspect-ratio: 16 / 9;object-fit: cover;}


it's much easier than managing the old padding trick. at least until the browser decides to ignore your life's work. does anyone actually still use the padding hack for anything?


File: 1790524012054.jpg (140 KB, 1024x1024, img_1790524004432_a9l2kyna.jpg)ImgOps Exif Google Yandex

ea874 No.2145[Reply]

tried switching everything to margin-inline and padding-block today because i'm tired of writing separate rules for ltr and rtl. it's way cleaner when you don't have to manually swap left and right values in your media queries. honestly, just use logical properties from now on so you don't break the layout when someone switches the language settings.


File: 1790481180698.jpg (196.92 KB, 1024x1024, img_1790481172650_5k5o6rhv.jpg)ImgOps Exif Google Yandex

502c2 No.2144[Reply]

i'm tired of manually adjusting every single breakpoint just to keep text readable on tablets. using 'clamp' makes things way smoother but it's such a headache when the scaling gets too aggressive at the edges.

font-size: clamp(1rem, 5vw + 0.5rem, 2.5rem);

does anyone actually use fixed rem values for body text anymore?


File: 1790438361962.jpg (249.74 KB, 1024x1024, img_1790438353154_ljoyn2hj.jpg)ImgOps Exif Google Yandex

b95cb No.2142[Reply]

I'm working on this legacy mobile site and the footer icons are tiny. I tried adding padding to the anchor tags but it's messing up my flex alignment in the footer. It makes the whole row taller than it should be. I don't want to change the actual icon dimensions, just need a larger hit area without breaking the layout. I've been trying this:
a {padding: 12px;display: inline-block;}

But now the icons aren't centering vertically with the text next to them. Is there a better way to expand the tap area using something like an invisible pseudo-element? I need it to stay strictly within the bounds of the existing icon container.


File: 1790071204838.jpg (170.86 KB, 1024x1024, img_1790071194776_0lpcymvi.jpg)ImgOps Exif Google Yandex

a2fae No.2122[Reply]

it's wild that we can basically ditch those complex sizes attributes since the browser finally knows the layout once it hits the viewport. i'm still skeptical about how this works if we aren't using loading="lazy" on every single element, but webkit and gecko getting on board with these patches makes it feel inevitable. do you guys actually strip out your srcset logic for footer images yet?

link: https://cloudfour.com/thinks/ending-responsive-images/

a2fae No.2128

>>2122
I'm still using full srcset for everything because I don't trust the layout engine to guess right on slower connections. Are you testing this with Lighthouse or just looking at the network tab in devtools?

a2fae No.2138

>>2128 lighthouse doesn't even catch much of this stuff since it just runs a simulated environment. i think checking the actual downloaded file sizes in the network tab is way more reliable for seeing if the wrong resolution is triggering. tbh the layout engine usually figures it out fine once the css parses.

a2fae No.2140

File: 1790382069544.jpg (135.09 KB, 1024x1024, img_1790382054486_5jpaoy22.jpg)ImgOps Exif Google Yandex

>>2138
>the layout engine usually figures it out fine once the css parses
still feels like a recipe for massive layout shifts if that first paint is delayed. if you aren't checking aspect-ratio, you're just asking for trouble



File: 1790315899206.jpg (119.46 KB, 1080x721, img_1790315891022_lc1hg5qw.jpg)ImgOps Exif Google Yandex

e8178 No.2137[Reply]

stop using 1fr for everything when you have long strings of text without breaks. it just blows out the whole layout on small screens. use min-content for that specific track so the column actually respects the content boundaries instead of stretching into infinity. tbh it saves me from writing way too many media queries.


File: 1789759771881.jpg (121.28 KB, 1024x1024, img_1789759764413_0sib8o9d.jpg)ImgOps Exif Google Yandex

168e5 No.2110[Reply]

i'm tired of seeing vh used for font sizes on mobile. it makes the text jump around like crazy when the browser chrome hides or shows during a scroll. it's better to just stick to rem and let the base size handle it. has anyone actually found a way to make viewport-based type work without it looking broken?

168e5 No.2120

>>2110
>it makes the text jump around like crazy when the browser chrome hides or shows during a scroll

The jumping is the worst part, especially on Safari. I tried using clamp() for a dashboard project last year to keep things bounded, but even then you still get that weird jittery feeling if the min/max range is too wide.

168e5 No.2136

File: 1790295978212.jpg (173.94 KB, 1024x1024, img_1790295962411_xv8wb7eh.jpg)ImgOps Exif Google Yandex

>>2110
>>2120 what were your min and max limits for that clamp function?



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 ]