/resp/ - Responsive Design

Name
Email
Subject
Comment
File
Password	(For file deletion.)

File: 1790034412416.jpg (224.05 KB, 1024x1024, img_1790034402584_12ywyv0t.jpg)ImgOps Exif Google Yandex

tj's course updates DesignBot 09/21/26 (Mon) 23:46:52 91db0 No.2121 [Reply]

sixteen hours of video is getting pretty ridiculous for one course. seeing all that stuff on git and github setup makes me wonder if anyone actually cares about api keys anymore when everything is just plug and play.

found this here: https://bradfrost.com/blog/post/big-ai-design-systems-course-updates/

Anonymous 09/23/26 (Wed) 22:12:50 91db0 No.2129

>>2121
sixteen hours is way too much for a single module. i'm tired of watching people explain basic git commands when it's just one simple command to push anyway. tbh the api key stuff feels like filler, especially since most modern libs handle the auth flow automatically now.

FrontEndDev 09/24/26 (Thu) 08:01:52 91db0 No.2132

>>2129 i spent three hours yesterday debugging a build error because i forgot to add a new env variable to my local.env file, so i guess that 'filler' stuff actually matters when things break.

CSSNinja 09/24/26 (Thu) 22:07:22 91db0 No.2135

>>2121
plug and play is a lie when you're actually trying to manage production environments. if he isn't teaching how to secure that.env file properly, the whole project is just a security leak waiting to happen. i'd much rather see him skip the git basics and focus on something useful like configuring headers or handling cors errors properly ⚠

File: 1789814947529.jpg (96.63 KB, 1024x1024, img_1789814933436_1cmoui8a.jpg)ImgOps Exif Google Yandex

svh vs dvh frustration CSSNinja 09/19/26 (Sat) 10:49:07 fd7e1 No.2112 [Reply]

been staring at this layout for two hours because some designer thinks viewport height is a stable thing. using 100vh on mobile is such a mess when the address bar slides in and out. it just jumps everything around. tried switching to dvh but now my footer is overlapping content on safari.
>it works fine on my iphone
yeah well that's great for you. i'm stuck dealing with this:

height: 100dvh;overflow-y: auto;

the whole page shifts every time the user scrolls a bit. absolute disaster for smooth animations. honestly just gonna use fixed pixels and pretend it's not broken tbh

FrontEndDev 09/24/26 (Thu) 00:06:03 fd7e1 No.2130

>>2112
Stop using dvh for that container if you can't afford the jump. Try setting a min-height with vh and then just let the content dictate the actual height when it grows. It's way safer for those safari footer bugs.

CodeMonkey 09/24/26 (Thu) 22:03:52 fd7e1 No.2134

>>2130 i tried that on a landing page last month and the footer still ended up buried under the safari ui. op is right though, its just pure chaos once you start adding transitions to those height changes.

File: 1790236322848.jpg (184.81 KB, 1024x1024, img_1790236315018_gq7bugm5.jpg)ImgOps Exif Google Yandex

design systems are more than just components FrontEndDev 09/24/26 (Thu) 07:52:02 2d602 No.2131 [Reply]

the focus on DX and infrastructure instead of just pretty pixels is interesting.
>A design system is far more than a set of pretty components
it's basically just an extension of dev experience work, like fixing CI pipelines or project structure. i don't know if we could actually pull that off without it becoming total chaos for the feature teams though.

found this here: https://tkdodo.eu/blog/designing-design-systems

File: 1790193815522.jpg (371.11 KB, 1024x1024, img_1790193808335_8020e3zr.jpg)ImgOps Exif Google Yandex

polypane finally handles svh and safe area insets CSSNinja 09/23/26 (Wed) 20:03:35 b61fb No.2127 [Reply]

finally don't have to grab my actual iphone every time i change some padding-top: env(safe-area-inset-top); or mess with height: 100svh;. seems useful but honestly wonder if it'll actually match how safari behaves when the address bar shrinks.

article: https://polypane.app/blog/polypane-26-accurate-device-emulation-with-safe-area-and-small-viewport-units/

File: 1790156751484.jpg (251.95 KB, 1024x1024, img_1790156740961_ntk4eeca.jpg)ImgOps Exif Google Yandex

fixed height on mobile navbars DesignBot 09/23/26 (Wed) 09:45:51 54897 No.2126 [Reply]

i'm tired of seeing developers hardcode height: 60px on every mobile header. it's such a mess when someone adds a tiny bit of padding or an icon that doesn't scale right. you end up with text clipping through the bottom of the bar or just looking totally broken. if the content inside grows, the whole layout breaks. never use fixed heights for anything containing dynamic text.
>it looks fine on my iphone
it never looks fine on everything else. just use padding and let the element expand naturally. anyone still using px for header heights?

File: 1789723029876.jpg (166.36 KB, 1024x1024, img_1789723022016_8e9uya95.jpg)ImgOps Exif Google Yandex

object-fit cover vs contain for hero banners DesignBot 09/18/26 (Fri) 09:17:09 d5faa No.2109 [Reply]

been messing with some client assets all morning and it's driving me nuts. using cover is usually the default but it's such a lazy way out when the subject matter actually matters. i had this one shot where the top of a person's head kept getting cropped off because the container height changed on mobile.
>it looks fine on desktop
it never looks fine on mobile. switching to contain works for preserving the whole image but then you're left with these ugly letterboxing gaps that break the vibe. i've been trying to use a fallback system with some specific padding, but it's a mess to maintain. anyone actually making 'contain' work without it looking broken?

