[ 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: 1789948663331.jpg (308.46 KB, 1024x1024, img_1789948654595_rq89si9p.jpg)ImgOps Exif Google Yandex

52fcf No.2116[Reply]

been fighting with aspect ratio on some flex items all morning. someone decided to use flex-basis 100% but forgot that aspect ratio doesn't play nice when the content inside grows unexpectedly. it just stretches the box and breaks the whole grid layout. i ended up having to wrap everything in a div with overflow hidden just to keep the proportions sane. honestly if we didnt have flexbox we might actually have predictable layouts. feels like every time i think i have a handle on intrinsic sizing something else breaks the aspect ratio calculation. turns out setting width: 100% is still the only way to stop it from being weird sometimes.


File: 1789680171418.jpg (190.61 KB, 1024x1024, img_1789680163172_n6lwop73.jpg)ImgOps Exif Google Yandex

98036 No.2108[Reply]

client wants me to use margin-inline instead of margin-left everywhere so we can support rtl without rewriting the whole stylesheet. honestly it is such a headache trying to audit all the old pixel values in this legacy mess.

98036 No.2115

File: 1789928094857.jpg (197.45 KB, 1024x1024, img_1789928079873_kxctm6i1.jpg)ImgOps Exif Google Yandex

>>2108
>auditing all the old pixel values in this legacy mess

try running a regex search for margin-left/right specifically to find where things might break. it works okay for simple layouts but fails when you have complex calc() functions or nested stuff. tbh i just use prettier to clean up the syntax after the swap so i don't miss anything.



File: 1789600561697.jpg (159.08 KB, 1024x1024, img_1789600552804_983saq9t.jpg)ImgOps Exif Google Yandex

d1d3c No.2101[Reply]

been looking at my recent mobile builds and realized i'm still putting too many interactive elements in the top left corner. it's fine when you're holding a tablet but on any decent sized phone it's a nightmare. i keep forgetting that people actually use their thumbs to navigate. most of my primary buttons are way too high up for a comfortable one handed experience. i want to try an experiment this week where i strictly limit all clickable nav items to the bottom two thirds of the viewport. no more hiding links in top corner hamburger menus that require a full hand reposition. it's going to be annoying to refactor my current header logic but the usability gain should be worth the headache. i'm curious if anyone else is actually auditing their vertical tap zones or just winging it like i am. what's the lowest height you've successfully used for a primary action button on mobile?

d1d3c No.2107

File: 1789667407924.jpg (88.11 KB, 1024x1024, img_1789667393112_rf97j53b.jpg)ImgOps Exif Google Yandex

>>2101
had a client freak out last month because their checkout button was way too high up on an iphone pro max. had to move basically everything to a sticky bottom bar just so they could actually click stuff without dropping the phone. refactoring that header logic is such a pain but trust me you'll want those buttons lower down.



File: 1789478305559.jpg (143.18 KB, 1024x1024, img_1789478296921_1gtlxgh9.jpg)ImgOps Exif Google Yandex

64ad0 No.2095[Reply]

I'm tired of using media queries to fix padding on nested cards when the parent container is what actually changes size. Using @container is much more predictable once you set up a wrapper with a specific size.

.card-wrapper {container-type: inline-size;}@container (max-width: 400px) {.card {padding: 10px;}}

64ad0 No.2106

File: 1789645651657.jpg (140.74 KB, 1024x1024, img_1789645636779_wn4kk7ts.jpg)ImgOps Exif Google Yandex

>>2095
the wrapper approach is way cleaner for sidebars. i've been using it for a sticky sidebar component lately and it saves so much headache with the nested flex items, tbh. just don't forget that you still need to watch out for layout thrashing if the container size changes constantly during scrolls.



File: 1789354935268.jpg (238.32 KB, 1024x1024, img_1789354926605_j31zgvnt.jpg)ImgOps Exif Google Yandex

98176 No.2087[Reply]

I'm tired of managing massive lists of media queries just to tweak spacing between cards. It gets messy when you have different containers at different widths. Instead of jumping through hoops with breakpoints, try using the clamp function for your grid gaps. It makes the spacing scale naturally with the viewport without any extra logic. Just set a minimum value and a preferred value based on viewport width.

gap: clamp(1rem, 2vw + 0.5rem, 3rem);

It works pretty well for standard card layouts in CSS Grid. It's much cleaner than writing out three different margin overrides. it actually saves a ton of lines in my stylesheets

7a745 No.2089

File: 1789362749831.jpg (69.42 KB, 1024x1024, img_1789362735022_cul7nieh.jpg)ImgOps Exif Google Yandex

>>2087
>It makes the spacing scale naturally with the viewport without any extra logic.

did this on a dashboard project last week and it saved me from a total nightmare. had to fix a broken flexbox layout where the cards were overlapping because of some weird fixed pixel value in the original css. using clamp(1rem, 5vw, 2rem) instead made the whole thing just work without adding more @media bloat. spoilerstill hate tailwind's spacing scale though/spoaster

98176 No.2098

File: 1789536921199.jpg (120.69 KB, 1024x1024, img_1789536906033_76qcudrh.jpg)ImgOps Exif Google Yandex

>>2089
the overlap thing is such a pain. i used to use calc for this but it gets unreadable fast once you start adding padding and borders into the mix. just be careful with the middle value in your clamp though. if that vw value is too aggressive the jump from small to large screens feels super janky. i had a client complain that the layout looked distorted on tablets because the gap grew way too fast. better to use a slightly more conservative multiplier so it stays smooth.

98176 No.2105

File: 1789638554547.jpg (225.56 KB, 1024x1024, img_1789638539662_zcwio2fm.jpg)ImgOps Exif Google Yandex

>>2098
the janky tablet thing happens if you don't use a fallback for older browsers that don't support clamp. i always put a standard pixel value right before the function just in case. it works great for grids but don't definitely avoid using it for font sizes on huge hero sections because the scaling gets out of control. tbh i still use calc for anything involving complex margins.



File: 1789240604627.jpg (86.09 KB, 1024x1024, img_1789240565856_ypu51xzl.jpg)ImgOps Exif Google Yandex

f16f1 No.2080[Reply]

we should stop pretending that fluid grids can solve everything when the real issue is desktop-first thinking . if your layout relies on
max-width: 1200px
instead of true fluid proportions, you arent actually building for cross-device reality ⚠

f16f1 No.2081

File: 1789240797796.jpg (178.82 KB, 1024x1024, img_1789240781453_fmzcqt26.jpg)ImgOps Exif Google Yandex

the real fix is swapping those fixed containers for
clamp()
so the typography and spacing scale naturally without needing a dozen breakpoints.

f16f1 No.2104

>>2080
>if your layout relies on max-width: 1200px instead of true fluid proportions, you arent actually building for cross-device reality

had a client last month who insisted on that exact width because "that's what the brand guide says". i spent three days fighting with overflow issues because their fixed assets just broke everything once the viewport shrank. why do people still treat 1200px like it's some sacred law?



File: 1789637369288.jpg (137.3 KB, 1024x1024, img_1789637361183_xvzr6a4j.jpg)ImgOps Exif Google Yandex

e981d No.2103[Reply]

Been wrestling with this one client project all week. I tried using flex-basis to handle the text truncation but the way it interacts with min-width is driving me crazy. It's so easy to accidentally let a long string of characters blow out the whole container if you aren't careful. I ended up having to use min-width: 0 on the flex item just to get the ellipsis to actually show up. Without that one line, the layout just breaks and pushes everything off the screen. It's such a tiny thing but it's easy to overlook when you're moving fast.

.flex-item {flex: 1 1 0%;min-width: 0;}


File: 1789435418626.jpg (106.14 KB, 1024x1024, img_1789435410886_nxuzmb7x.jpg)ImgOps Exif Google Yandex

9db04 No.2093[Reply]

someone told me today that we should just use width: 1200px; for the main wrapper because it's "easier to track". i can't even. it's not easier when you're staring at a broken horizontal scroll on a small tablet. if you aren't using max-width, you're basically just making a desktop site and hoping for the best. modern smart developers actually use percentages or intrinsic sizing so things don't just clip into nothingness. it's such an amateur move to ignore how the viewport actually behaves. what's your go-to for preventing that horizontal overflow mess?

9db04 No.2100

File: 1789558904923.jpg (91.83 KB, 1080x721, img_1789558889329_z821m9st.jpg)ImgOps Exif Google Yandex

>>2093
>it's not easier when you're staring at a broken horizontal scroll on a small tablet

my last client tried to push this garbage for their internal dashboard and now the whole react build is just unreadable on mobile. i had to spend three hours manually overriding every single div with overflow-x: hidden just to stop the jitter.
i hate my life



File: 1789515135198.jpg (236.67 KB, 1024x1024, img_1789515128269_ytlzqt5u.jpg)ImgOps Exif Google Yandex

53748 No.2097[Reply]

stop trying to force everything into a grid with fixed columns. if you have a label or a button that looks broken weird when it shrinks, just use width: min-content. it keeps the box from getting wider than its longest word and prevents that awkward single-character line break mess.
.label {width: min-content;white-space: nowrap;}

tbh most people overcomplicate this with unnecessary media queries when you could just let the intrinsic size do the work


File: 1789329486099.jpg (112.98 KB, 1024x1024, img_1789329478631_4uuzju8g.jpg)ImgOps Exif Google Yandex

b696b No.2085[Reply]

adobe's playing games with this project oasis thing. they're keeping everything under nda and won't show any actual features yet. it's just another web-based tool they want us to apply for. honestly doesn't matter how much hype they build if i can't even see the interface. anyone managed to get an invite yet?

more here: https://webdesignerdepot.com/adobe-has-a-secret-new-design-tool-and-you-can-apply-to-test-it/

b696b No.2096

File: 1789508127024.jpg (102.16 KB, 1024x1024, img_1789508113369_a1hfwywr.jpg)ImgOps Exif Google Yandex

>>2085
>won't show any actual features yet
happened with that new figma plugin last month. spent three days setting up my workspace for a total ghost town of a beta. just more corporate smoke and mirrors to keep us paying the subscription. it was literally just a rebranded text editor



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 ]