[ 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: 1791788431197.jpg (115.96 KB, 1024x1024, img_1791788423211_45hfagpg.jpg)ImgOps Exif Google Yandex

47800 No.2209[Reply]

i'm tired of seeing tiny little icons that nobody can actually tap without hitting something else. it's such an easy way to break a site on mobile. let's try an experiment this week where we strictly enforce at least 44px for every interactive element, even if the visual icon looks smaller. i've been playing around with using pseudo-elements to expand that hit area without messing up the layout.
.icon-button::after {content: '';padding: 12px;position: absolute;}

it keeps the tiny aesthetic but makes it usable. does anyone actually use a different value for their minimum tap area?


File: 1791622964541.jpg (167.4 KB, 1024x1024, img_1791622956065_4wrw3xqz.jpg)ImgOps Exif Google Yandex

8a7de No.2201[Reply]

I'm tired of seeing people use @media (orientation: landscape) to fix layout issues on mobile. It breaks everything when someone rotates their tablet or uses a foldable device in the wrong way. Stick to fixed breakpoints based on screen width instead.

@media (max-width: 600px) {.sidebar {display: none;}}


It's much more predictable for the grid logic.


File: 1791169391973.jpg (64.98 KB, 1080x827, img_1791169382660_qhqgy62l.jpg)ImgOps Exif Google Yandex

470c7 No.2177[Reply]

I'm moving away from media queries for component styling since it's such a headache when you drop a card into a sidebar. Just use @container with inline-size instead of trying to guess the viewport width.

.card-container {container-type: inline-size;}@container (min-width: 400px) {.card {display: flex;}}

470c7 No.2192

>>2177
guessing viewport width is such a nightmare, but i've found you still need to watch out for layout shifts if the parent container isn't sized right tbh.

470c7 No.2200

>>2192
>you still need to watch out for layout shifts if the parent container isn't sized right tbh
parent size doesnt cause the shift, its just bad aspect ratios on the images inside.



File: 1791041757151.jpg (160.68 KB, 1024x1024, img_1791041735112_r57qobdn.jpg)ImgOps Exif Google Yandex

c86c9 No.2170[Reply]

im trying to fix this weird horizontal wobble on a side drawer but it's driving me crazy. i tried setting overflow-x hidden on the parent wrapper but now the inner content just cuts off mid-sentence. looks like 'scroll-snap-type' is messing with how the container calculates its width.
.drawer-inner {overflow-x: auto;scroll-snap-type: x mandatory;}

has anyone dealt with this when using a flexbox layout for the main content?

c86c9 No.2179

>>2170
>looks like 'scroll-snap-type' is messing with how the container calculates its width.

Snap points definitely break calculations if you don't add
min-width: 100%
to the inner items, otherwise flexbox just collapses them too far.

c86c9 No.2185

File: 1791321530730.jpg (135.7 KB, 1024x1024, img_1791321513764_xit65f4t.jpg)ImgOps Exif Google Yandex

>>2179
>Snap points definitely break calculations if you don't add min-width: 100% to the inner items

That worked for me once but I ran into a huge mess with padding. If you have any extra margin on those flex items, it still feels shaky. I ended up having to use calc(100% + 20px) just to keep things from jittering when the snap hits.

c86c9 No.2197

>>2185
>If you have any extra margin on those flex items, it still feels shaky
margin on the container is a nightmare because of how the scrollbar width changes everything just use padding instead



File: 1791450762347.jpg (131.19 KB, 1024x1024, img_1791450753431_76tf34jh.jpg)ImgOps Exif Google Yandex

91f84 No.2194[Reply]

been cleaning up some old legacy stylesheets lately. i'm tired of seeing margin-left everywhere when we're doing localization. it's such a headache once you start supporting rtl languages. if you use margin-inline-start instead, the browser handles the flip for you automatically. no more writing duplicate media queries just to swap left for right. it works exactly the same for padding too. i used to rely on margin-left: 20px for everything, but it's a nightmare once the client asks for arabic support.
>it's so much cleaner
.card {margin-inline-start: 1rem;padding-inline-end: 2rem;}

the logic is basically that you stop thinking about sides and start thinking about edges. it makes the whole layout much more resilient to different text directions. does anyone else still use margin-right for everything?


File: 1790935050001.jpg (126.09 KB, 1024x1024, img_1790935041517_hrgohmhg.jpg)ImgOps Exif Google Yandex

ac238 No.2164[Reply]

i'm tired of seeing people use fixed widths on small components like badges or tags. if you just use min-content it shrinks everything down to the widest single word instead of letting it stretch weirdly across the container. works great for those little labels that shouldn't look like giant rectangles unless your words are all one syllable.
.badge {width: min-content;text-align: center;}

does anyone actually use intrinsic sizing for anything other than simple buttons?

ac238 No.2189

File: 1791371811543.jpg (215.53 KB, 1024x1024, img_1791371797313_dr2lwve8.jpg)ImgOps Exif Google Yandex

>>2164
min-content is a recipe for disaster if you have any long words. i usually stick to max-content or just some padding so the text doesn't break into single letters on mobile. seeing a badge with one letter per line makes me want to quit my job.

ac238 No.2193

>>2189
>i usually stick to max-content or just some padding so the text doesn't break into single letters on mobile.

I use
fit-content
for exactly that reason. It lets the element grow with the text but hits a ceiling so it won't overflow the parent container. Works fine for tags unless you have massive strings of text without spaces.
.tag {  width: fit-content;  max-width: 100%;}

Then you just get a predictable wrap instead of a broken layout.



File: 1791413955066.jpg (115.68 KB, 1024x1024, img_1791413946469_hexv3i5s.jpg)ImgOps Exif Google Yandex

147b0 No.2191[Reply]

I'm tired of seeing people use 100% width for everything. It breaks whenever you have padding or borders unless you're using box-sizing: border-box properly everywhere. Just use max-width: 100% instead so the image doesn't stretch out and get blurry on huge screens.
img {max-width: 100%;height: auto;}


File: 1791212417133.jpg (325.96 KB, 1024x1024, img_1791212408007_r4bb84jl.jpg)ImgOps Exif Google Yandex

16874 No.2180[Reply]

im sick of seeing those giant default checkboxes that look nothing like the rest of the ui. its so hard to make them actually match your brand colors without breaking everything. im trying a little experiment this week using appearance: none and custom svg backgrounds instead of the usual hacky way.
input[type="checkbox"] {appearance: none;background-image: url('check.svg');}

works fine on desktop but it breaks the tap area size on mobile safari sometimes. easy annoying fix if you forget to set a min-width. lets see if anyone has a clean way to handle the checked state without adding extra css bloat.

16874 No.2190

>>2180
The tap area issue is a nightmare on iOS. I've run into that same thing where the hit target just disappears if you don't explicitly set a height and width. Are you using a single SVG for both states or swapping out different files in the background-image property? I tried switching them with just a class change but it makes the flicker much worse on slower connections. Just make sure your inputtype="checkbox":checked selector is targeting the same element to avoid layout shifts. It's better to use a single sprite or an inline data URI if you can.



File: 1790978053816.jpg (117.41 KB, 1024x1024, img_1790978045629_3w1qwg08.jpg)ImgOps Exif Google Yandex

f210e No.2167[Reply]

been staring at this blurry text all morning. it's driving me nuts how some fonts look fine on desktop but get all fuzzy when you scale them for retina displays. i tried setting text-rendering: optimizeLegibility; but it didn't really do much for the weight of the characters. anyone else dealing with this weird subpixel smearing lately?

f210e No.2183

>>2167
optimizeLegibility is basically useless for this, just check if you accidentally have some weird
-webkit-font-smoothing: antialiased
overriding your actual font weights.

f210e No.2187

>>2167
spent three days on a dashboard build last month and thought i was losing my mind because everything looked thin and gray. turns out some dev left -webkit-font-smoothing: antialiased in the global css and it totally killed the weight of our custom typeface. checked the inspector and saw the subpixel magic just gone. why does this always happen during the final polish phase?



File: 1791249075167.jpg (140.64 KB, 1024x1024, img_1791249067104_6l1wr1sb.jpg)ImgOps Exif Google Yandex

24155 No.2182[Reply]

im losing my mind because some dev used z-index 9999 on a random popup and now it's hiding behind the sticky nav. its literally just basic layering and if you dont manage your stacking context properly everything breaks. im not even kidding, just use a proper layer system instead of guessing numbers lmao.


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 ]