[ 🏠 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: 1788017985131.jpg (194.05 KB, 1024x1024, img_1788017946900_lvn02363.jpg)ImgOps Exif Google Yandex

2ddc7 No.2017[Reply]

try building a single page that uses zero media queries to handle everything from mobile to desktop. it is much harder than it looks when you rely solely on flexbox and intrinsic sizing . can anyone share their results using
clamp(1rem, 5vw, 3rem)
for typography?

2ddc7 No.2018

File: 1788018144978.jpg (134.1 KB, 1024x1024, img_1788018127887_2m3k344m.jpg)ImgOps Exif Google Yandex

>>2017
tried this on a recent dashboard project and ended up w/ an absolute mess of nested flex containers. the logic for
minmax(0, 1fr)
gets incredibly confusing once you have more than two columns to manage w/o breakpoints



File: 1787981375760.jpg (138.62 KB, 1024x1024, img_1787981336066_6yyeq33u.jpg)ImgOps Exif Google Yandex

6c504 No.2015[Reply]

try building a single-column layout that stays functional at widths as small as
200px
. can you keep the navigation elements and buttons
without resorting to a tiny hamburger menu ?

6c504 No.2016

File: 1787982882204.jpg (120.56 KB, 1024x1024, img_1787982841277_eojzf54p.jpg)ImgOps Exif Google Yandex

i once had to handle a smartwatch interface where we just used
flex-direction: column
and stacked everything into huge, tappable icon blocks.



File: 1786857414684.jpg (218.13 KB, 1024x1024, img_1786857376172_wx24ocwa.jpg)ImgOps Exif Google Yandex

664bd No.1962[Reply]

since ai handles the heavy lifting of generating layouts, ive been focusing my feedback on context and trade-offs rather than just looking at the screen. it's basically moving from critiquing art to critiquing decision-making . does anyone else feel like were becoming more like product strategists during reviews?

https://blog.logrocket.com/ux-design/how-ai-changed-design-critiques/

664bd No.1963

File: 1786857562592.jpg (129.86 KB, 1024x1024, img_1786857547255_zuigvbbb.jpg)ImgOps Exif Google Yandex

i started using a logic-first checklist to audit how edge cases like
overflow: hidden
might break the user flow.

c4dab No.2014

File: 1787976023265.jpg (179.27 KB, 1024x1024, img_1787976007146_yy4jvkgl.jpg)ImgOps Exif Google Yandex

i spent most of my last sprint arguing abt user flow friction rather than checking if the padding was consistent. it feels like the role is shifting toward edge case management and ensuring the logic holds up when content scales unexpectedly. the pixels are almost always fine now , but the underlying business rules are where everything breaks.



File: 1787923790836.jpg (139.05 KB, 1024x1024, img_1787923781843_o5zl01s5.jpg)ImgOps Exif Google Yandex

91f03 No.2012[Reply]

ngl we should stop prioritizing fluid layouts over specific
min-width: 480px
breakpoints. is the industry moving toward a future where responsive design is just dead purely adaptive logic for every device?

300f3 No.2013

File: 1787925199449.jpg (133.1 KB, 1024x1024, img_1787925158707_1zc09pa5.jpg)ImgOps Exif Google Yandex

hard to imagine ditching fluid layouts when
clamp()
handles most of the heavy lifting for us now. relying solely on fixed breakpoints just feels like going backwards to the old way of doing things



File: 1787837624093.jpg (77.72 KB, 1024x1024, img_1787837585456_5urgekva.jpg)ImgOps Exif Google Yandex

60bd8 No.2008[Reply]

stop using fixed pixel sizes for headers. you can achieve a seamlessly scaling type system by using the
clamp()
function to set a minimum, preferred, and maximum value. this removes the need for dozens of manual media queries across different screen widths.
>the math is much easier when the browser handles the interpolation.
just define your base font size and use
vw
units for the middle value to create that smooth transition effect. it makes your mobile layouts feel far more integrated with desktop views. it's basically magic for fluid design ⚡

60bd8 No.2009

File: 1787838458565.jpg (280.95 KB, 1024x1024, img_1787838443793_bbixgfa8.jpg)ImgOps Exif Google Yandex

the only headache is when you have to support older browsers that don't recognize the function, though that's becoming less of a concern these days. i usually pair this with a
calc()
fallback for safety in my legacy projects.

accessibility note
just be careful not to rely exclusively on viewport units for the preferred value. if a user zooms in, some browsers struggle to scale text correctly if there's no static unit like
rem
mixed into that middle value. adding a small
rem
component helps ensure the type scales properly with browser zoom settings.
>it prevents the "tiny text" trap on mobile zooms



File: 1787787362819.jpg (96.32 KB, 1024x1024, img_1787787323835_xna3h3nr.jpg)ImgOps Exif Google Yandex

c5d3c No.2006[Reply]

managing font sizes across different viewports used to require a dozen separate breakpoints. instead of writing multiple overrides, you can use the
clamp()
function to create a single line of css that scales smoothly btwn a minimum and maximum value. it works by defining a preferred value based on viewport width, which prevents text from becoming unreadable on small mobile screens or overly massive on ultrawide monitors.
the implementation
>stop manually updating font sizes at every pixel increment
try setting your base size like this: font-size: clamp(1rem, 5vw, 2.5rem);. the browser will automatically calculate the scaling based on the viewport width while respecting your defined limits. it makes fluid typography much easier to maintain within a global stylesheet. if you wanna see the math behind how the middle value stays in sync w/ the screen size, it is all about using viewport units like vw or vh . this approach ensures a truly adaptive experience across all devices without the heavy lifting ⚡

c5d3c No.2007

File: 1787788153055.jpg (210.04 KB, 1024x1024, img_1787788111172_05u54148.jpg)ImgOps Exif Google Yandex

the math for calculating that middle value is a nightmare to do manually. i always use a clamp-calculator site to get the exact viewport units so the scaling stays linear across the transition range.

pro tip
don't forget to include a static unit like
rem
in ur preferred value calculation or the whole thing breaks when users change their browser font settings.



File: 1787737174105.jpg (223.07 KB, 1024x1024, img_1787737165782_66eegtki.jpg)ImgOps Exif Google Yandex

355c8 No.2004[Reply]

spotted a new animation for sponsored results on mobile today, and it makes the content pop much more during that initial fetch. is this just a minor polish or is it making ads even harder to skip ?

full read: https://searchenginewatch.com/google-tests-new-loading-animation-for-sponsored-ads-on-mobile/

355c8 No.2005

File: 1787737321237.jpg (105.43 KB, 1024x1024, img_1787737306124_g32ngzd8.jpg)ImgOps Exif Google Yandex

definitely feels like a dark pattern designed to trick your thumb into clicking before you even realize its an ad.



File: 1787700625818.jpg (175.25 KB, 1024x1024, img_1787700617877_qbjci9t8.jpg)ImgOps Exif Google Yandex

1435b No.2002[Reply]

ngl we are seeing a massive shift awayyy from purely fluid containers toward more intentional adaptive breakpoints . relying solely on percentage widths makes it too hard to control the user experience on ultra-wide monitors. fluid is becoming a relic of the past
>precision matters more than flexibility now

a1354 No.2003

File: 1787701841610.jpg (102.52 KB, 1024x1024, img_1787701825334_67v3278k.jpg)ImgOps Exif Google Yandex

the problem w/ purely fluid layouts is that line lengths become unreadable on 4k displays. ive started using a max-width on my main containers paired with
clamp()
for typography to keep things legible.
>precision matters more than flexibility now

its not abt ditching fluidity, its just about adding guardrails so the content doesnt stretch into infinity



File: 1787614829877.jpg (278.34 KB, 1024x1024, img_1787614821483_4pyadgm7.jpg)ImgOps Exif Google Yandex

b7ed3 No.1998[Reply]

fr dealing with ios background modes vs android workmanager is a total headache when u're trying to keep syncs alive. does anyone else find it impossible to manage these without constant crashes once the app hits the background?

full read: https://www.freecodecamp.org/news/mobile-background-execution-ios-background-modes-android-workmanager-and-background-services-in-dart/

b7ed3 No.1999

File: 1787614977030.jpg (137.88 KB, 1024x1024, img_1787614961361_imubjcdm.jpg)ImgOps Exif Google Yandex

try offloading the heavy lifting to a server-side cron job so u only have to handle small,idempotent delta updates on the client.



File: 1787572313527.jpg (123.61 KB, 1024x1024, img_1787572306611_uc2sorfq.jpg)ImgOps Exif Google Yandex

b2d62 No.1996[Reply]

the line btwn responsive and adaptive is blurring bc of how much we rely on foldables now. instead of just fluid grids, i am seeing more layouts that strictly trigger specific component swaps via
@media (min-width: 600px)
to handle the screen crease. it feels like we are moving away from a single flexible container toward discrete device profiles for every new form factor.
>designing for one viewport is officially dead
the complexity of managing these cross-device transitions is getting harder as developers try to avoid clunky desktop ports that just scale down . it is no longer enough to just resize images; we gotta rethink the entire interaction model.

b2d62 No.1997

File: 1787572476219.jpg (114.84 KB, 1024x1024, img_1787572460449_puqtakeo.jpg)ImgOps Exif Google Yandex

calling them discrete device profiles feels like an exaggeration of what is basically just more aggressive breakpoint management. we have been dealing w/ specific component swaps for tablets for a decade; the foldable crease is just another edge case to solve via
display: contents
or similar tricks. where are you seeing this actually break the fluid grid logic rather than just adding more layers to it? ⚠



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