> When you resize your browser, you're not testing for responsiveness. You're testing the side effect of how a layout looks when you resize a browser.<p>Yes, but testing how the layout looks when you resize should test responsiveness or something is wrong with the design.<p>Who can do more can do less.<p>The design should not break when resizing, resizing is a legitimate action on a desktop UI, and small windows are legitimate too. If it breaks when resizing and depends on reloading, or on being loaded on a specific device, the design is fragile.<p>There's no reason the menu can't become stacked while resizing if needed, and there's no reason the content should overflow the window.<p>(now of course it's important to have all this stuff in mind, but still)
> When you resize your browser, you're not testing for responsiveness. You're testing the side effect of how a layout looks when you resize a browser.<p>A UI that is not resizable should not use the web platform. [^1]<p>If you do imperative things in reaction to viewport dimensions, it's your own responsibility to do it correctly (layout operations always need to be idempotent).<p>There is a point though: window resizing misses DPR. And missing that commonly breaks responsive UIs.<p>Maybe that's the main point of the author, but the word "side effect" is really unfortunate then.<p>[1] If you don't support some viewport sizes, you can show a hint to the user that this viewport is unsupported.
Resizing the browser is a legitimate use case. I snap browser windows to the left/right on a laptop all the time to be able to look at two things at once
Sounds like the author should start testing by resizing the browser and fix the issues that causes rather than complain about valid reports.<p>If things get cut off or not layed out correctly with a resized browser window then that's just as much as a bug as one shown in the responsive device mode. And frankly if your layout is correct in one but not the other then that's a strong hint you are doing something very very wrong and fighting the browser instead of letting it lay out things responsively.
As other's have said, there is some useful information in this article, but the approach of sizing things based on viewport size shouldn't be what we're doing in 2024 with new projects.<p>Now that we have Flexbox, CSS Grid and Container Queries and styles (among other many other features), components can resize themselves.<p>Jen Simmons talked about Intrinsic Design at least 4 years ago [1].<p>[1]: <a href="https://www.youtube.com/watch?v=jBwBACbRuGY" rel="nofollow">https://www.youtube.com/watch?v=jBwBACbRuGY</a>
The worst thing about resizing the browser is when it uses that to decide if you are a mobile user rather than user agent. Just give me the desktop version please.
Ehh. You should be <i>constantly</i> resizing your browser (as well as testing reloads at those sizes), while developing a design.<p>Not least because people do resize browsers on already-loaded pages, do tile views on their iPads, etc., and it is common-sense to deal with that.<p>I mean this bit, for example:<p><i>> Unintended reflows and re-renders<p>> Narrowing the browser in complex UI with listeners also invokes reflows and re-renders which don’t represent the initial page rendering on device browsers.<p>> If you’re using components with observers like ResizeObservers in carousels, you trigger events and side effects that would otherwise not happen if a user initially loaded the page on a mobile device.</i><p>Sure. Is it a good substitute for <i>mobile testing</i>? Not specifically. And it's not a great substitute for orientation-change testing. But the issues that come up need sorting, because people do resize windows!<p>And simply reloading the page at that new size is going to help you find really quite a lot of low-hanging-fruit issues that would affect a mobile device loading that page on that fixed viewport.<p>All the other stuff in this blog post is valid and important or essential, but it's meaningless unless you develop these instincts first.<p>You build all that extra stuff on top of starting with a <i>fluid</i> design and then considering what limitations should lead you to adding <i>responsive</i> elements.<p>This way, when you get to device-oriented or device-specific testing you have much less to do, because your build is constructed around being size-agnostic.<p>There's not only no shame in designing without specific device optimisations (like viewport-height stuff) in mind -- it may be the only really meaningful way to design for the web now, when you have no hope of testing even a fraction of the device types out there.<p>Exhaustively testing in BrowserStack or even the Chrome or Safari dev tools is a hiding to nothing. These tools are useful but they are creating busywork and a dependency.<p>You have to design and build in a way that gives you fundamental confidence that you understand how your design might react, and that means embracing the idea that strong flexible design principles, relatively conservative designs, and actual physical device testing on the most commonplace devices or your target devices are the only things that will keep web development sustainable.<p>(This blog post is a bit of a listicle which seems to have been written to justify its silly clickbait headline. Which is a shame because there's useful information in it.)