3 ms·
> 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. A UI tha
by moritzwarhier 2y ago
> 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.
A UI that is not resizable should not use the web platform. [^1]
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).
There is a point though: window resizing misses DPR. And missing that commonly breaks responsive UIs.
Maybe that's the main point of the author, but the word "side effect" is really unfortunate then.
[1] If you don't support some viewport sizes, you can show a hint to the user that this viewport is unsupported.
- Alifatisk 2y agoYour footnote was unnecessary, it could’ve just been a new sentence on the same paragraph.
- moritzwarhier 2y agoyes, that was an accident because it came to my mind later, think it was also edited in. Anyway, you're right about that
- moritzwarhier 2y agoAfter having read the article: These are its main points, nothing totally wrong there. Apart from the DPR point, there are behaviors or mobile browsers that can only be reliable tested with an emulator. Example: if for some reason your site renders an input with a font size below 16px, iOS Safari will zoom into the page when that input is focused.
- DANmode 2y agoThat sounds like behaviors on mobile browser.
- alwillis 2y agohttps://medium.com/@rares.popescu/2-ways-to-avoid-the-automatic-zoom-in-on-input-fields-8a71479e542e#:~:text=Apple%20devices%20(iOS)%20on%20Safari,16px%20should%20do%20the%20trick https://medium.com/@rares.popescu/2-ways-to-avoid-the-automa....