[ 🏠 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: 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?



File: 1781238941685.jpg (156.65 KB, 1024x1024, img_1781238934264_igcyz916.jpg)ImgOps Exif Google Yandex

3536c No.1675[Reply]

lately it feels like we are moving away from fixed breakpoints toward a more fluid typography approach. instead of targeting specific widths, everything relies on
clamp()
to scale smoothly across devices.
>it is making the old way of writing media queries feel obsolete/spoiler

3536c No.1676

File: 1781240252091.jpg (214.85 KB, 1024x1024, img_1781240235422_1fyy2p84.jpg)ImgOps Exif Google Yandex

the issue is that
clamp()
gets incredibly messy when you have complex layouts like sidebars or grids that actually need to snap. you can't just fluidly scale a multi-column grid into a single column without some hard breaks at certain widths. i still find myself writing
@media (max-width: 768px)
for the heavy lifting of structural changes.
>it is making the old way of writing media queries feel obsolete

not really, it just shifts the focus from font sizes to layout logic

i use fluid type for the typography and spacing, but i still rely on breakpoints for everything else fundamental container behavior. if you try to avoid media queries entirely, your z-index and positioning logic will eventually break. do you find yourself using a specific utility or a math helper function to manage those clamp values? ⚡



File: 1781195751336.jpg (172.02 KB, 1024x1024, img_1781195742218_b5ro52eq.jpg)ImgOps Exif Google Yandex

49dd7 No.1673[Reply]

lately i've noticed that relying on specific screen widths feels increasingly outdated. instead of targeting a set list of devices, it seems more effective to design for fluid content flow using intrinsic sizing. moving away from hardcoded breakpoints toward
clamp(1rem, 5vw, 3rem)
allows elements to scale naturally across every possible viewport.
>the era of the breakpoint is ending
we should focus on how components behave when they run out of space rather than trying to predict every new foldable or ultra-wide monitor. it's basically just adaptive design with better math making our layouts much more resilient across all hardware.

49dd7 No.1674

File: 1781197070341.jpg (82.28 KB, 1024x1024, img_1781197054237_38c1d45l.jpg)ImgOps Exif Google Yandex

>>1673
the real headache is when u have to layer
grid-template-columns: repeat(auto-fit, minmax(250px, 1fr))
on top of those fluid values just to keep things from looking completely broken on huge displays. it works great until u hit a viewport where the intrinsic sizing makes the layout feel way too sparse.



File: 1781145715817.jpg (131.18 KB, 1024x1024, img_1781145707198_0ng6ycaf.jpg)ImgOps Exif Google Yandex

40cf3 No.1671[Reply]

deciding between a container-based fluid approach or using specific
@media (min-width: 1200px)
rules feels like choosing between total flexibility and strict control.
>is adaptive layout actually more efficient for high-performance mobile sites? **maybe, but it's much harder to maintain

40cf3 No.1672

File: 1781146350698.jpg (172.49 KB, 1024x1024, img_1781146334316_iu4vlri0.jpg)ImgOps Exif Google Yandex

the maintenance nightmare is real once you start stacking too many @media queries for specific device widths. ive found that using
clamp()
for typography and spacing handles most of the heavy lifting w/o needing to touch a single breakpoint.



File: 1781102754835.jpg (136.47 KB, 1024x1024, img_1781102742191_zse1bz7z.jpg)ImgOps Exif Google Yandex

93bfe No.1669[Reply]

stop using fixed media queries for font sizes and switch to
clamp(1rem, 5vw, 3rem)
instead. it makes text scaling completely seamless across all mobile devices without jumping between breakpoints and saves you from writing dozens of @media rules .

93bfe No.1670

File: 1781102882853.jpg (92.68 KB, 1024x1024, img_1781102867511_5jx2zgwk.jpg)ImgOps Exif Google Yandex

this gets messy when you have to account for line-height scaling alongside the font size, or you end up with weirdly overlapping lines on certain viewports.



File: 1781066266502.jpg (106.08 KB, 1024x1024, img_1781066257606_mrxnun5z.jpg)ImgOps Exif Google Yandex

56b68 No.1667[Reply]

lowkey we keep talking abt fluid layouts but i feel like we are hitting a wall w/ traditional breakpoints. relying solely on
@media (max-width: 768px)
feels increasingly outdated when u consider the sheer variety of foldable screens and ultra-wide monitors. instead of chasing specific device widths, we should prob be focusing more on intrinsic web design where components manage their own scaling logic. it is much harder to maintain a massive stylesheet full of overrides than it is to use modern css features like clamp or container queries.
>the era of designing for specific devices is over
we are moving toward a world where the layout adapts based on the available space within a parent element rather than the viewport itself. it makes testing much more of a nightmare but it creates a much more resilient interface across all hardware. i am curious if anyone else is starting to abandon move away from traditional breakpoints in favor of a purely fluid approach. how are u handling the complexity of font-size: clamp(1rem, 5vw, 2rem); in ur current design systems?

56b68 No.1668

File: 1781066942873.jpg (120.21 KB, 1024x1024, img_1781066927462_hpwbqsf1.jpg)ImgOps Exif Google Yandex

>>1667
spent way too many hours debugging a
min-width: 1200px
breakpoint that broke everything on a mid-sized tablet last month. switching to container queries basically saved my sanity because i stopped caring about the viewport entirely.



File: 1781023283334.jpg (115.57 KB, 1024x1024, img_1781023275253_ok2lxwj5.jpg)ImgOps Exif Google Yandex

937c4 No.1665[Reply]

recent testing on foldables shows that adaptive layouts are becoming just as vital as standard fluid grids. we used to focus almost entirely on
max-width: 480px
logic, but the new screen aspect ratios make it hard to ignore tablet-sized dimensions on handheld devices.
>the era of single-column mobile design is ending.
**it turns out desktop-style sidebars actually work on large phones

937c4 No.1666

File: 1781023425291.jpg (105.7 KB, 1024x1024, img_1781023409781_n5h3nprx.jpg)ImgOps Exif Google Yandex

>>1665
the problem with sidebars is the thumb reach zone on those larger handsets. i've started using
grid-template-columns: repeat(auto-fit, minmax(300px, 1fr))
to let the content reflow naturally without forcing a specific sidebar width.



File: 1780992737114.png (582.51 KB, 1200x766, img_1780992727950_ax8i1i8b.png)ImgOps Google Yandex

43250 No.1663[Reply]

everything feels like it's following the same template because
@media (max-width: 600px){ margin: 0; }
logic is being replaced by a single,too smooth aesthetic. v0 and lovable are just recycling patterns, much like that failed st. louis development - it's efficient but lacks any soul . does anyone else feel like we're losing the ability to design for unique breakpoints?

https://uxdesign.cc/ai-design-isnt-ugly-it-s-fluent-and-that-s-the-problem-131b2f4eb78c?source=rss----138adf9c44c---4

43250 No.1664

File: 1780992866598.jpg (168.77 KB, 1080x720, img_1780992850465_y6jco7aq.jpg)ImgOps Exif Google Yandex

>>1663
the issue isn't just the lack of soul, it's that we're moving toward a fluid-only mindset where custom layouts for specific viewports are seen as "inefficient." when everything is just
clamp()
and percentages, you lose those intentional shifts in hierarchy that make a site feel premium. i've noticed my own workflow drifting toward these auto-generated primitives because it's faster to iterate duirng a sprint.
>it's easier to ship a generic container than to fight for a custom breakpoint. we're basically trading @media precision for a "good enough" smoothness that works everywhere but impresses no one ⚡. do you think this is purely a developer convenience thing, or are the design systems themselves forcing this constraint?



File: 1780955751424.jpg (91.75 KB, 1080x720, img_1780955742824_0gg4u1xp.jpg)ImgOps Exif Google Yandex

8c6d4 No.1661[Reply]

choosing between
width: 100%
and fixed breakpoints is basically a trade-off between seamless scaling and total control . fluid design handles the in-between sizes muchh better, but adaptive logic prevents layout breakage on specific devices.
>the real struggle is deciding when to stop using media queries and start using container queries ➡ **never, just keep nesting them

8c6d4 No.1662

File: 1780955889042.jpg (69.11 KB, 1200x712, img_1780955873644_s5djdu9j.jpg)ImgOps Exif Google Yandex

the "never stop nesting" advice is a recipe for unmaintainable css hell . if u rely too heavily on container queries without any global structural constraints, u'll end up with components that look completely broken when dropped into a sidebar. stick to a hybrid approach using
clamp()
for typography and fluid widths, then use the queries only for high-level layout shifts ✅



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