R: 2 / I: 1
does anyone have a specific layout that's currently breaking because of this?
intrinsic sizing with min-width on text elements
been seeing way too many people using fixed widths for containers that hold long strings of text. it's making everything break when someone inputs a massive name or a weirdly long product title. let's try an experiment this week and replace those static values with intrinsic sizing like min-content or max-content to see if we can stop the overflow mess..card-title {width: min-content;}does anyone have a specific layout that's currently breaking because of this?
R: 0 / I: 0
max-width on desktop containers
another day of fixing broken layouts because someone thinks mobile first means ignoring how things look on a 32 inch monitor. we're stuck using some massive max-width: 1440px; hack that makes the whole site look like garbage on ultrawide displays.
R: 1 / I: 0 fine unbearable when the rhythm is off like this.
has anyone figured out a way to scale the tracking and line-height together without breaking the vertical rhythm?
letter spacing on narrow viewports
i'm losing my mind with this line-height on mobile. i tried using a media query to tighten up the tracking for small screens so the text doesn't look like it's falling apart, but now the descenders are hitting the line below. it looks messy and totally unpolished. i even tried adjusting the letter-spacing via a clamp function but that just makes the kerning feel all wonky on larger tablets. it's@media (max-width: 480px) {p {letter-spacing: -0.02em;line-height: 1.2;}}has anyone figured out a way to scale the tracking and line-height together without breaking the vertical rhythm?
R: 2 / I: 1
aspect ratio on object fit
trying to fix that weirdly stretched logo look on mobile. using object fit cover is fine until the crop cuts off the actual brand name. switching back to aspect ratio on the img tag handles it way better without extra wrapper divs. tbh just use the property and stop overcomplicating things with container hacks
R: 3 / I: 2
tbh it makes the fluid stuff way easier than manual overrides
clamp for font sizing
stop using media queries for every single font size change. use clamp to let the text scale between a min and max value so you don't have to manage fifty different breakpoints for typography.font-size: clamp(1rem, 5vw, 2.5rem);
tbh it makes the fluid stuff way easier than manual overrides
R: 2 / I: 0
fixed pixel widths in media queries
i was looking at some old client handoffs today and it's honestly so frustrating when devs still hardcode specific pixel breakpoints instead of letting the content dictate where the layout breaks. it makes the whole experience feel brittle because you end up with these weird gaps or awkward text wrapping on anything that doesn't hit those exact dimensions. we should be designing for ranges of content rather than trying to predict every single device width out there. do you guys find yourselves fighting against fixed breakpoints in your current sprints?
R: 0 / I: 0
anyone still using margin-left for everything?
logical properties for margin and padding
i'm tired of seeing people hardcode margin-left everywhere like we aren't writing internationalized sites. if you're swapping to rtl layouts, using margin-inline-start saves a massive headache with your stylesheets. it's way cleaner than rewriting every single media query just to flip the direction..card {margin-inline-start: 20px;padding-inline-end: 15px;}anyone still using margin-left for everything?
R: 1 / I: 0
>the design process kept growing while the time left for making the product kept shrinking.
It's weird because the heavy lifting on components and assets feels like it's being automated away, leaving only the high-level strategy or the tiny manual tweaks. I don't see how we maintain any consistency if nobody is actually building out the middle layers anymore.
more here: https://uxdesign.cc/ai-is-hollowing-out-the-middle-of-design-leaving-an-hourglass-behind-b7069db250fd?source=rss----138adf9c44c---4
designers stuck at the ends of the workflow
The middle part of the process is basically disappearing.>the design process kept growing while the time left for making the product kept shrinking.
It's weird because the heavy lifting on components and assets feels like it's being automated away, leaving only the high-level strategy or the tiny manual tweaks. I don't see how we maintain any consistency if nobody is actually building out the middle layers anymore.
more here: https://uxdesign.cc/ai-is-hollowing-out-the-middle-of-design-leaving-an-hourglass-behind-b7069db250fd?source=rss----138adf9c44c---4
R: 0 / I: 0
percentage based width vs calc for gutter spacing
tried switching all my margin-right values to percentage units to match the container flow. it's a nightmare when you have an element with a fixed border-width because the math just breaks. using margin-right: calc(10% - 20px) is much more predictable than pretending percentages work for everything. tbh just stick to calc if you want things to actually line up without a headache
R: 1 / I: 0
It keeps things from lookingstretched pixelated when the viewport gets massive.
max-width on heavy images
Been seeing too many people setting width to 100% without any max-width. It makes the image huge on desktop monitors and just looks broken. I usually stick to this for my main hero assets:img {width: 100%;max-width: 800px;}It keeps things from looking
R: 0 / I: 0
tbh it feels like the browser is just ignoring the tracks when the parent has dynamic content. i've tried setting a fixed min-height on the rows but that's a terrible hack for a fluid layout. some weird overlap happening with the footer too.
subgrid alignment issues with uneven content
trying to get my cards to align their headers perfectly but the content height is all over the place. even with subgrid enabled on the child items, it's not grabbing the row tracks from the parent correctly. i tried setting the grid-template-rows to match the main container but everything just collapses..card {display: grid;grid-template-rows: subgrid;}tbh it feels like the browser is just ignoring the tracks when the parent has dynamic content. i've tried setting a fixed min-height on the rows but that's a terrible hack for a fluid layout. some weird overlap happening with the footer too.
R: 0 / I: 0 hacky heavy for a simple hero. has anyone actually found a way to make this consistent without breaking the layout on safari?
viewport height issues on mobile safari
i'm working on this landing page for a client and it's driving me crazy. the hero section keeps jumping around when the address bar hides or shows while scrolling. i tried using height: 100vh; but that just makes the bottom of the image get cut off by the browser ui. i even tried switching to height: 100dvh; like everyone says, but now my footer is acting all weird and overlapping the content on some older ios versions. ngl it's a mess right now. been trying to use a little bit of javascript to calculate the actual window height manually but that feels so
R: 1 / I: 0
tbh seeing people still manually adjusting column counts in css is painful. it's just extra code to maintain and prone to breaking when the content changes. never use fixed columns unless you actually want a broken layout on mobile. stick to the minmax approach and save yourself the headache.
grid template columns vs auto-fit for card layouts
been fighting with a client's weird grid requirements all morning. they want cards to just "work" without manual media queries for every single breakpoint. i tried using auto-fill but it leaves those massive, awkward gaps on the right side of the screen when you don't have enough items to fill a row. honestly auto-fit is much better because it stretches the tracks to cover the space. just set your column width with a minmax value and let the browser handle the math. it's way cleaner than writing out five different media queries for different screen sizes.grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
tbh seeing people still manually adjusting column counts in css is painful. it's just extra code to maintain and prone to breaking when the content changes. never use fixed columns unless you actually want a broken layout on mobile. stick to the minmax approach and save yourself the headache.
R: 0 / I: 0
Using inline size for layout shifts
I'm tired of seeing huge jumps when images load. Just set the width and height directly on the img tag so the browser can calculate the space before the pixels actually arrive.<img src="hero.jpg" width="800" height="450" style="width: 100%; height: auto;">
R: 3 / I: 2
using svh for mobile layouts
I'm tired of seeing people use 100vh on mobile because the URL bar always breaks it. It leaves that annoying white space at the bottom when the browser UI shrinks or expands. Just switch to svh if you don't want the layout jumping around..hero {height: 100svh;} 
R: 0 / I: 0
>it works everywhere regardless of screen size
that's literally the point of a component-driven workflow. if you aren't using them yet, you're basically just making life harder for yourself. it's not that hard to learn. i hate seeing codebases where every single margin adjustment is tied to the global window width.
it's just better logic for modern layouts. what's your go-to strategy for handling component padding in dense grids?
container queries for simple padding tweaks
i'm so tired of seeing people jump straight to media queries just to fix a tiny bit of internal spacing. it makes no sense when you've got a component that lives in both a sidebar and a main content area. if the container is narrow, the padding should shrink regardless of the viewport size. i've been using @container for months now and it's much cleaner. you don't end up with this massive mess of breakpoints that only apply to one specific element.>it works everywhere regardless of screen size
that's literally the point of a component-driven workflow. if you aren't using them yet, you're basically just making life harder for yourself. it's not that hard to learn. i hate seeing codebases where every single margin adjustment is tied to the global window width.
@container (min-width: 300px) {.card {padding: 2rem;}}it's just better logic for modern layouts. what's your go-to strategy for handling component padding in dense grids?
R: 1 / I: 0
aspect-ratio for image placeholders
Images loading late always breaks my layout because the page jumps around while the browser calculates the height. I've started setting aspect-ratio on the img tag itself so the space is reserved before the actual file downloads. It keeps things stable and prevents that annoying layout shift during page load.img {width: 100%;aspect-ratio: 16 / 9;object-fit: cover;} 
R: 2 / I: 0
>flex-basis: 30%
it looks fine until the content hits a certain point and then the whole row just collapses into nothing lol. i guess i'll just go back to using min-width for everything like a caveman. at least it doesn't break the entire grid
flex basis vs width for responsive columns
trying to fix this broken layout and honestly just using width is such a headache when things get crowded. i tried switching everything to flex-basis but now my columns are doing that weird thing where they shrink way too much on small screens. it's basically pure chaos once you add padding to the containers.>flex-basis: 30%
it looks fine until the content hits a certain point and then the whole row just collapses into nothing lol. i guess i'll just go back to using min-width for everything like a caveman. at least it doesn't break the entire grid
R: 2 / I: 2
min-content width on flex items
been fighting with this all morning because some designer thinks everything should just shrink to fit. setting width to min-content is great until your text wraps into a single vertical column of letters. it's basically pure chaos if you don't pair it with a proper min-width or some decent padding..card {width: min-content;flex: 1 1 auto;} 
R: 3 / I: 3
article: https://webdesignerdepot.com/web-designers-love-dark-mode-toggles-users-might-not-care/
another thing for designers to obsess
spent way too much time building that sun-and-moon button in my last header only to realize users probably don't even notice it. most people just rely on their system settings anyway so having a permanent toggle taking up space is pretty pointless. i'm tired of seeing these little UI ornaments that don't actually add value for anyone not working in web design. do you guys actually keep the toggle visible or do you just hide it in a settings menu?article: https://webdesignerdepot.com/web-designers-love-dark-mode-toggles-users-might-not-care/
R: 0 / I: 0
it keeps the tiny aesthetic but makes it usable. does anyone actually use a different value for their minimum tap area?
touch target size for mobile buttons
i'm tired of seeing tiny little icons that nobody can actually tap without hitting something else. it's such an easy way to break a site on mobile. let's try an experiment this week where we strictly enforce at least 44px for every interactive element, even if the visual icon looks smaller. i've been playing around with using pseudo-elements to expand that hit area without messing up the layout..icon-button::after {content: '';padding: 12px;position: absolute;}it keeps the tiny aesthetic but makes it usable. does anyone actually use a different value for their minimum tap area?
R: 0 / I: 0
It's much more predictable for the grid logic.
media query for orientation changes
I'm tired of seeing people use @media (orientation: landscape) to fix layout issues on mobile. It breaks everything when someone rotates their tablet or uses a foldable device in the wrong way. Stick to fixed breakpoints based on screen width instead.@media (max-width: 600px) {.sidebar {display: none;}}It's much more predictable for the grid logic.
R: 2 / I: 0
container queries for card components
I'm moving away from media queries for component styling since it's such a headache when you drop a card into a sidebar. Just use @container with inline-size instead of trying to guess the viewport width..card-container {container-type: inline-size;}@container (min-width: 400px) {.card {display: flex;}} 
R: 3 / I: 1
has anyone dealt with this when using a flexbox layout for the main content?
overflow x on nested scroll containers
im trying to fix this weird horizontal wobble on a side drawer but it's driving me crazy. i tried setting overflow-x hidden on the parent wrapper but now the inner content just cuts off mid-sentence. looks like 'scroll-snap-type' is messing with how the container calculates its width..drawer-inner {overflow-x: auto;scroll-snap-type: x mandatory;}has anyone dealt with this when using a flexbox layout for the main content?
R: 0 / I: 0
>it's so much cleaner
the logic is basically that you stop thinking about sides and start thinking about edges. it makes the whole layout much more resilient to different text directions. does anyone else still use margin-right for everything?
logical properties for margins and padding
been cleaning up some old legacy stylesheets lately. i'm tired of seeing margin-left everywhere when we're doing localization. it's such a headache once you start supporting rtl languages. if you use margin-inline-start instead, the browser handles the flip for you automatically. no more writing duplicate media queries just to swap left for right. it works exactly the same for padding too. i used to rely on margin-left: 20px for everything, but it's a nightmare once the client asks for arabic support.>it's so much cleaner
.card {margin-inline-start: 1rem;padding-inline-end: 2rem;}the logic is basically that you stop thinking about sides and start thinking about edges. it makes the whole layout much more resilient to different text directions. does anyone else still use margin-right for everything?
R: 2 / I: 1
does anyone actually use intrinsic sizing for anything other than simple buttons?
min-content for text wrapping
i'm tired of seeing people use fixed widths on small components like badges or tags. if you just use min-content it shrinks everything down to the widest single word instead of letting it stretch weirdly across the container. works great for those little labels that shouldn't look like giant rectangles unless your words are all one syllable..badge {width: min-content;text-align: center;}does anyone actually use intrinsic sizing for anything other than simple buttons?
R: 0 / I: 0
percentage width on images
I'm tired of seeing people use 100% width for everything. It breaks whenever you have padding or borders unless you're using box-sizing: border-box properly everywhere. Just use max-width: 100% instead so the image doesn't stretch out and get blurry on huge screens.img {max-width: 100%;height: auto;} 
R: 1 / I: 0
works fine on desktop but it breaks the tap area size on mobile safari sometimes.easy annoying fix if you forget to set a min-width. lets see if anyone has a clean way to handle the checked state without adding extra css bloat.
input type checkbox styling on ios safari
im sick of seeing those giant default checkboxes that look nothing like the rest of the ui. its so hard to make them actually match your brand colors without breaking everything. im trying a little experiment this week using appearance: none and custom svg backgrounds instead of the usual hacky way.input[type="checkbox"] {appearance: none;background-image: url('check.svg');}works fine on desktop but it breaks the tap area size on mobile safari sometimes.
R: 2 / I: 0
subpixel rendering on high dpi screens
been staring at this blurry text all morning. it's driving me nuts how some fonts look fine on desktop but get all fuzzy when you scale them for retina displays. i tried setting text-rendering: optimizeLegibility; but it didn't really do much for the weight of the characters. anyone else dealing with this weird subpixel smearing lately?
R: 0 / I: 0
z-index stacking on sticky headers
im losing my mind because some dev used z-index 9999 on a random popup and now it's hiding behind the sticky nav. its literally just basic layering and if you dont manage your stacking context properly everything breaks. im not even kidding, just use a proper layer system instead of guessing numbers lmao.
R: 2 / I: 2
rem units for viewport width transitions
I'm not seeing any real benefit to switching from fixed pixels to rems for these transitions. I've run this test on Chrome mobile for a week and the layout jumps are still there, so I need to see some actual data showing it actually smooths things out.
R: 3 / I: 1
>set height: 60px;
never do this if you want your nav to actually work on different screen densities without clipping text. anyone else just using min-height and letting the padding do the heavy lifting?
fixed height on mobile nav bars
i'm tired of seeing developers set a hard 60px height on every single header. it's such a mess when you actually have a multi-line logo or some weirdly sized utility icon that breaks the layout.>set height: 60px;
never do this if you want your nav to actually work on different screen densities without clipping text. anyone else just using min-height and letting the padding do the heavy lifting?
R: 3 / I: 2 flexbox grid is way more predictable for anything involving images and text wraps. i hate how much boilerplate you need just to get a basic responsive card working right. it's ridiculous.
intrinsic sizing for images in flex containers
been fighting with flexbox alignment all morning. tried to let a single image grow naturally but it just squishes everything into a tiny column. people act like flex is magic but it's actually garbage if you don't set an explicit basis. i ended up using flex-basis: content on the parent container to stop the shrink. also found that setting min-width: 0 on the flex item is basically mandatory if there's any text involved. otherwise the overflow just breaks the whole layout. honestly just use grid if you can avoid this mess.
R: 0 / I: 0
anyone found a way to cap the growth without breaking the fluid feel on smaller screens?
clamp function for font size on ultra wide monitors
tried setting up a clamp with some min and max values but it's getting way too huge once you cross 2560px. it looks fine on my laptop and even a standard desktop, but the text is basically unreadable on this client's setup. i thought using a viewport width unit would scale it down properly but it just keeps growing with the screen size.font-size: clamp(1rem, 5vw, 3rem);
anyone found a way to cap the growth without breaking the fluid feel on smaller screens?
R: 1 / I: 0
percentage based width on images is a disaster
stop using width: 100% for everything and just let it break your layout. if you don't set a max-width it just stretches into infinity on ultra-wide monitors. honestly css grid handles this way better with auto-fit.grid-template-columns: repeat(auto-fit, minmax(250px, 1fr))
R: 3 / I: 3
aspect ratio on svg icons
it's driving me crazy that some devs still use fixed width/height attributes instead of letting the viewBox do its job. try replacing your hardcoded dimensions with aspect-ratio: 1/1 in your css this week and see if anything breaks.
R: 0 / I: 0 it's fine it's not fine.
does anyone actually use a specific linter rule to catch this during builds?
touch targets for interactive elements
been looking at some recent audits and it's honestly depressing how many buttons are just way too small on mobile. i saw a site yesterday where the close icon was basically microscopic. you can't expect people to have surgical precision with their thumbs on a 6-inch screen. it doesn't matter if the css layout looks clean on desktop because it's basically unusable once you actually try to tap anything. i'm starting to think we should just hardcode a minimum size for everything that isn't plain text.button,a,input {min-width: 44px;min-height: 44px;}does anyone actually use a specific linter rule to catch this during builds?
R: 1 / I: 1 unreadable exhausting to track your eyes from left to right. i always wrap my main content in a div with a
does anyone actually use more than 80 characters per line?
using max-width for text containers
tired of reading lines that stretch across the whole screen on huge monitors. it'smax-widthand some padding so the text doesn't hit the edge of the browser.
.container {max-width: 70ch;margin-inline: auto;padding-inline: 1.5rem;}does anyone actually use more than 80 characters per line?
R: 3 / I: 2
overflow x issues on mobile with inline-block elements
getting weird horizontal scrolls on some android devices even though i set overflow-x hidden on the body. tried removing the width from the child div but it still jitters when scrolling. im thinking it's some legacy issue with how certain browsers handle inline-block margins.
R: 0 / I: 0
makes the whole layout feel broken and jittery. if youre not using svh or lvh yet yous are basically asking for layout shifts every time someone scrolls. its such a mess to debug when the client sends a screenshot of it happening.
viewport height jump on mobile safari
im sick of that stupid scrollbar behavior when the address bar hides. just tried fixing it with dvh but its still jumping around weirdly during the transition. looks like some sites are still using vh for everything which is total chaos on ios. you end up with this massive white gap at the bottom of the page once the UI settles.height: 100vh;overflow: hidden;
makes the whole layout feel broken and jittery. if youre not using svh or lvh yet yous are basically asking for layout shifts every time someone scrolls. its such a mess to debug when the client sends a screenshot of it happening.
R: 0 / I: 0 huge empty space on the right side of the container when there's only one item left.
anyone know a way to force that last row to center or something?
grid template columns with auto-fit gaps
tried using auto-fit but the items aren't stretching to fill the whole row like they should. it leaves this weirdgrid-template-columns: repeat(auto-fit, minmax(200px, 1fr));gap: 20px;
anyone know a way to force that last row to center or something?
R: 1 / I: 1
it's not a magic fix for everything but it'sperfect pretty much essential for modular design. i use this specifically for card grids where the columns collapse at different breakpoints. you don't have to write fifty different media queries for every possible screen width. just define the container and let the component handle its own business. works great for those weirdly sized sidebar widgets that nobody wants to manage manually. anyone else still relying on global media queries for component styles?
container queries for font size scaling
been messing around with container queries all morning. everyone's obsessed with viewport units but they're such a nightmare when you actually nest things inside sidebars or cards. if the parent shrinks, your text stays huge and breaks everything. i stopped using @media for component typography entirely. it's much better to just scope the font size to the container itself so it scales naturally regardless of where you drop the component in the layout..card-container {container-type: inline-size;}@container (max-width: 400px) {.card-title {font-size: 1.2rem;}}it's not a magic fix for everything but it's
R: 3 / I: 2
media query breakpoints vs client viewport widths
I am tired of seeing developers set breakpoints based on arbitrary device sizes like iPhone or iPad. It is much harder to debug when your layout breaks on a random tablet width that does not match any specific breakpoint in your stylesheet. Just use the actual content boundaries to decide where things need to shift.
R: 0 / I: 0
it's much easier than managing the old padding trick. at least until the browser decides to ignore your life's work. does anyone actually still use the padding hack for anything?
aspect ratio box vs object fit cover
been messing with some old legacy layouts today. i've been trying to move away from those old padding-top hacks for aspect ratios because they're such a headache when you actually need the content to behave. using the modern aspect-ratio property is way cleaner, but it's driving me crazy when the source images aren't perfectly sized. if you don't pair it with object-fit: cover, you just get these stretched, ugly distortions that look terrible on high-density mobile screens..card-img {aspect-ratio: 16 / 9;object-fit: cover;}it's much easier than managing the old padding trick. at least until the browser decides to ignore your life's work. does anyone actually still use the padding hack for anything?
R: 0 / I: 0
using logical properties for margin and padding
tried switching everything to margin-inline and padding-block today because i'm tired of writing separate rules for ltr and rtl. it's way cleaner when you don't have to manually swap left and right values in your media queries. honestly, just use logical properties from now on so you don't break the layout when someone switches the language settings.
R: 0 / I: 0
font-size: clamp(1rem, 5vw + 0.5rem, 2.5rem);
does anyone actually use fixed rem values for body text anymore?
clamp for font size vs fixed rem units
i'm tired of manually adjusting every single breakpoint just to keep text readable on tablets. using 'clamp' makes things way smoother but it's such a headache when the scaling gets too aggressive at the edges.font-size: clamp(1rem, 5vw + 0.5rem, 2.5rem);
does anyone actually use fixed rem values for body text anymore?
R: 0 / I: 0
But now the icons aren't centering vertically with the text next to them. Is there a better way to expand the tap area using something like an invisible pseudo-element? I need it to stay strictly within the bounds of the existing icon container.
touch target size for small buttons
I'm working on this legacy mobile site and the footer icons are tiny. I tried adding padding to the anchor tags but it's messing up my flex alignment in the footer. It makes the whole row taller than it should be. I don't want to change the actual icon dimensions, just need a larger hit area without breaking the layout. I've been trying this:a {padding: 12px;display: inline-block;}But now the icons aren't centering vertically with the text next to them. Is there a better way to expand the tap area using something like an invisible pseudo-element? I need it to stay strictly within the bounds of the existing icon container.
R: 3 / I: 1
link: https://cloudfour.com/thinks/ending-responsive-images/
lazy loading might kill srcset for everything below the fold
it's wild that we can basically ditch those complex sizes attributes since the browser finally knows the layout once it hits the viewport. i'm still skeptical about how this works if we aren't using loading="lazy" on every single element, but webkit and gecko getting on board with these patches makes it feel inevitable. do you guys actually strip out your srcset logic for footer images yet?link: https://cloudfour.com/thinks/ending-responsive-images/
R: 0 / I: 0
min-content width for grid tracks
stop using 1fr for everything when you have long strings of text without breaks. it just blows out the whole layout on small screens. use min-content for that specific track so the column actually respects the content boundaries instead of stretching into infinity. tbh it saves me from writing way too many media queries.
R: 2 / I: 1
viewport units for typography
i'm tired of seeing vh used for font sizes on mobile. it makes the text jump around like crazy when the browser chrome hides or shows during a scroll. it's better to just stick to rem and let the base size handle it. has anyone actually found a way to make viewport-based type work without it looking broken?
R: 3 / I: 0
found this here: https://bradfrost.com/blog/post/big-ai-design-systems-course-updates/
tj's course updates
sixteen hours of video is getting pretty ridiculous for one course. seeing all that stuff on git and github setup makes me wonder if anyone actually cares about api keys anymore when everything is just plug and play.found this here: https://bradfrost.com/blog/post/big-ai-design-systems-course-updates/
R: 2 / I: 0
>it works fine on my iphone
yeah well that's great for you. i'm stuck dealing with this:
the whole page shifts every time the user scrolls a bit. absolute disaster for smooth animations. honestly just gonna use fixed pixels and pretend it's not broken tbh
svh vs dvh frustration
been staring at this layout for two hours because some designer thinks viewport height is a stable thing. using 100vh on mobile is such a mess when the address bar slides in and out. it just jumps everything around. tried switching to dvh but now my footer is overlapping content on safari.>it works fine on my iphone
yeah well that's great for you. i'm stuck dealing with this:
height: 100dvh;overflow-y: auto;
the whole page shifts every time the user scrolls a bit. absolute disaster for smooth animations. honestly just gonna use fixed pixels and pretend it's not broken tbh
R: 0 / I: 0
>A design system is far more than a set of pretty components
it's basically just an extension of dev experience work, like fixing CI pipelines or project structure. i don't know if we could actually pull that off without it becoming total chaos for the feature teams though.
found this here: https://tkdodo.eu/blog/designing-design-systems
design systems are more than just components
the focus on DX and infrastructure instead of just pretty pixels is interesting.>A design system is far more than a set of pretty components
it's basically just an extension of dev experience work, like fixing CI pipelines or project structure. i don't know if we could actually pull that off without it becoming total chaos for the feature teams though.
found this here: https://tkdodo.eu/blog/designing-design-systems
R: 0 / I: 0
article: https://polypane.app/blog/polypane-26-accurate-device-emulation-with-safe-area-and-small-viewport-units/
polypane finally handles svh and safe area insets
finally don't have to grab my actual iphone every time i change some padding-top: env(safe-area-inset-top); or mess with height: 100svh;. seems useful but honestly wonder if it'll actually match how safari behaves when the address bar shrinks.article: https://polypane.app/blog/polypane-26-accurate-device-emulation-with-safe-area-and-small-viewport-units/
R: 0 / I: 0
>it looks fine on my iphone
it never looks fine on everything else. just use padding and let the element expand naturally. anyone still using px for header heights?
fixed height on mobile navbars
i'm tired of seeing developers hardcode height: 60px on every mobile header. it's such a mess when someone adds a tiny bit of padding or an icon that doesn't scale right. you end up with text clipping through the bottom of the bar or just looking totally broken. if the content inside grows, the whole layout breaks. never use fixed heights for anything containing dynamic text.>it looks fine on my iphone
it never looks fine on everything else. just use padding and let the element expand naturally. anyone still using px for header heights?
R: 1 / I: 1
>it looks fine on desktop
it never looks fine on mobile. switching to contain works for preserving the whole image but then you're left with these ugly letterboxing gaps that break the vibe. i've been trying to use a fallback system with some specific padding, but it's a mess to maintain. anyone actually making 'contain' work without it looking broken?
object-fit cover vs contain for hero banners
been messing with some client assets all morning and it's driving me nuts. using cover is usually the default but it's such a lazy way out when the subject matter actually matters. i had this one shot where the top of a person's head kept getting cropped off because the container height changed on mobile.>it looks fine on desktop
it never looks fine on mobile. switching to contain works for preserving the whole image but then you're left with these ugly letterboxing gaps that break the vibe. i've been trying to use a fallback system with some specific padding, but it's a mess to maintain. anyone actually making 'contain' work without it looking broken?
R: 0 / I: 0
more here: https://polypane.app/blog/using-safe-area-inset-to-build-mobile-safe-layouts/
handling notch cutouts with env variables
always hated how floating buttons end up stuck behind the home indicator on ios. saw some stuff about using safe-area-inset to fix that mess. it's not like actual margins though so you can't just slap it on a div and call it a day. you basically have to pad the body or whatever if you don't want content getting clipped by the dynamic island. polypane seems to be the go-to for testing this properly since emulating the actual hardware is such a pain. i saw a snippet using env with a fallback value like 1rem just in case things break. it's pretty standard stuff but still annoying that we can't just ignore these cutouts anymore. feels like every new phone makes our css more complicated for no reason. anyone actually using the max-inset variables for anything besides extreme edge cases?more here: https://polypane.app/blog/using-safe-area-inset-to-build-mobile-safe-layouts/
R: 3 / I: 0
input type text width fix
i'm tired of seeing mobile layouts break because some dev forgot to set max-width to 100 percent on text inputs. it's such a simple way to stop your form fields from bleeding off the side of the screen on small devices. do you guys just reset them all globally in your base css or handle it per class?
R: 0 / I: 0 mess disaster when the images stretch way too far across the screen. i've been sticking to a simple max-width combo lately:
does anyone actually still use percentage for the actual image element itself?
percentage width vs max-width for image containers
i'm tired of seeing people just use width: 100% on everything. it makes the desktop view look like a.container {width: 100%;max-width: 800px;}does anyone actually still use percentage for the actual image element itself?
R: 3 / I: 2
touch-action for scrolling issues
stopped using overflow-y auto on my mobile nav because the whole page started jittering during swipes. it's much cleaner to just usenav {touch-action: pan-y;}so the browser knows exactly what we're doing with the vertical scroll. anyone else still fighting with that weird delay on ios? 
R: 0 / I: 0
aspect ratio on nested flex items
been fighting with aspect ratio on some flex items all morning. someone decided to use flex-basis 100% but forgot that aspect ratio doesn't play nice when the content inside grows unexpectedly. it just stretches the box and breaks the whole grid layout. i ended up having to wrap everything in a div with overflow hidden just to keep the proportions sane. honestly if we didnt have flexbox we might actually have predictable layouts. feels like every time i think i have a handle on intrinsic sizing something else breaks the aspect ratio calculation. turns out setting width: 100% is still the only way to stop it from being weird sometimes.
R: 1 / I: 1
logical properties for margin and padding
client wants me to use margin-inline instead of margin-left everywhere so we can support rtl without rewriting the whole stylesheet. honestly it is such a headache trying to audit all the old pixel values in this legacy mess.
R: 1 / I: 1
tap targets for thumb reach
been looking at my recent mobile builds and realized i'm still putting too many interactive elements in the top left corner. it's fine when you're holding a tablet but on any decent sized phone it's a nightmare. i keep forgetting that people actually use their thumbs to navigate. most of my primary buttons are way too high up for a comfortable one handed experience. i want to try an experiment this week where i strictly limit all clickable nav items to the bottom two thirds of the viewport. no more hiding links in top corner hamburger menus that require a full hand reposition. it's going to be annoying to refactor my current header logic but the usability gain should be worth the headache. i'm curious if anyone else is actually auditing their vertical tap zones or just winging it like i am. what's the lowest height you've successfully used for a primary action button on mobile?
R: 1 / I: 1
container queries for component padding
I'm tired of using media queries to fix padding on nested cards when the parent container is what actually changes size. Using @container is much more predictable once you set up a wrapper with a specific size..card-wrapper {container-type: inline-size;}@container (max-width: 400px) {.card {padding: 10px;}} 
R: 3 / I: 3
gap: clamp(1rem, 2vw + 0.5rem, 3rem);
It works pretty well for standard card layouts in CSS Grid. It's much cleaner than writing out three different margin overrides. it actually saves a ton of lines in my stylesheets
clamp for gap sizes
I'm tired of managing massive lists of media queries just to tweak spacing between cards. It gets messy when you have different containers at different widths. Instead of jumping through hoops with breakpoints, try using the clamp function for your grid gaps. It makes the spacing scale naturally with the viewport without any extra logic. Just set a minimum value and a preferred value based on viewport width.gap: clamp(1rem, 2vw + 0.5rem, 3rem);
It works pretty well for standard card layouts in CSS Grid. It's much cleaner than writing out three different margin overrides. it actually saves a ton of lines in my stylesheets
R: 2 / I: 1 fluid grids can solve everything when the real issue is desktop-first thinking . if your layout relies on
adaptive design is just a fancy way to say lazy
we should stop pretending thatmax-width: 1200pxinstead of true fluid proportions, you arent actually building for cross-device reality ⚠
R: 0 / I: 0
Intrinsic sizing on flex basis
Been wrestling with this one client project all week. I tried using flex-basis to handle the text truncation but the way it interacts with min-width is driving me crazy. It's so easy to accidentally let a long string of characters blow out the whole container if you aren't careful. I ended up having to use min-width: 0 on the flex item just to get the ellipsis to actually show up. Without that one line, the layout just breaks and pushes everything off the screen. It's such a tiny thing but it's easy to overlook when you're moving fast..flex-item {flex: 1 1 0%;min-width: 0;} 
R: 1 / I: 1 modern smart developers actually use percentages or intrinsic sizing so things don't just clip into nothingness. it's such an amateur move to ignore how the viewport actually behaves. what's your go-to for preventing that horizontal overflow mess?
fixed width containers are still ruining everything
someone told me today that we should just use width: 1200px; for the main wrapper because it's "easier to track". i can't even. it's not easier when you're staring at a broken horizontal scroll on a small tablet. if you aren't using max-width, you're basically just making a desktop site and hoping for the best.
R: 0 / I: 0 broken weird when it shrinks, just use width: min-content. it keeps the box from getting wider than its longest word and prevents that awkward single-character line break mess.
tbh most people overcomplicate this with unnecessary media queries when you could just let the intrinsic size do the work
using min-content for text wraps
stop trying to force everything into a grid with fixed columns. if you have a label or a button that looks.label {width: min-content;white-space: nowrap;}tbh most people overcomplicate this with unnecessary media queries when you could just let the intrinsic size do the work
R: 1 / I: 1
more here: https://webdesignerdepot.com/adobe-has-a-secret-new-design-tool-and-you-can-apply-to-test-it/
adobe's project oasis is hiding again
adobe's playing games with this project oasis thing. they're keeping everything under nda and won't show any actual features yet. it's just another web-based tool they want us to apply for. honestly doesn't matter how much hype they build if i can't even see the interface. anyone managed to get an invite yet?more here: https://webdesignerdepot.com/adobe-has-a-secret-new-design-tool-and-you-can-apply-to-test-it/
R: 1 / I: 0 magic fine but i hate how it breaks if the container is too small. let's try a challenge where we build a gallery using only aspect-ratio and no fixed heights at all.
aspect-ratio for embedded images
trying to stop that weird layout shift when my lazy images load. using aspect-ratio: 16 / 9 isimg {width: 100%;aspect-ratio: 4 / 3;object-fit: cover;} 
R: 2 / I: 1
https://zapier.com/blog/graphic-design-tools-for-social-media-images
free tools for social media visuals
found some killer free design software that saves a ton on subscriptions since visuals drive all the engagement across platforms like bluesky and tiktok. **anyone else still paying for adobehttps://zapier.com/blog/graphic-design-tools-for-social-media-images
R: 3 / I: 2
>it feels less like resizing and more like building a separate app.
**the distinction btwn responsive and adaptive is basically disappearing
adaptive layouts are getting weirdly complex
the way developers are moving away from simple fluid grids toward component-specific breakpoints is making the mobile experience feel much more intentional. instead of just scaling everything, we are seeing more logic likedisplay: none;used to swap out entire interaction patterns for smaller screens.
>it feels less like resizing and more like building a separate app.
**the distinction btwn responsive and adaptive is basically disappearing
R: 3 / I: 3 lose their minds double up on outputs when they reconnect. it focuses on preventing stale approvals and keeping the stream clean using a specific pattern for event_log_sync. mobile-first syncing is definitely the way to go, but i wonder if this scales well for massive multi-agent swarms ].
article: https://hackernoon.com/designing-reconnect-safe-event-streams-for-remote-coding-agents?source=rss
handling agent disconnects without losing data
found this interesting approach to managing event logs so remote agents don'tarticle: https://hackernoon.com/designing-reconnect-safe-event-streams-for-remote-coding-agents?source=rss
R: 1 / I: 1
>the concept of a fixed breakpoint is becoming obsolete
it is making the old way of writing media queries for every single device size feelcompletely necessary quite redundant. we are essentially building containers that breathe based on available viewport width. this means we might not even need mobile-firsts as a strict rule soon because the layout adapts naturally without manual intervention. it is a massive shift in how we think about cross-device design patterns.
death of the mobile breakpoint
noticed something weird while auditing a few recent site builds. developers are moving away from traditional breakpoints and leaning much harder into fluid typography and intrinsic sizing. instead of defining specific widths, we are seeing more reliance onclamp(1rem, 5vw, 3rem)to handle scaling. this makes the transition between a small smartphone and a tablet feel seamlessly smooth rather than jumpy. it feels like the industry is finally moving toward a truly liquid layout approach where content dictates the space.
>the concept of a fixed breakpoint is becoming obsolete
it is making the old way of writing media queries for every single device size feel
R: 1 / I: 1
fluid layouts vs adaptive components
is it better to rely on a singlewidth: 100%approach or move toward component-levelness with specific breakpoints? >adaptive is much easier for testing
R: 1 / I: 1
found this here: https://uxplanet.org/can-gpt-6-actually-do-ux-design-1fe818e91794?source=rss----819cc2aaeee0---4
Can GPT-6 Actually Do UX Design?
GPT-6 Astra can create impressive prototypes. I've tested this AI model for creating mobile layouts:found this here: https://uxplanet.org/can-gpt-6-actually-do-ux-design-1fe818e91794?source=rss----819cc2aaeee0---4
R: 1 / I: 1
>if it breaks, you lose.
the catch is that the typography needs to scale perfectly without any manual font-size resets . try using fluid typography techniques to make the text feel natural on a tiny smartwatch screen or a massive monitor. post your results and the specific
ultra-minimalist layout challenge
lets try something weird for a week. the goal is to design a single landing page using zero media queries and no fixed widths. everything must rely onclamp()or
calc()functions to handle transitions between mobile and desktop.
>if it breaks, you lose.
the catch is that the typography needs to scale perfectly without any manual font-size resets . try using fluid typography techniques to make the text feel natural on a tiny smartwatch screen or a massive monitor. post your results and the specific
font-sizelogic you used below.
R: 1 / I: 1 obsolete ? it feels like we are moving away from viewport-driven layouts entirely
death of media queries?
is anyone still relying on @media (max-width: 768px) for everything, or is the move toward container queries finally making traditional breakpoints
R: 1 / I: 1
full read: https://www.creativebloq.com/tech/laptops/best-ai-laptops-for-motion-design-and-vfx
found some decent ai laptops for motion/vfx work
mobile-first power is the only way to handle these renders without a desktop, but im wondering if anyone has actually tested them on a heavy timeline . smooth playback depends so much on the hardware specs.full read: https://www.creativebloq.com/tech/laptops/best-ai-laptops-for-motion-design-and-vfx
R: 2 / I: 2
>it feels more like maintenance hell than design
i wanna avoid re-writing every single media query from scratch every time a new aspect ratio drops. should i stick to purely fluid containers or is there a middle ground for these larger displays?
handling adaptive vs responsive for foldable devices
i am struggling w/ how to approach layouts for new foldables. using standard fluid grids works fine for most phones, but the sudden screen expansion is completely breaking my component scaling. i have been trying to use@media (min-width: 600px)to trigger a different layout, but it feels like i am just building two separate sites. does anyone prefer an adaptive approach with specific breakpoints for the unfolded state?
>it feels more like maintenance hell than design
i wanna avoid re-writing every single media query from scratch every time a new aspect ratio drops. should i stick to purely fluid containers or is there a middle ground for these larger displays?
R: 1 / I: 1 outdated when dealing with ultra-wide monitors. instead of jumping btwn fixed steps, everything is moving toward a more continuous scaling approach using
>the era of rigid breakpoints is ending
it feels like we are finally moving awayyy from designing for specific devices and towards designing for fluid viewport density . **adaptive design might actually become a niche strategy for legacy systems rather than the standard approach
shift from breakpoints to fluid typography
noticed lately that standard media queries feel a bitclamp(). it makes the transition between mobile and desktop look much smoother bc there are no sudden layout shifts.
>the era of rigid breakpoints is ending
it feels like we are finally moving awayyy from designing for specific devices and towards designing for fluid viewport density . **adaptive design might actually become a niche strategy for legacy systems rather than the standard approach
R: 1 / I: 1
>design for the middle, not the edges
it will be extremely difficult to maintain hierarchy when everything is scaling dynamically. prepare to rewrite your entire css architecture if you try to use fixed widths. post your results or a link to your codepen below.
single-breakpoint challenge
let's try a design experiment where we build a complex landing page using only one media query. the goal is to see how much we can rely on flexbox and grid to handle fluid resizing w/o constant breakpoints. you must useflex-wrap: wrap;or similar logic to manage the layout transition btwn mobile and desktop.
>design for the middle, not the edges
it will be extremely difficult to maintain hierarchy when everything is scaling dynamically. prepare to rewrite your entire css architecture if you try to use fixed widths. post your results or a link to your codepen below.
R: 1 / I: 1
adaptive layouts are becoming a massive waste of resources
we are spending way too much time writing specific @media (min-width: 1200px) rules when fluid typography and flexbox should handle the heavy lifting. adaptive design is just a fancy word for doing responsive work twice
R: 2 / I: 2
>true responsiveness is about continuous scaling, not just jumping between states.
death of the breakpoint
the way we handle desktop layouts is shifting toward fluid typography instead of fixed breakpoints. developers are moving away from rigidwidth: 1200pxcontainers and relying more on
clamp()to bridge the gap between mobile and ultra-wide monitors. it makes adaptive design feel much more natural
>true responsiveness is about continuous scaling, not just jumping between states.
R: 1 / I: 1
the setup
set ur font size using three parameters: a minimum value, a preferred fluid value, and a maximum value. for example, font-size: clamp(1rem, 5vw, 2.5rem); ensures the text never gets too tiny on mobile or too massive on ultra-wide monitors. it creates an effortless transition between devices without any jumps in scale.
>stop relying on fixed pixel values for typography
this approach makes ur layout much more adaptive because the scaling happens continuously rather than at rigid breakpoints. u can apply this same logic to padding and margins to keep your white space proportional to the screen size. it basically renders traditional fluid typography media queries obsolete if you configure your math correctly. just be careful not to let your viewport unit calculation get too aggressive or your text might become unreadable on very small screens
using clamp for fluid typography without media queries
managing font sizes across different viewport widths usually involves writing a dozen separate media queries. instead of manually adjusting breakpoints, u can use theclamp()function to create a single line of CSS that scales smoothly between a minimum and maximum value. this method relies on the viewport width unit to calculate the intermediate steps automatically.
the setup
set ur font size using three parameters: a minimum value, a preferred fluid value, and a maximum value. for example, font-size: clamp(1rem, 5vw, 2.5rem); ensures the text never gets too tiny on mobile or too massive on ultra-wide monitors. it creates an effortless transition between devices without any jumps in scale.
>stop relying on fixed pixel values for typography
this approach makes ur layout much more adaptive because the scaling happens continuously rather than at rigid breakpoints. u can apply this same logic to padding and margins to keep your white space proportional to the screen size. it basically renders traditional fluid typography media queries obsolete if you configure your math correctly. just be careful not to let your viewport unit calculation get too aggressive or your text might become unreadable on very small screens
R: 2 / I: 2
the implementation
first, ensure the parent element has a defined
>the layout stays consistent regardless of the viewport size.
it makes testing much easier bc you only need to resize the parent container rather than the entire browser window. it basically renders traditional media queriesobsolete for component architecture. using this approach ensures your design remains fluid and adaptive across every possible device configuration.
modern container queries for component-driven layouts
stop relying solely on viewport width to dictate your layout logic. if you are building a library of reusable components, using @media queries means the element only knows abt the screen size, not its actual space. instead, try using @container rules to make elements react to their immediate parent. this allows a card component to switch from a single column to a horizontal layout based on whether it is sitting in a narrow sidebar or a wide main content area. ⚡the implementation
first, ensure the parent element has a defined
container-type: inline-size;property. once that is set, you can use simple media-query-like syntax to adjust children. this creates a truly modular system where components are self-contained and device-agnostic.
>the layout stays consistent regardless of the viewport size.
it makes testing much easier bc you only need to resize the parent container rather than the entire browser window. it basically renders traditional media queries
R: 1 / I: 1 clunky jumps in font size when resizing a browser window.
the setup
you just need three parameters: the minimum size, the preferred scaling value, and the maximum size. for example, font-size: clamp(1rem, 5vw, 2.5rem); handles everything in one line. the middle value uses a viewport unit to ensure the text grows as the screen expands. it is much cleaner than managing multiple @media blocks.
>stop using fixed pixel values for mobile typography
this approach ensuers your layout remains legible and adaptive without extra overhead. if you want to see how this affects container padding, just apply it to your padding property too . it makes the transition between mobile and desktop feel seamless rather than stepped.
using clamp() to fix fluid typography headaches
managing font sizes across devices usually involves a messy stack of media queries that are hard to maintain. instead of writing separate rules for every breakpoint, you can use theclamp()function to create truly fluid type. this allows the text to scale smoothly between a defined minimum and maximum value based on the viewport width. it removes the need for
the setup
you just need three parameters: the minimum size, the preferred scaling value, and the maximum size. for example, font-size: clamp(1rem, 5vw, 2.5rem); handles everything in one line. the middle value uses a viewport unit to ensure the text grows as the screen expands. it is much cleaner than managing multiple @media blocks.
>stop using fixed pixel values for mobile typography
this approach ensuers your layout remains legible and adaptive without extra overhead. if you want to see how this affects container padding, just apply it to your padding property too . it makes the transition between mobile and desktop feel seamless rather than stepped.
R: 1 / I: 1
>adaptive feels safer for data-heavy tables
the downside of adaptive is that you might miss the "in-between" sizes found on modern tablets. responsive layouts are much more future-proof because they scale dynamically without needing a new preset for every device launch. fluid is still king for simple content, but adaptive wins for complex dashboards ➡
adaptive vs fluid layouts for complex dashboards
lowkey choosing between adaptive and responsive approaches depends on how much control you need over the user experience. adaptive layouts use specific breakpoints likemax-width: 768pxto swap out entire components, which is great for maintaining strict design patterns on mobile. fluid designs rely more on relative units and flexbox to ensure content flows naturally across every single screen size.
>adaptive feels safer for data-heavy tables
the downside of adaptive is that you might miss the "in-between" sizes found on modern tablets. responsive layouts are much more future-proof because they scale dynamically without needing a new preset for every device launch. fluid is still king for simple content, but adaptive wins for complex dashboards ➡
R: 1 / I: 1
>one line of code replaces three separate breakpoints
it makes your mobile layouts feel much more organic because the text scales proportionally with the screen size. just ensure you test on very small devices so your minimum value doesn't break your layout width. it is basically magic for responsive typography
css clamp for fluid typography without media queries
stop using fixed pixel sizes for headers and embrace fluid scaling . instead of writing multiple media queries to adjust font size, you can use theclamp()function to define a minimum, preferred, and maximum value. this creates a smooth transition between viewport widths.
>one line of code replaces three separate breakpoints
it makes your mobile layouts feel much more organic because the text scales proportionally with the screen size. just ensure you test on very small devices so your minimum value doesn't break your layout width. it is basically magic for responsive typography
R: 1 / I: 1
>this removes the need for multiple media query breakpoints just for text size.
**it actually makes your css much cleaner
modern way to handle fluid typography
stop using fixed pixel sizes for font scaling across different viewports. you can achieve a smooth transition btwn mobile and desktop by using theclamp()function.
>this removes the need for multiple media query breakpoints just for text size.
**it actually makes your css much cleaner
R: 1 / I: 1
>is anyone else moving toward dedicated adaptive assets for ultra-small screens?
i'd love to avoid maintaining two entirely different codebases if possible ❓
adaptive vs responsive for wearable screens
i'm struggling with deciding between a purely responsive approach or building a separate adaptive layout for smartwatches. the current CSS@media (max-width: 300px)setup feels like it might break the usability of our complex navigation menus.
>is anyone else moving toward dedicated adaptive assets for ultra-small screens?
i'd love to avoid maintaining two entirely different codebases if possible ❓
R: 1 / I: 1
the rules
focus on container queries and the flexbox wrap behavior to handle content rearrangement. u cannot use any hardcoded pixel widths for ur main containers.
>make it fluid or make it break
if u find yourself reaching for a standard breakpoint, you have failed the challenge. the real secret is mastering the math inside clamp() so the layout feels natural on every device w/o manual intervention. post ur snippets below and show us how you handled the complex scaling logic
zero-breakpoint experiment
let's try smth different by ditching standard breakpoints entirely. the goal is to build a single component that relies purely on fluid typography and intrinsic sizing instead of fixed media queries. we will avoid using@media (min-width: 768px)or any other rigid layout shifts. everything must scale smoothly from a tiny smartwatch screen to an ultrawide monitor using only relative units like
clamp(),
vw, and
ch.
the rules
focus on container queries and the flexbox wrap behavior to handle content rearrangement. u cannot use any hardcoded pixel widths for ur main containers.
>make it fluid or make it break
if u find yourself reaching for a standard breakpoint, you have failed the challenge. the real secret is mastering the math inside clamp() so the layout feels natural on every device w/o manual intervention. post ur snippets below and show us how you handled the complex scaling logic
R: 1 / I: 1
fluid layouts vs adaptive components
is it better to rely on a singlewidth: 100%approach or switch to distinct component states for different viewports? >'adaptive might be too much overhead' but responsive is getting harder to maintain ➡
R: 1 / I: 1
full read: https://www.freecodecamp.org/news/feature-modularization-in-flutter-combine-clean-architecture-and-domain-driven-design/
scaling flutter features with clean architecture and ddd
the current setup works fine for us, but i wonder if things would completely break once we hit 20+ devs on the same repo. it feels like modularizing via ddd is the only way to avoid a massive mess . does anyone else think clean architecture is overkill for smaller squads?full read: https://www.freecodecamp.org/news/feature-modularization-in-flutter-combine-clean-architecture-and-domain-driven-design/
R: 1 / I: 1
stop using fixed widths for containers
try switching to width: min(100% - 2rem, 800px); to handle mobile scaling automatically. it makes your layouts feel much more fluid on small screens without adding extra media queries. it saves so much time in the stylesheet
R: 2 / I: 2 hide our ai usage rely on plain text to look organic anymore. designing for accessibility might get harder if the watermark messes with screen readers or automated audits. anyone else worried abt how this affects our copy audits?
more here: https://uxplanet.org/claude-watermark-explained-what-product-designers-need-to-know-3d14049ca76b?source=rss----819cc2aaeee0---4
anthropic's new invisible watermark
anthropic just dropped that claude is using an invisible statistical watermark now. it means we can't rlymore here: https://uxplanet.org/claude-watermark-explained-what-product-designers-need-to-know-3d14049ca76b?source=rss----819cc2aaeee0---4
R: 2 / I: 2
>fluid is easier for ultra-wide monitors but can break complex components.
some developers still prefer the precision of adaptive assets for mobile, even if it meansmanaging too many images dealing with a massive asset library . i find that a hybrid approach works best for most projects.
fluid vs adaptive layouts for modern web
deciding between a purely fluid approach and an adaptive strategy usually comes down to how much control you need over specific breakpoints. fluid design uses relative units likewidth: 100%to ensure everything scales smoothly across every possible viewport size. adaptive layouts are more rigid because they rely on fixed snapshots for certain devices.
>fluid is easier for ultra-wide monitors but can break complex components.
some developers still prefer the precision of adaptive assets for mobile, even if it means
R: 1 / I: 1 too rigid too slow for agile sprints?
full read: https://blog.logrocket.com/ux-design/double-diamond-design-process/
explaining the double diamond
found a good breakdown of how to use the double diamond to balance exploration versus decision-making. it covers everything from problem discovery to delivery, plus when you might need to reverse the whole thing . mobile-first workflows are way easier when you actually follow these phases instead of just jumping into the final UI. does anyone else find this framework a bitfull read: https://blog.logrocket.com/ux-design/double-diamond-design-process/
R: 1 / I: 1 destroying nuking the chips. good luck with the cosmic rays
mobile-first orbital deployment is gonna require some wild new shielding logic like:
full read: https://thenewstack.io/spacex-nvidia-orbital-ai/
spacex is taking nvidia hardware to orbit
spacex and nvidia are basically porting the nvl72 rack-scale platform into space, which means we might see massive compute power floating above us soon. it sounds cool until you realize they still gotta figure out how to stop radiation frommobile-first orbital deployment is gonna require some wild new shielding logic like:
@media (min-width: 0px) { .radiation-shielding { display: block; } }full read: https://thenewstack.io/spacex-nvidia-orbital-ai/