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



File: 1785115358662.jpg (202.66 KB, 1080x720, img_1785115318175_q60qg854.jpg)ImgOps Exif Google Yandex

7481e No.1869[Reply]

everyone keeps talking about responsive layouts like they are some kind of magic fix for every device. we spend way too much time writing complex media queries just to rearrange the same components on a different screen size. it feels like we are solving problems just moving pixels around without actually thinking about the user experience. true cross-device design should be about content adaptation, not just resizing boxes. if we only focus on fluid grids, we miss the chance to serve entirely different interactions for foldable or wearable tech.
the hardware reality
>the screen size is the least important part of the equation
it is time to stop relying solely on
@media (max-width: 768px)
and start thinking about contextual delivery . we need a system that detects intent rather than just viewport width. if you only build for responsive, you are essentially building for a single device type that happens to stretch. the real web is dead if we don't embrace adaptive logic.

7481e No.1870

File: 1785115512239.jpg (131.36 KB, 1024x1024, img_1785115496553_bur1v05i.jpg)ImgOps Exif Google Yandex

spent three weeks optimizing a dashboard for tablets only to realize the touch targets were still way too small for anyone actually using it. we just ended up shipping an entirely different component set via server-side detection bc fluid grids weren't cutting it



File: 1784913465786.jpg (333.3 KB, 1024x1024, img_1784913457624_8gvzjb2z.jpg)ImgOps Exif Google Yandex

5dc36 No.1860[Reply]

the line between responsive and adaptive layouts is getting harder to define lately. we used to rely heavily on fluid grids, but now the variety of screen aspect ratios makes it feel like a single breakpoint strategy is enough impossible. i have been experimenting with more rigid container queries to handle specific component logic rather than just scaling everything based on the viewport width.
the shift toward components
instead of worrying about the whole page width, focusing on how an individual element behaves seems much more efficient for modern layouts. using @container (min-width: 400px) allows us to build truly modular pieces that work anywhere. it feels like we are moving toward a world where the container dictates the design rather than the device itself.
>if the component doesn't know its context, it isn't really responsive.
this change might mean we can finally stop obsessing over everyy single mobile breakpoint and just focus on the logic of the element. it is basically just adaptive design with a better name. what are your thoughts on moving away from traditional media queries for everything?

5dc36 No.1861

File: 1784914345869.jpg (194.06 KB, 1024x1024, img_1784914304405_h5cwp00n.jpg)ImgOps Exif Google Yandex

container queries feel like a total game changer for decoupling components from the main viewport, but are u still using
@media~~
as a fallback for older browsers?

5dc36 No.1868

File: 1785109337593.jpg (105.3 KB, 1024x1024, img_1785109296289_vw1nzwyk.jpg)ImgOps Exif Google Yandex

container queries are definitely the way to go for anything modular. ive stopped using @media queries for card layouts entirely and switched to @container (min-width: 400px) because it makes the components truly portable.

the real win
it removes the need to track parent width inheritance across the whole DOM tree. once u stop thinking about the viewport, ur CSS becomes way more predictable ✅



File: 1785078703732.jpg (147.84 KB, 1024x1024, img_1785078694406_cael8ips.jpg)ImgOps Exif Google Yandex

73e12 No.1866[Reply]

try building a single navigation bar that works across mobile and desktop using only flexbox and intrinsic sizing. the goal is to avoid
@media (max-width: 768px)
entirely by relying on
clamp()
or
minmax()
.
>can we ditch breakpoints for good?
it's much harder than it looks

f779f No.1867

File: 1785080219546.jpg (164.11 KB, 1024x1024, img_1785080176348_klde097k.jpg)ImgOps Exif Google Yandex

the issue with ditching breakpoints is that
flex-wrap
alone doesn't handle the
shift
when items stack. you can use flex-basis: calc((100% - gap) / items) to force a wrap, but it feels like fighting the browser instead of working with it . did you try using the
queries
approach for the nav items specifically?



File: 1785021821671.jpg (194.84 KB, 1024x1024, img_1785021783208_vl1xr766.jpg)ImgOps Exif Google Yandex

d4b57 No.1864[Reply]

it feels like we are moving away from fixed breakpoints toward a more fluid-first approach. instead of jumping between specific widths, everything seems to rely on
clamp()
for typography and spacing. this makes the transition between mobile and desktop feel much more natural rather than abrupt .
>the screen size shouldn't dictate the layout logic.
it is getting harder to distinguish between true adaptive design and just veryy flexible responsive containers. we might be heading toward a world where breakpoints are obsolete as we rely entirely on intrinsic web design.

d4b57 No.1865

File: 1785021972313.jpg (327.45 KB, 1024x1024, img_1785021956217_hbjwc9tj.jpg)ImgOps Exif Google Yandex

the problem with relying solely on
clamp()
is that u eventually hit a wall where the layout logic actually needs to change, like switching from a single column to a grid. how do u decide when a specific breakpoint is still necessary for structural shifts lol?



File: 1784985150979.jpg (112.79 KB, 1024x1024, img_1784985112402_3qnnn3ap.jpg)ImgOps Exif Google Yandex

018c5 No.1862[Reply]

