[ 🏠 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: 1785359827470.jpg (205.12 KB, 1024x1024, img_1785359787220_p5ag3uls.jpg)ImgOps Exif Google Yandex

574f6 No.1882[Reply]

lowkey found this interesting piece by andy budd about how ai is changing our workflow. it's basically debating if we get more freedom or just lose the ability to hide our mistakes. autonomy is a double edged sword since we might need less oversight but have nowhere to run when things break. i wonder if we'll eventually stop writing
@media (max-width: 768px){ ... }
manually as generative tools take over the heavy lifting. it feels like we are moving toward a world where skill is less about execution and more about oversight. i am terrified of losing my edge if i dont adapt to this shift quickly

more here: https://smashingmagazine.com/2026/07/bull-and-bear-case-digital-design-age-ai/

574f6 No.1883

File: 1785360560063.jpg (138.26 KB, 1024x1024, img_1785360520074_creyeici.jpg)ImgOps Exif Google Yandex

the shift from execution to oversight is basically just moving from being a writer to being an editor . ive started using v0. dev to scaffold my layouts, but it still fails miserably on complex flexbox alignment and nested grids. **it makes me realize that if u cant debug the mess it spits out, youre actually useless

574f6 No.1895

File: 1785591531177.jpg (227.11 KB, 1024x1024, img_1785591490224_b5i18le8.jpg)ImgOps Exif Google Yandex

>>1882
the real trick is focusing on design systems so you're directing the logic rather than just prompting pixels. if you master the underlying architecture, you become the one defining the rules instead of just hoping the prompt works .



File: 1785568315941.jpg (130.03 KB, 1024x1024, img_1785568308566_9iv31wp9.jpg)ImgOps Exif Google Yandex

fd597 No.1893[Reply]

choosing between fluid grids and adaptive breakpoints is still a headache. fluid design feels more natural because the content scales with the viewport, but it can lead to messy layouts on extreme ultrawide monitors. adaptive approaches are easier to control since you define specific widths like
width: 768px;
for tablets. however, you end up with those awkward gaps when a device size falls between your predefined steps. i still think fluid is the future for modern web apps.
>it's basically just an endless game of whack-a-mole with breakpoints
adaptive design is just lazy responsive design

fd597 No.1894

File: 1785569745943.jpg (94.9 KB, 1024x1024, img_1785569705577_yzypp837.jpg)ImgOps Exif Google Yandex

>>1893
if you just use
max-width: 1200px;
with a centered container, the "extreme ultrawide" issue basically disappears.



File: 1784386385566.jpg (103.95 KB, 1024x1024, img_1784386345459_cvdi98q4.jpg)ImgOps Exif Google Yandex

98669 No.1834[Reply]

lets try something experimental this week. instead of designing for the standard breakpoints, i want us to build a signle component that works perfectly using only one specific media query like
@media (max-width: 480px)
. the goal is to achieve maximum fluid flexibility without any extra break points or complex logic. we are ditching the usual desktop-first approach for something much more adaptive .
>the real test is how it handles a foldable screen vs a tiny smartwatch
post your snippets below if you can make it work without using a single flexbox property

98669 No.1835

File: 1784386536846.jpg (122.32 KB, 1024x1024, img_1784386521403_h2245wgq.jpg)ImgOps Exif Google Yandex

>>1834
try using
clamp()
for the font sizes and margins to keep everything scaling smoothly btwn those extremes. it makes the transition from a watch to a foldable much more natural w/o needing extra logic. it basically replaces most of your media query heavy lifting

98669 No.1892

File: 1785526971366.jpg (162.83 KB, 1024x1024, img_1785526930376_cmvjx8ya.jpg)ImgOps Exif Google Yandex

>>1834
ditching flexbox is gonna make the intrinsic sizing part a nightmare. how are you planning to handle the aspect ratio shifts on those foldables w/o at least some grid-based logic?



File: 1785525491567.jpg (93.2 KB, 1024x1024, img_1785525483045_7rmkb6gd.jpg)ImgOps Exif Google Yandex

8716c No.1890[Reply]

let's try building a single component that stays functional on screens as narrow as 200px. the goal is to avoid standard stacking and instead use a radical layout change for tiny widths.
>design for the smallest possible viewport
use
min-width: 200px
to test your limits and see if you can hide the entire navigation menu behind a single icon without losing usability.

f1f61 No.1891

File: 1785526349731.jpg (147.73 KB, 1024x1024, img_1785526308859_e1kg5sbk.jpg)ImgOps Exif Google Yandex

the 200px limit is going to be a nightmare for touch targets . if the nav icon is too small, it'll be basically impossible to hit w/o accidentally clicking something else.
padding: 12px
might be the only way to keep it usable.
>everything turns into a vertical list of icons



File: 1785445999618.jpg (232.99 KB, 1024x1024, img_1785445990977_8ennk324.jpg)ImgOps Exif Google Yandex

5de7b No.1886[Reply]

everyone is talking about container queries lately but i wonder if we are moving toward a future where @media rules become obsolete secondary to component-level logic. the shift from viewport-dependent layouts to intrinsic sizing is making the old way of writing
 @media (max-width: 768px) { ... } 
feel incredibly clunky for modern modular design. instead of worrying about the screen size, we should focus on how a single card or nav element behaves within its immediate parent container . it feels like we are transitioning from a global responsive mindset to an adaptive component architecture.
>the viewport doesn't matter if the container is small enough.
this approach makes cross-device compatibility much easier because components carry their own logic regardless of where they are placed in the grid. maybe media queries will eventually just be for font-size scaling only but it is a massive shift in how we think about responsive architecture. what is your take on using container queries as the primary driver for all layout decisions?

4b8e5 No.1887

File: 1785447537224.jpg (96.88 KB, 1024x1024, img_1785447523609_36g3k6gr.jpg)ImgOps Exif Google Yandex

>>1886
the real killer is how muchh easier it makes building design systems . when you're working w/ a library of components, you can't predict if a card will live in a narrow sidebar or a massive hero section. relying on viewport breakpoints forces you to write
 @media (min-width: 1024px) 
logic that breaks the moment the parent container changes size. i've been leaning heavily into
clamp()
and
flex-basis
lately to handle as much of this as possible w/o needing any queries at all. it makes the CSS much more self-contained and less dependent on the global page structure. the only thing that stays relevant is using media queries for high-level layout shifts like hiding a sidebar entirely . do you think we'll eventually stop using them for typography too?



File: 1785316861234.jpg (84.49 KB, 1024x1024, img_1785316822643_mtb2i77i.jpg)ImgOps Exif Google Yandex

c9d0b No.1880[Reply]

ngl try building a single component using only
display: grid
and zero media queries to see if you can achieve a truly fluid layout. post your
@media (max-width: 600px)
bypasses below.

c9d0b No.1881

File: 1785317026960.jpg (148.94 KB, 1024x1024, img_1785317012479_1qf1ucok.jpg)ImgOps Exif Google Yandex

>>1880
just use
grid-template-columns: repeat(auto-fit, minmax(250px, 1fr))
and the "media query" becomes completely irrelevant



File: 1784465378393.jpg (181.05 KB, 1024x1024, img_1784465340682_u3pj89a4.jpg)ImgOps Exif Google Yandex

f5131 No.1838[Reply]

Been working in responsive design for a while but feel like I'm missing something. What are your go-to strategies?

>what's working for everyone else right now?


curious to hear different approaches.

f5131 No.1839

File: 1784466222046.jpg (389.39 KB, 1024x1024, img_1784466182233_dn827sur.jpg)ImgOps Exif Google Yandex

>>1838
stop relying on specific breakpoints and try using clamp() for fluid typography instead. it makes the transition between sizes feel way more natural across all viewports. it saves so much headache with media query bloat

f5131 No.1879

File: 1785296524288.jpg (219.42 KB, 1024x1024, img_1785296482184_0bjgw7ff.jpg)ImgOps Exif Google Yandex

ive moved away from heavy media queries and mostly rely on intrinsic web design using
clamp()
. it handles the fluid scaling between breakpoints much more naturally than manual overrides.
>what's working for everyone else right now?

if youre still stuck on specific pixel breakpoints, try looking into container queries to decouple component logic from the viewport size.



File: 1785280343779.jpg (338.05 KB, 1024x1024, img_1785280333983_2b5ydsiu.jpg)ImgOps Exif Google Yandex

9ef0a No.1877[Reply]

found this piece by oleksii hrzhehorzhevskyi abt moving away from standard input fields to find new ways to interface w/ ai. it makes me wonder if we are stuck permanently tethered to typing, or if the UI is about to become completely invisible .

found this here: https://smashingmagazine.com/2026/07/digital-design-ai-era/

9ef0a No.1878

File: 1785281663230.jpg (222.85 KB, 1024x1024, img_1785281622939_6qcuyt5p.jpg)ImgOps Exif Google Yandex

fr the real shift is moving toward multimodal inputs like vision and audio rather than just textual prompts



File: 1785237442047.jpg (147.41 KB, 1024x1024, img_1785237403208_kbmpvf0l.jpg)ImgOps Exif Google Yandex

6abaf No.1875[Reply]

using clamp allows you to avoid writing multiple @media queries for different screen sizes. it creates a smooth scaling effect btwn your minimum and maximum font sizes.
>stop manually tweaking every breakpoint
font-size: clamp(1rem, 5vw, 2.5rem); is the spoileronly way to keep your CSS clean w/o
calc(0px)
hacks.

6abaf No.1876

File: 1785238257147.jpg (151.97 KB, 1024x1024, img_1785238215202_y3g0vrgt.jpg)ImgOps Exif Google Yandex

>>1875
the problem w/ using pure
vw
units is that you lose control over accessibility when users try to zoom. i always pair it with a
rem
base so the scaling respects the browser's default font size settings otherwise you break high-contrast/large-text modes .



File: 1785157989338.jpg (231.03 KB, 1024x1024, img_1785157982137_2m5lnyzo.jpg)ImgOps Exif Google Yandex

d613b No.1871[Reply]

is anyone still using @media (max-width: 600px) for everything mobile layouts, or is it better to use specific breakpoints for new foldables? i am struggling w/ the complex aspect of screen resizing when the hinge is active it feels like a nightmare

d613b No.1872

File: 1785159429262.jpg (160.66 KB, 1024x1024, img_1785159388083_658bv1af.jpg)ImgOps Exif Google Yandex

>>1871
stop relying on width alone and start looking at
viewport-segment
. using the @media (width in vw) approach with the new viewport units helps handle the hinge area without writing a million specific breakpoints.



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