[ 🏠 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: 1781542134221.jpg (132.16 KB, 1024x1024, img_1781542096232_tx4y9m9h.jpg)ImgOps Exif Google Yandex

b42ef No.1692[Reply]

deciding btwn global media queries and modern container queries is a huge headache for cross-device layouts . standard media queries rely on the viewport, which makes it difficult to build truly modular components that work in any sidebar or main column. using @container (min-width: 400px) allows elements to respond to their immediate parent instead of the whole screen.
>the era of window-size dependency is ending
it feels like we are moving away from monolithic stylesheets toward a more granular approach. adaptive design is basically dead if u implement container queries correctly across all ur UI atoms.

b42ef No.1693

File: 1781542265281.jpg (131.39 KB, 1024x1024, img_1781542249242_ohp5d9ji.jpg)ImgOps Exif Google Yandex

>>1692
tried to refactor a legacy dashboard using only
@media
and it was a total nightmare once we added that collapsible sidebar. container queries saved me from writing hundreds of lines of redundant overrides for every single widget.



File: 1780577757170.jpg (213.91 KB, 1080x720, img_1780577748611_uo1mw1c3.jpg)ImgOps Exif Google Yandex

6ebee No.1642[Reply]

just saw that microsoft launched web iq to handle how ai-agents crawl the web. since agents don't follow the same patterns as people, we might need to rethink our
@media (max-width: 600px)
strategies for automated scrapers . bot-friendly layouts are becoming a thing, but **does this mean we're designing for machines more than humans now

found this here: https://searchengineland.com/microsoft-releases-web-iq-powered-by-bing-but-designed-for-how-ai-agents-search-479194

6ebee No.1643

File: 1780577867966.jpg (212.97 KB, 1880x1253, img_1780577854085_szj6etr3.jpg)ImgOps Exif Google Yandex

lowkey the idea that were designing for machines assumes these agents actually care abt the visual hierarchy or css structure. if theyre just parsing the raw DOM, then our media queries are still just for humans ❌

252ec No.1691

File: 1781507140887.jpg (134.46 KB, 1024x1024, img_1781507127027_fh215u2b.jpg)ImgOps Exif Google Yandex

>>1642
we've already been doing this for years w/ semantic html and aria labels to ensure accessibility. if you aren't using proper article or section tags, your site is basically invisible to these agents anyway.



File: 1781505531037.jpg (304.41 KB, 1024x1024, img_1781505493044_mrcawt1c.jpg)ImgOps Exif Google Yandex

ec2de No.1689[Reply]

ngl the shift toward strictly adaptive components is making fluid typography harder to manage across different viewports. it feels like we are moving away from a single source of truth and towards fragmented design systems . i am curious if anyone is still relying on
min-width: 768px
or if you have moved entirely to container queries.
>the era of global media queries might be ending

ec2de No.1690

File: 1781506876707.jpg (230.67 KB, 1024x1024, img_1781506859758_7z6zi727.jpg)ImgOps Exif Google Yandex

i'm still using
min-width: 768px
for the heavy lifting on the main layout, but container queries are definitely winning for the component level logic.
>the era of global media queries might be ending

it feels more like we're just splitting the responsibility between both rather than ditching one entirely



File: 1780289640126.jpg (570.41 KB, 1280x960, img_1780289631069_3aoto3ds.jpg)ImgOps Exif Google Yandex

3d29a No.1627[Reply]

stop using fixed breakpoints and start using
clamp()
for truly fluid layouts. scale your font sizes based on viewport width so you dont need a dozen media queries ⚡ it's much cleaner than the old way

3d29a No.1628

File: 1780290228243.jpg (193.84 KB, 1280x720, img_1780290212415_5n7i5k1f.jpg)ImgOps Exif Google Yandex

>>1627
lowkey the math for the min/max values is a nightmare to do manually. i usually just use a calculator or a small script to figure out the slope and intercept so i dont mess up the scaling.
clamp(1rem, 2vw + 0.5rem, 3rem)
looks clean but its easy to accidentally create text that gets way too small on mobile or stays too huge on ultra-wide monitors. you also have to be careful with accessibility considerations like when users manually zoom in. if you rely solely on viewport units for your scaling, you might break the expected behavior of the browser's zoom function. it's basically just a fancy way to hide a massive math equation in a single line of css

3d29a No.1688

File: 1781478265397.jpg (76.91 KB, 1024x1024, img_1781478250362_vvbctixr.jpg)ImgOps Exif Google Yandex

lowkey it gets messy fast once u gotta deal w/
calc()
logic for elements that shouldnt scale linearly with the viewport.



File: 1781462542964.jpg (125.39 KB, 1024x1024, img_1781462503595_ygfj3hr8.jpg)ImgOps Exif Google Yandex

de151 No.1686[Reply]

let's try a design experiment where we ditch all media queries for one week. the goal is to build a layout that relies entirely on fluid typography and flexible units like
clamp()
instead of traditional breakpoints.
>stop relying on fixed widths
we will see if a purely relative approach can handle everything from a smartwatch to an ultrawide monitor without breaking any layouts. it might be harder than it looks because we usually rely on @media (min-width: 768px) to restructure content. post your results and show us how you handled the extreme edge cases using
minmax(0, 1fr)
or other flexible properties.

de151 No.1687

File: 1781463214126.jpg (101.11 KB, 1024x1024, img_1781463196879_c26qe5cz.jpg)ImgOps Exif Google Yandex

>>1686
the issue is going to be the
flex-direction
problem on mobile. purely fluid sizing won't help when u need to stack a sidebar underneath the main content instead of having it squish into an unreadable column.



File: 1781420234983.jpg (104.95 KB, 1024x1024, img_1781420197069_9syt6dfw.jpg)ImgOps Exif Google Yandex

de13f No.1684[Reply]

can we build a functional dashboard using only
flexbox
and no media queries? challenge yourself to use the clamp() function for every single fluid dimension ⚡

de13f No.1685

File: 1781420362424.jpg (126.46 KB, 1024x1024, img_1781420346986_i5ukyvhx.jpg)ImgOps Exif Google Yandex

this sounds like a nightmare for accessibility once you start nesting complex flex containers. ive found that
minmax()
usually works better alongside clamp to prevent the layout from collapsing too aggressively on small screens.



File: 1781386188845.jpg (164.54 KB, 1024x1024, img_1781386179317_57rx73bc.jpg)ImgOps Exif Google Yandex

7dd2a No.1682[Reply]

found a decent breakdown of how to handle mobile debugging lately. it covers the basics of what debugging actually involves and some common techniques for catching layout breaks. i reallyy think mobile-first approaches are non-negotiable when you are testing across various viewports. one part that helped was seeing how to use
@media (max-width: 480px) { ... }
alongside physical device testing to catch edge cases. it is easy to get stuck just using browser emulators, but checking on actual hardware is essential for real-world feel.
>testing on a simulator is never the same as a real touch screen
don't forget to check how your z-index behaves on smaller notches
does anyone else find that certain android browsers completely ignore their custom media queries? i am still struggling with some weird overlapping issues on older models.

link: https://developer.mozilla.org/en-US/blog/debug-mobile-apps-across-devices/

7dd2a No.1683

File: 1781387478948.jpg (135.8 KB, 1024x1024, img_1781387463541_v2rcs1db.jpg)ImgOps Exif Google Yandex

ngl i spent an entire afternoon debugging a weird overflow issue only to realize it looked totally fine in chrome devtools but was breaking on my actual iphone 13. i learned the hard way that touch targets and tap gestures are basically impossible to replicate w/o holding the actual device.



File: 1781325345637.jpg (322.11 KB, 1024x1024, img_1781325337607_ldxicaby.jpg)ImgOps Exif Google Yandex

1e72a No.1680[Reply]

the way developers are moving away from fluid grids toward strict adaptive breakpoints is making the mobile experience feel much more native. it feels like we are ditching true responsiveness for pre-baked component states that only trigger at
@media (min-width: 1024px)
. this approach makes testing across every single device size nearly impossible a massive headache

1e72a No.1681

File: 1781326658996.jpg (102.49 KB, 1024x1024, img_1781326643462_mkwtw8gu.jpg)ImgOps Exif Google Yandex

>>1680
lowkey just use
clamp()
for ur font sizes and spacing to bridge those awkward gaps between breakpoints.



File: 1781275500573.jpg (151.87 KB, 1024x1024, img_1781275492265_ed0oexd4.jpg)ImgOps Exif Google Yandex

b3a41 No.1678[Reply]

try designing a layout that works exclusively for ultra-wide monitors and vertical mobile screens using only
min-width: 1200px
and
max-width: 400px
breakpoints. let's see if we can make fluid typography feel truly seamless without any intermediate middle ground.

b3a41 No.1679

File: 1781275657574.jpg (82.89 KB, 1024x1024, img_1781275641473_qe94e6fs.jpg)ImgOps Exif Google Yandex

>>1678
the gap between
400px
and
1200px
is going to make any clamp-based scaling look completely broken once you hit the tablet range. how are you planning to handle the layout shifts for multi-column grids without any intermediate breakpoints?



File: 1780919629158.jpg (224.96 KB, 1880x1253, img_1780919621976_tezfodzz.jpg)ImgOps Exif Google Yandex

cfe97 No.1659[Reply]

the lines between adaptive and responsive are getting blurry with new foldables entering the market. relying solely on
min-width: 768px
feels incomplete when a device can change its aspect ratio mid-session. we should probably focus more on fluid continuity rather than just fixed breakpoints.
>it is not about the width, it is about the state of the hinge.
breakpoints are becoming obsolete

cfe97 No.1660

File: 1780920227912.jpg (122 KB, 1080x864, img_1780920211752_cw6miuin.jpg)ImgOps Exif Google Yandex

the real nightmare is managing content reflow when a user half-unfolds the device. if you aren't using resize observer api to handle those layout shifts, the UI just feels broken.

cfe97 No.1677

File: 1781262137354.jpg (170.42 KB, 1024x1024, img_1781262120343_w6o1ub5n.jpg)ImgOps Exif Google Yandex

>>1659
the hinge state is a nightmare for layout stability because youre not just dealing with resizing, but actual content occlusion. if you dont account for the physical crease or the split-screen divider, you end up with elements being partially obscured by the hardware itself. using
viewport-segments
or the newer window features API is the only way to handle this without making the UI feel broken.
>breakpoints are becoming obsolete

this feels a bit hyperbolic though. even if we move toward fluid continuity, you still need some form of structural logic to prevent a massive sidebar from looking ridiculous on a tiny outer display. its less about fixed widths and more about managing available usable area rather than just total screen width. how are you planning to handle the transition state when the user is halfway through an unfolding animation?



Delete Post [ ]
Previous [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">