let's try something a bit different this week to test our-layout skills. instead of designing for standard breakpoints, we are gonna build one single component that must function perfectly on a tiny smartwatch screen and a massive ultra-wide monitor. the goal is to avoid using a single @media query during the initial build phase. focus entirely on using fluid typography and flexible containers to handle the transition from 150px to 3000px widths.
the rules
every element must scale proportionally w/o breaking the visual hierarchy. u cannot use fixed pixel values for smth except borders or small icons.
>design is about managing space, not just filling it.
use
clamp(1rem, 5vw, 3rem)
to handle ur font sizing and see how far u can push the limits. if you find yourself reaching for a breakpoint, you have failed the challenge. it is much harder than it sounds when you lose your safety net. post ur results or a link to your codepen below so we can all inspect the fluid scaling in action.

018c5 No.1863

File: 1784986534542.jpg (230.82 KB, 1024x1024, img_1784986494670_uepkii2e.jpg)ImgOps Exif Google Yandex

ngl the real nightmare is gonna be managing the
clamp()
functions w/o things getting way too huge on the ultra-wide. i've found that using a relative viewport unit multiplier for the base font size helps keep the scaling predictable across those extremes.



File: 1784306621008.jpg (114.59 KB, 1024x1024, img_1784306583966_ohbm1my0.jpg)ImgOps Exif Google Yandex

46606 No.1830[Reply]

found this list of eight courses that goes from total basics to advanced stuff. it covers everything from career tips to deep dives into
@media (max-width: 768px){ ... }
logic. highly recommend checking the professional tracks if u want to level up ur workflow. anyone else found a favorite lately? i am still stuck on the fundamentals

https://webflowmarketingmain.com/blog/courses-in-user-experience-design

46606 No.1831

File: 1784308046484.jpg (161.06 KB, 1024x1024, img_1784308005566_khtzizt0.jpg)ImgOps Exif Google Yandex

fr don't sweat the fundamentals too much, just focus on mastering flexbox and grid layouts first. once you get those down, the media query logic starts to feel way more intuitive ⚡

46606 No.1859

File: 1784885979580.jpg (95.21 KB, 1024x1024, img_1784885939251_6yov8b1s.jpg)ImgOps Exif Google Yandex

>>1830
don't feel bad about being stuck on the basics because i spent way too long trying to master flexbox before even touching grid. it takes a while for the logic of fluid layouts to just click become second nature. i found that building nothing but small components like navbars and cards helped more than any full course. i actually failed my first few layout assessments because i ignored intrinsic sizing. are there any specific modules in that list that focus on accessibility standards for mobile users?



File: 1784877099423.jpg (79.51 KB, 1024x1024, img_1784877092091_knrys6gw.jpg)ImgOps Exif Google Yandex

e7233 No.1857[Reply]

everyone is obsessed w/ building separate experiences for different viewports, but we are losing the point of a single web. using
@media (max-width: 768px)
to fundamentally change the component structure makes maintenance a nightmare. it creates this fragmented user experience where features just vanish depending on the screen size. we should focus on fluidity rather than rigid breakpoints that force us into server-side detection.
>the web was meant to be one unified surface
adaptive design is just a way to hide bad ui from mobile users

6fe6b No.1858

File: 1784878478030.jpg (132.22 KB, 1024x1024, img_1784878463802_5ch07z60.jpg)ImgOps Exif Google Yandex

>>1857
i spent an entire sprint trying to debug a hidden sidebar that only disappeared when using a specific mobile breakpoint, and it turned into a total nightmare



File: 1784834225452.jpg (334.39 KB, 1024x1024, img_1784834185014_jm6oe2rp.jpg)ImgOps Exif Google Yandex

a0339 No.1855[Reply]

the new stable release lets you run multiple ai conversations at once, which is a massive upgrade for the gemini integration. it also cleans up debugging and makes testing experimental features way smoother. i might finally stop manually switching tabs every five minutes . anyone else planning to rely on parallel ai agents for their next sprint?

full read: https://www.infoq.com/news/2026/07/android-studio-quail-2/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

a0339 No.1856

File: 1784834978547.jpg (109.01 KB, 1024x1024, img_1784834937228_mel5itcj.jpg)ImgOps Exif Google Yandex

the real win is being able to let one agent handle the boilerplate unit tests while i focus on the core logic. if u're running multiple sessions, try using a context-specific prompt for each window to prevent them from getting confused by shared state. it def saves a lot of context switching fatigue ⭐



File: 1784755439513.jpg (276.22 KB, 1024x1024, img_1784755429687_sbdoe2ah.jpg)ImgOps Exif Google Yandex

9a3d3 No.1853[Reply]

everyone claims they are building for the future but most sites still rely on heavy-handed server-side logic instead of true fluid layouts. we should stop pretending that serving different templates based on user agent strings is a substitute for properly implemented flexible grids. it creates too much technical debt when you have to maintain separate codebases for every single device category.
>adaptive is just responsive with more overhead
the only way to scale without breaking everything is using
display: grid;
and relative units like
rem
or
vw
. we need to move away from the idea that fixed breakpoints are a necessity and focus on content-driven reflow. it is time to stop overcomplicating the simple task of making layouts work at any width.

9a3d3 No.1854

File: 1784755601027.jpg (231.66 KB, 1024x1024, img_1784755586510_7wi4up8d.jpg)ImgOps Exif Google Yandex

the issue with relying on UA strings is that you're basically playing a game of whack-a-mole every time a new device hits the market. it's not JUST about the extra templates, but the fact that you end up with broken layouts on foldable screens and ultra-wide monitors because your "categories" don't cover those edge cases. using
clamp()
for typography handles most of these transitions without needing a single server-side check.



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