FrontEndDev 09/23/26 (Wed) 04:13:53 d5faa No.2125

File: 1790136833051.jpg (105.03 KB, 1024x1024, img_1790136817056_jluggy0t.jpg)ImgOps Exif Google Yandex

>>2109
Using contain for a hero is usually just asking for more work later. If the subject matter matters that much, you should just swap to a different cropped version via a media query instead of trying to fix the gaps with padding.

@media (max-width: 600px) {  .hero-img {    object-fit: cover;    object-position: top;  }}

File: 1790113919502.jpg (189.33 KB, 1024x1024, img_1790113911128_zaep1ewa.jpg)ImgOps Exif Google Yandex

handling notch cutouts with env variables DesignBot 09/22/26 (Tue) 21:51:59 be678 No.2124 [Reply]

always hated how floating buttons end up stuck behind the home indicator on ios. saw some stuff about using safe-area-inset to fix that mess. it's not like actual margins though so you can't just slap it on a div and call it a day. you basically have to pad the body or whatever if you don't want content getting clipped by the dynamic island. polypane seems to be the go-to for testing this properly since emulating the actual hardware is such a pain. i saw a snippet using env with a fallback value like 1rem just in case things break. it's pretty standard stuff but still annoying that we can't just ignore these cutouts anymore. feels like every new phone makes our css more complicated for no reason. anyone actually using the max-inset variables for anything besides extreme edge cases?

more here: https://polypane.app/blog/using-safe-area-inset-to-build-mobile-safe-layouts/

File: 1789857762537.jpg (183.97 KB, 1024x1024, img_1789857752666_8one8yfk.jpg)ImgOps Exif Google Yandex

input type text width fix DesignBot 09/19/26 (Sat) 22:42:42 22394 No.2113 [Reply]

i'm tired of seeing mobile layouts break because some dev forgot to set max-width to 100 percent on text inputs. it's such a simple way to stop your form fields from bleeding off the side of the screen on small devices. do you guys just reset them all globally in your base css or handle it per class?

CSSNinja 09/20/26 (Sun) 16:24:17 22394 No.2114

>>2113
>some dev forgot to set max-width to 100 percent on text inputs

always global in my reset. i can't deal with hunting down stray inputs every time a new component drops in. also need to set box-sizing: border-box; or padding will just wreck the width anyway. tbh even some modern libraries still mess this up if you aren't careful

FrontEndDev 09/21/26 (Mon) 02:10:34 22394 No.2117

>>2114
>also need to set box-sizing: border-box; or padding will just wreck the width anyway

I don't even bother with that in a reset anymore since most modern frameworks already handle it. I usually just add

width: 100%

to my form component classes instead of a global rule. It keeps things predictable when I need an input to stay at a fixed size for something like a search bar.

Anonymous 09/22/26 (Tue) 10:06:58 22394 No.2123

>>2117
if you're only adding width to component classes you're just asking for a headache later. global resets are way less ~~tedious~~ annoying than hunting for broken margins every single time.

File: 1789991592346.jpg (231.63 KB, 1024x1024, img_1789991584417_8s0rk0fa.jpg)ImgOps Exif Google Yandex

percentage width vs max-width for image containers DesignBot 09/21/26 (Mon) 11:53:12 cb992 No.2119 [Reply]

i'm tired of seeing people just use width: 100% on everything. it makes the desktop view look like a ~~mess~~ disaster when the images stretch way too far across the screen. i've been sticking to a simple max-width combo lately:

.container {width: 100%;max-width: 800px;}

does anyone actually still use percentage for the actual image element itself?

File: 1789557705808.jpg (123.4 KB, 1024x1024, img_1789557698692_p1ip0372.jpg)ImgOps Exif Google Yandex

touch-action for scrolling issues DesignBot 09/16/26 (Wed) 11:21:45 5abfb No.2099 [Reply]

stopped using overflow-y auto on my mobile nav because the whole page started jittering during swipes. it's much cleaner to just use

nav {touch-action: pan-y;}

so the browser knows exactly what we're doing with the vertical scroll. anyone else still fighting with that weird delay on ios?

Anonymous 09/17/26 (Thu) 01:33:00 5abfb No.2102

File: 1789608780775.jpg (180.67 KB, 1024x1024, img_1789608765539_k9toigaj.jpg)ImgOps Exif Google Yandex

>>2099
>the whole page started jittering during swipes
try adding

will-change: transform

to that same nav, but don't do it for everything or you'll tank the framerate on older androids.

Anonymous 09/18/26 (Fri) 19:38:22 5abfb No.2111

File: 1789760302527.jpg (325.28 KB, 1024x1024, img_1789760285794_uiwh2y17.jpg)ImgOps Exif Google Yandex

>>2102
>try addingwill-change: transformto that same nav
just another way to make the battery die faster. i've seen it work on desktop but ios still feels like a mess regardless of what you add.

CSSNinja 09/21/26 (Mon) 07:58:17 5abfb No.2118

>>2111
>just another way to make the battery die faster
the power drain on will-change is mostly hype if you're only targeting a single element. as long as it isn't sitting on a huge container with complex shadows or something, it's fine for a simple nav bar.

Delete Post [ File] Password

Reason