> Now, I think we can all agree that, on our desktop computers, we prefer viewing the full-width layout of most web pages.
This assumption is not reflective of current accessibility research. For folks that regularly use browsers at high zoom levels, it's important for content to be able to reflow even on a desktop computer. This is disproportionally impactful for older seniors, who might struggle with instructions like "remember to put an m. in front of the url".
> For folks that regularly use browsers at high zoom levels, it's important for content to be able to reflow even on a desktop computer.
I am one of those people; I have ~150% zoom on most sites, often higher. It's 240% on HN right now, which is my "default" for HN. This is not because I'm visually impaired by the way – I don't even use (or need) glasses – I just like it. I've been doing this since I was in my mid-20s and I just find it more comfterable.
I find these kind of reflows frequently make the page worse, not better. Even with a high zoom level the full desktop site usually works better than the "mobile optimized" site.
It's not uncommon that zooming will make the text smaller. You're at 140% and want to go a tad higher, so you go to 150% and bam: you're over the limit, the text becomes smaller, and now you need to zoom to ludicrous amounts to actually get the desired 150%.
The overall layout also often becomes worse. A common issue is that it makes the box in which the text is displayed too narrow, wasting a lot of space.
This is basically what's going on in this story: it's not that the website shouldn't work well on all different zoom levels or that it shouldn't have any kind of reflow at all, it's that it shouldn't give me a "mobile" site when the desktop version is actually still just fine. I think you've misunderstood this post a little bit.
In my own websites/webapps I generally take a gradual approach. If the screen becomes too narrow to display a certain UI element then tweak that element a bit, and do this individually for every UI element. This is quite a different approach than the "IF smaller_than(1200px) THEN serve_mobile_site". IMHO that's just lazy and bad design.
I usually avoid device detection, but do use it for a few things (e.g. <input type="date"> is ugly on the desktop, so it always serves a JS version for that).
A related note: forcing mobile UX patterns on desktop in general is usually not a good idea. Today I wanted to copy some text from the Dutch parliament website, and I couldn't as the UI element was one of those "swipe left/right" things, so actually trying to select text would swipe the thing to the left/right. I had to resort to the inspector mode to actually be able to select/copy the text.
>It's not uncommon that zooming will make the text smaller
At least in Firefox you can enforce the minimum font size through settings without using any third-party plugins or custom themes (look in about:preferences → "minimum font size"). I have it set to something like 16 or 18.
This doesn't fix the actual problem, but I gave up on trying to change the world a long time ago.
> It's not uncommon that zooming will make the text smaller. You're at 140% and want to go a tad higher, so you go to 150% and bam: you're over the limit, the text becomes smaller, and now you need to zoom to ludicrous amounts to actually get the desired 150%.
In fact, the video in his link that shows "correct" responsive design does exactly this, the text becomes larger or smaller in a seemingly random fashion as he zooms in. But to be fair to the BBC, I went to bbc.com and it doesn't seem to do that currently.
Yes, but how showing (shoving) everything under a hamburger menu on desktop helps accessibility? Usually if you back from such a full-page menu, you'll completely leave the website, because it's implemented as some <div> overlay with no one bothering to at least push an entry into history, so it looks like navigation but isn't and is in general very confusing.
On mobile people may be using back button less, but on desktop it's always easily visible and accessible in multiple ways, incl. the keyboard, and at least for me it's almost a reflex to use it. Just ctrl+[ away.
Yes, navigation links that don't behave like normal links are also an accessibility problem[1]. That's a separate issue, though; I don't think it is a reasonable argument against supporting reflow based on perceived window size.
We have desktop users with anywhere from 1400 to 3200pixel screen widths, so the concept of having a 'desktop site' without any kind of flow logic at all just doesn't make sense to me.
You end up with sites like daringfireball that is always 512 pixels of content centered in however wide your window is. On a 16:9 display this is extremely awkward. On a 1.85:1 or 2.39:1 display this looks dumb as hell.
Something barely related that drives me nuts, is that if reflow is something so important (it is), then why is Opera the only Android browser which implements text reflow? !
It should be a top concern for browser and page devs IMO.
Yes, we found our customers like to shrink our webapp down to half the screen, multitask, etc. Assuming full width even if their screen dimensions were large was a bad idea.
I often scale my browser window to 30% of the screen's width(it's a large screen).
Webapps and responsive webpages often like to either switch to a layout made for smartphones which looks really weird and makes some links and options inaccessible, or it just breaks in some ugly way. I've seen websites literally becoming unscrollable when the browser window got too narrow, websites where writing in a text field would gradually shift the site out of the visible area, forums that would hide away the "reply" button in narrow windows, instead showing the "report" button in the same location(facepalm).
Web developers should stop assuming their website is the center of my world and attention.
Yes, I almost never have my browser fullscreen (only when the page layout forces me to), and instead use a roughly 1:1 aspect ratio in the middle of the screen, so that text lines aren’t too wide and text starts not too far on the left. That’s with a 27" 16:10 screen.
While the wording isn't particularly clear, the later remarks contrasting full-width with full-screen makes it clear that full-width in this instance does not refer to the full-width of the screen, but only that the "widest" responsible layout is used.
I don't think the article is using unclear wording; I think it is clearly arguing the exact opposite of what you're describing. I think the clearest demonstration of this is the concluding section, where the author specifically talks about using "is desktop/laptop" as a preferred alternative to breakpoints that are based on window size.
Not only do I zoom in all the time, I also, you know, use my operating system's capabilities to put the page into a non full screen window, sometimes even a small (especially narrow) one.
Each of the suggested device categories (Desktop/laptop, Tablet, Phone) has many different screen sizes/resolutions. And all of them might have screens in landscape or portrait mode. All of these devices might support multi-tasking with varying split screen sizes. All of those devices support custom accessibility configurations for font-sizes, zooming or both. By detecting the UA and trying to shoehorn it into a certain category, you only increase the number of issues for the users.
One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible. Only break columns into rows when there is no more space left.
> One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible.
This is what "responsive design" used to mean. I remember being quite confused when people started using it to refer to distinct, non-responsive mobile-vs-desktop views.
Yeah, the advent of CSS frameworks introduced the concept of a relatively small number of global breakpoints. The consequence of this was that at certain widths, typically some figure meant to represent a change on form factor (mobile, tablet, laptop, desktop), there'd be dramatic layout shifts.
For a long time I resisted this, opting instead for more surgical introduction of a breakpoint, literally at the _point_ where some part of a page's design _breaks_ (not really the etymology of the word, but it's fun to think of it this way). But it's felt like a decade-long battle against the momentum of the industry, and sometimes I just want to build things rather than fight.
Yeah, that was confusing to me, too. I saw the article's first example and thought, "Well, that's not really responsive design, that's switching between two entirely different views!"
On my personal site I do indeed have a media query to make some tweaks when the viewport is phone-in-portrait-orientation narrow, but I try to keep them pretty minimal. I find sites that reorganize themselves at different widths ("if your browser window is 2000px across, this is a three-column display instead of two!") to be…not necessarily bad, but at best, unnecessarily clever.
I guess that's bootstrap's legacy: they implemented a grid in precisely that annoying way. Not that you have to use it like that, but the temptation seems to be considerable.
> This is what "responsive design" used to mean. I remember being quite confused when people started using it to refer to distinct, non-responsive mobile-vs-desktop views.
I agree this is confusing, but I think we still need a term for distinct types of views. The point of the article is that, once a user has started using one particular view, it shouldn't suddenly change to a completely different view with a different layout just because the user's browser window got resized by a few pixels.
I don't think it's possible for an app to auto-detect which view the user wants to use, particularly not if the auto-detection logic allows changing views on the fly in the middle of a user session based on resizing the browser window. I think the only real solution is to have different views that each have their own distinct URL, so the user can choose which view to use. Each view can then be "responsive" within the general constraints of the layout it adopts.
> One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible. Only break columns into rows when there is no more space left.
While the web still lacks in certain areas to accomplish this with CSS, there are many new techniques with grid and flex that allow very little use of media queries to reflow the content.
When using break points, or media queries, I don't think you should abide to a constant set. While relative units might solve certain situations, it's not a complete solution.
Using constant set of breakpoint sizes is what causes these bizarre jumps from a "wow this is a very stretched out mobile site." By using grid and flex and things like auto-fit, minmax(), etc will get you part of the way today. After you still need to use breakpoints to handle edge cases. These should always be set only at the point they are actually needed, not a fixed "this how wide phones kind of are." This way when the page is resized you have a fluid adjustment of content that only reflows automatically (with grid and flex) and at strategic breakpoints for edge cases. So regardless of the device it will flow more smoothly according to your site's content, rather than just 5 different screens (breakpoints).
> One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible. Only break columns into rows when there is no more space left.
Not sure what you mean. What does "no more space left" mean in practice, and how do you detect it with CSS?
Assume you have a number of cards organized in rows and columns. You could define how many columns to show between each breakpoint using several media queries. However, a better approach would be to use a flex container with `flex-wrap:wrap`. Specify `flex-basis` for its children and the browser will automatically wrap them accordingly. No break points needed.
But instead of just using CSS units, you can use hard breakpoints, but not for the whole site.
Each UI elements needs to be tailored based on width and height of a browser, you cannot bucket everything.
The best way to accomplish this is container queries, which are just starting to show up in browsers. Essentially, you define breakouts based on the dimensions of individual elements, not the full browser window. https://css-tricks.com/say-hello-to-css-container-queries/
> The most striking example is when a horizontal menu bar is converted to a vertical menu bar: all the user's spatial memory of the menu bar's links flies out the window! That option that you thought were there? It's actually here!
What do you expect to happen when there’s simply no room for all the content to fit horizontally? Something has to give.
Furthermore, vertical menus are far more common on mobile phones (not just on websites — apps too). Finding a way to shoehorn a horizontal navigation layout into a tiny screen is more likely to mess with a user’s spatial memory rather than respect it.
Exactly this. You can either having pages that scroll horizontally or content that reflows. There is really no other option available when dealing with a layout that can be arbitrarily resized (edited to add: there are a couple other options such as scaling down all individual UI elements, or simply removing some elements but those aren't really viable solutions in most contexts).
Since we have collectively decided that horizontal scrolling is unacceptable in almost all web contexts, that leaves reflowing content when the window gets smaller.
I understand the complaint and I sometimes have a similar frustrations. But, what other options are there that don't introduce horizontal scrolling?
Not all reflowing is created equal. Say you knew for certainty your users were only on desktop. In that case you may still want responsive design but it will likely be a different responsiveness than what we get with the cliff dive to "the mobile site". Reflowing can be done gently and granularly at the exact maximum points needed with minimum changes - rather than the stark nuking to a completely different site at 700px.
I think the issue is that many sites use screen size (e.g. max-width, max-height) as a proxy for things like "is this a touchscreen device", instead of using the media queries designed for that, e.g. (pointer: course) and (hover: none).
I understand _why_ things are done that way; it's far easier to design and test for three or four different screen sizes than it is to design for dozens of different combinations of screen size, pointer types, and screen orientations. Still, I get why some people might be frustrated about UI density _decreasing_ to accommodate a touchscreen when they reduce the size of their browser window on desktop.
> What do you expect to happen when there’s simply no room for all the content to fit horizontally? Something has to give.
Before the author went off on a questionable advisement about javascript device detection he made a very good point: People should be using relative sizing for layouts so they scale.
Agreed, but I think the answer is still more nuanced than that. For example, even though touchscreen devices tend to have smaller screens, they need larger click targets; your finger is much less precise than a mouse cursor.
Well, the context of the question, I think, is what you do when the "content" in question is navigation elements. I expect the page not to move things, either, but I also don't expect to have to scroll to access basic navigation -- and if you just let those elements wrap on a small display, well, we're back to the page moving things.
In general I'm (ahem) on the same page with you, but there are times when you have to decide on the least worst option.
"A layout optimized for different viewports results in the layout changing when the viewport changes."
How ridiculous to complain about a phenomenon that is basically tautological. The solution? Apparently it's user agent detection of phones vs. tablets vs. desktops. Because (of course) all phones are the same size, all tablets are the same size, and all desktop browser windows are the same size. Oh, and phones and tables are apparently also square.
The complaint seems to be about bad implementations of responsive design, as illustrated in the gif. In other news, bad design is bad.
> on non-responsive pages, it is very clear if the window needs to be resized to fit the whole page, but on responsive pages, there isn't anything signaling to the user that hey! the whole page doesn't fit with your current window size
So instead of appreciating that someone tried their best (which, sure, sometimes isn’t good enough) to fit their site to your window, they should have deliberately made it worse just to signal to you that you should make your window fit their site? Like, if the site looks cramped to you, resize the window. If it doesn’t, what’s the problem? This is a super-weird and niche request that would be better solved with a browser extension.
The title is so click baity and the whole premise seems flawed.
Spacial reasoning wouldn't work on mac if the users were constantly resizing their monitor. If you always want your website to look and feel the same, keep your browser the same size.
If you don't want a site optimized for small screens, don't make your screen small.
Additionally, this is all complaints with no solution.
It's not an anti pattern if it's the only way to solve a real problem.
> maybe it would be better if we went back to some form of user agent detection
God no. Just because I have a desktop PC with a big monitor, doesn't mean that I'll always have one fullscreen browser window occupying all of it. For all the troubles of responsive design, it's really nice to be able to tuck a website into a very narrow viewport at the edge of the screen to do something else while keeping an eye on it.
The mobile-first approach that web developers have adopted reflects the desire to maintain one codebase regardless of device. What the author of the article proposes is what we used to have before responsive websites: separate mobile and desktop websites.
You can design responsive websites today using CSS Grid without needing media queries, and the resulting sites can offer a better experience than using media queries. Unfortunately, not many developers are taking such an approach. Why not? It may be they are:
- using a CSS framework (that does not use CSS Grid)
- using a CSS-in-JavaScript-style framework
- need to support older browsers
- simply aren't aware of modern CSS features available
CSS is still horrible and will never be anything less than that, but...modern CSS (for modern browsers) lets you leave behind all the horrible CSS hacks from the past.
I recommend watching this excerpt from an excellent video by Jen Simmonds (Developer Advocate at Mozilla) on CSS Grid from 2018:
Readit News
> Now, I think we can all agree that, on our desktop computers, we prefer viewing the full-width layout of most web pages.
This assumption is not reflective of current accessibility research. For folks that regularly use browsers at high zoom levels, it's important for content to be able to reflow even on a desktop computer. This is disproportionally impactful for older seniors, who might struggle with instructions like "remember to put an m. in front of the url".
WCAG 2.1 success criterion 1.4.10: Reflow is a good starting point for learning about this: https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
I am one of those people; I have ~150% zoom on most sites, often higher. It's 240% on HN right now, which is my "default" for HN. This is not because I'm visually impaired by the way – I don't even use (or need) glasses – I just like it. I've been doing this since I was in my mid-20s and I just find it more comfterable.
I find these kind of reflows frequently make the page worse, not better. Even with a high zoom level the full desktop site usually works better than the "mobile optimized" site.
It's not uncommon that zooming will make the text smaller. You're at 140% and want to go a tad higher, so you go to 150% and bam: you're over the limit, the text becomes smaller, and now you need to zoom to ludicrous amounts to actually get the desired 150%.
The overall layout also often becomes worse. A common issue is that it makes the box in which the text is displayed too narrow, wasting a lot of space.
This is basically what's going on in this story: it's not that the website shouldn't work well on all different zoom levels or that it shouldn't have any kind of reflow at all, it's that it shouldn't give me a "mobile" site when the desktop version is actually still just fine. I think you've misunderstood this post a little bit.
In my own websites/webapps I generally take a gradual approach. If the screen becomes too narrow to display a certain UI element then tweak that element a bit, and do this individually for every UI element. This is quite a different approach than the "IF smaller_than(1200px) THEN serve_mobile_site". IMHO that's just lazy and bad design.
I usually avoid device detection, but do use it for a few things (e.g. <input type="date"> is ugly on the desktop, so it always serves a JS version for that).
A related note: forcing mobile UX patterns on desktop in general is usually not a good idea. Today I wanted to copy some text from the Dutch parliament website, and I couldn't as the UI element was one of those "swipe left/right" things, so actually trying to select text would swipe the thing to the left/right. I had to resort to the inspector mode to actually be able to select/copy the text.
>It's not uncommon that zooming will make the text smaller
At least in Firefox you can enforce the minimum font size through settings without using any third-party plugins or custom themes (look in about:preferences → "minimum font size"). I have it set to something like 16 or 18.
This doesn't fix the actual problem, but I gave up on trying to change the world a long time ago.
In fact, the video in his link that shows "correct" responsive design does exactly this, the text becomes larger or smaller in a seemingly random fashion as he zooms in. But to be fair to the BBC, I went to bbc.com and it doesn't seem to do that currently.
On mobile people may be using back button less, but on desktop it's always easily visible and accessible in multiple ways, incl. the keyboard, and at least for me it's almost a reflex to use it. Just ctrl+[ away.
[1] https://www.w3.org/WAI/WCAG21/Techniques/failures/F42
You end up with sites like daringfireball that is always 512 pixels of content centered in however wide your window is. On a 16:9 display this is extremely awkward. On a 1.85:1 or 2.39:1 display this looks dumb as hell.
I'll still take it over Paul Graham's blog with all the text way over there on the left edge.
It should be a top concern for browser and page devs IMO.
Webapps and responsive webpages often like to either switch to a layout made for smartphones which looks really weird and makes some links and options inaccessible, or it just breaks in some ugly way. I've seen websites literally becoming unscrollable when the browser window got too narrow, websites where writing in a text field would gradually shift the site out of the visible area, forums that would hide away the "reply" button in narrow windows, instead showing the "report" button in the same location(facepalm).
Web developers should stop assuming their website is the center of my world and attention.
> What can the web designer do?
Completely disagree with this section.
Each of the suggested device categories (Desktop/laptop, Tablet, Phone) has many different screen sizes/resolutions. And all of them might have screens in landscape or portrait mode. All of these devices might support multi-tasking with varying split screen sizes. All of those devices support custom accessibility configurations for font-sizes, zooming or both. By detecting the UA and trying to shoehorn it into a certain category, you only increase the number of issues for the users.
One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible. Only break columns into rows when there is no more space left.
This is what "responsive design" used to mean. I remember being quite confused when people started using it to refer to distinct, non-responsive mobile-vs-desktop views.
For a long time I resisted this, opting instead for more surgical introduction of a breakpoint, literally at the _point_ where some part of a page's design _breaks_ (not really the etymology of the word, but it's fun to think of it this way). But it's felt like a decade-long battle against the momentum of the industry, and sometimes I just want to build things rather than fight.
On my personal site I do indeed have a media query to make some tweaks when the viewport is phone-in-portrait-orientation narrow, but I try to keep them pretty minimal. I find sites that reorganize themselves at different widths ("if your browser window is 2000px across, this is a three-column display instead of two!") to be…not necessarily bad, but at best, unnecessarily clever.
I agree this is confusing, but I think we still need a term for distinct types of views. The point of the article is that, once a user has started using one particular view, it shouldn't suddenly change to a completely different view with a different layout just because the user's browser window got resized by a few pixels.
I don't think it's possible for an app to auto-detect which view the user wants to use, particularly not if the auto-detection logic allows changing views on the fly in the middle of a user session based on resizing the browser window. I think the only real solution is to have different views that each have their own distinct URL, so the user can choose which view to use. Each view can then be "responsive" within the general constraints of the layout it adopts.
While the web still lacks in certain areas to accomplish this with CSS, there are many new techniques with grid and flex that allow very little use of media queries to reflow the content.
When using break points, or media queries, I don't think you should abide to a constant set. While relative units might solve certain situations, it's not a complete solution.
Using constant set of breakpoint sizes is what causes these bizarre jumps from a "wow this is a very stretched out mobile site." By using grid and flex and things like auto-fit, minmax(), etc will get you part of the way today. After you still need to use breakpoints to handle edge cases. These should always be set only at the point they are actually needed, not a fixed "this how wide phones kind of are." This way when the page is resized you have a fluid adjustment of content that only reflows automatically (with grid and flex) and at strategic breakpoints for edge cases. So regardless of the device it will flow more smoothly according to your site's content, rather than just 5 different screens (breakpoints).
Deleted Comment
Not sure what you mean. What does "no more space left" mean in practice, and how do you detect it with CSS?
But instead of just using CSS units, you can use hard breakpoints, but not for the whole site. Each UI elements needs to be tailored based on width and height of a browser, you cannot bucket everything.
What do you expect to happen when there’s simply no room for all the content to fit horizontally? Something has to give.
Furthermore, vertical menus are far more common on mobile phones (not just on websites — apps too). Finding a way to shoehorn a horizontal navigation layout into a tiny screen is more likely to mess with a user’s spatial memory rather than respect it.
Since we have collectively decided that horizontal scrolling is unacceptable in almost all web contexts, that leaves reflowing content when the window gets smaller.
I understand the complaint and I sometimes have a similar frustrations. But, what other options are there that don't introduce horizontal scrolling?
- Wrapping the menu to a second line
- Moving menu items that don't fit to an overflow menu
Both of these would preserve spatial memory for all of the earlier menu items.
I understand _why_ things are done that way; it's far easier to design and test for three or four different screen sizes than it is to design for dozens of different combinations of screen size, pointer types, and screen orientations. Still, I get why some people might be frustrated about UI density _decreasing_ to accommodate a touchscreen when they reduce the size of their browser window on desktop.
Before the author went off on a questionable advisement about javascript device detection he made a very good point: People should be using relative sizing for layouts so they scale.
First and foremost I absolutely expect the page to not move things!
If I resized my window and things don't fit any more... then a scrollbar is exactly what I want.
In general I'm (ahem) on the same page with you, but there are times when you have to decide on the least worst option.
How am I meant to tell if you are using a fullscreen mobile browser vs a resized desktop window?
Deleted Comment
How ridiculous to complain about a phenomenon that is basically tautological. The solution? Apparently it's user agent detection of phones vs. tablets vs. desktops. Because (of course) all phones are the same size, all tablets are the same size, and all desktop browser windows are the same size. Oh, and phones and tables are apparently also square.
> on non-responsive pages, it is very clear if the window needs to be resized to fit the whole page, but on responsive pages, there isn't anything signaling to the user that hey! the whole page doesn't fit with your current window size
So instead of appreciating that someone tried their best (which, sure, sometimes isn’t good enough) to fit their site to your window, they should have deliberately made it worse just to signal to you that you should make your window fit their site? Like, if the site looks cramped to you, resize the window. If it doesn’t, what’s the problem? This is a super-weird and niche request that would be better solved with a browser extension.
Spacial reasoning wouldn't work on mac if the users were constantly resizing their monitor. If you always want your website to look and feel the same, keep your browser the same size.
If you don't want a site optimized for small screens, don't make your screen small.
Additionally, this is all complaints with no solution.
It's not an anti pattern if it's the only way to solve a real problem.
God no. Just because I have a desktop PC with a big monitor, doesn't mean that I'll always have one fullscreen browser window occupying all of it. For all the troubles of responsive design, it's really nice to be able to tuck a website into a very narrow viewport at the edge of the screen to do something else while keeping an eye on it.
You can design responsive websites today using CSS Grid without needing media queries, and the resulting sites can offer a better experience than using media queries. Unfortunately, not many developers are taking such an approach. Why not? It may be they are:
- using a CSS framework (that does not use CSS Grid)
- using a CSS-in-JavaScript-style framework
- need to support older browsers
- simply aren't aware of modern CSS features available
CSS is still horrible and will never be anything less than that, but...modern CSS (for modern browsers) lets you leave behind all the horrible CSS hacks from the past.
I recommend watching this excerpt from an excellent video by Jen Simmonds (Developer Advocate at Mozilla) on CSS Grid from 2018:
CSS Grid: Assuming You Need Breakpoints: https://youtu.be/0Gr1XSyxZy0?t=189