The anti-pattern of responsive design
john.ankarstrom.se
john.ankarstrom.se
> 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
It should be a top concern for browser and page devs IMO.
That is not something I would want in many cases where I'm zooming in on mobile, if I understand you. A lot of time I'm doing that so I can accurately click a link that was too small. I want the text to stay positioned so I can zoom to a specific part of it without it changing underneath me. That's what a zoomed in view means, IMO, especially when considering the origin of the meaning.
Other browsers just don't care, leave the text in desktop-like proportions, and when you zoom in you end up needing to scroll sideways back and forth to read a sentence, quite cumbersome.
The most reasonable solution is Opera's where if you're on a desktop like site and you zoom to a block of text, it allows the letters to increase in size naturally according to your pinching, but when you let go it reflows the text block and makes it wrap once a line (at its new zoom level) reaches your phone's screen width. This way if you see a long paragraph (or Reddit title, for example), you can zoom until the text is readable, and then only need to scroll up and down, instead of sideways as well, without compromising the original site's design by wonking up the font sizes at (apparently) random.
I'm not sure I did the best job at explaining it, but basically the goal is to be able to zoom into small text on desktop-like pages until I'm comfortable with the size, and then make it wrap to the screen's width so you don't need to scroll sideways to read the text.
Easiest demo is to download Opera on Android, go to old.reddit.com and zoom around. Once you get used to it, every other browser becomes annoying.
Edit: lol, after typing all that I thought of looking up a video and here it is. Looks like some phone's default browsers already do it well too. https://www.youtube.com/watch?v=yAWTd9h1lbI
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.
This is why you see icons in the menu bar indicating that clicking here doesn't navigate you away from the page, but clicking over here instead might send you away from whatever it is you're doing here.
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.
They really should just focus on the content, and not obsess so much about how each and every pixel might look on my various browsers, and stop trying to make assumptions and guess about how I might prefer things to look based on silly things like browser width and user-agent string.
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.
1) Sites with multi-column or table design that can show more information when the browser window is wide. I tend to widen the browser window to get the most out of these pages.
2) Sites like Daring Fireball that have a fixed width, so I can still read the content just fine whether or not the window is wide.
3) Sites that expand the line length to wrap at whatever width the browser is at. I find these impossible to read unless I narrow the browser window because I lose track of which line of text I’m reading.
Types (1) and (2) are compatible and make up the large majority of sites I visit. Type (3) isn’t compatible for me, so I find it inconvenient. It’s not the end of the world, but it slightly inhibits my desire to visit such pages. I’d rather not maintain a multi-level navigation hierarchy with multiple windows and multiple tabs in a window.
Ecommerce sites are a minefield.
Saas and anything table-y or app-y, you're also out of luck for the most part.
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.
I have a few custom userstyles to deal with the worst of it; topnavs that grow to 20% of the page height and stuff like that.
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.
> 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.
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.
[1] https://github.com/w3c/csswg-drafts/issues/5796
[2] https://philipwalton.com/articles/responsive-components-a-so...
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.
A small number of global breakpoints can be a better trade-off when it means the website works better (for most people).
I've been using CSS Grid for years as my default layout method, but it doesn't magically solve all issues.
I prefer having a few fixed well defined breakpoints that having a combination explosion of places to fix and widths that I have to control when I do a changed on a component.
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.
Not sure what you mean. What does "no more space left" mean in practice, and how do you detect it with CSS?
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).
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?
At _some_ point, you will have to have a significant transition if you have an website that is mostly optimized for a desktop, full window experience.
I agree that many sites overdo the transition, but there are some things that really do warrant a phase-change at some point.
In that case I would prefer the scroll bar over implementing a whole separate layout just for the 0.1% who resized their window to 300px for a moment.
- 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.
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.
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.
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.
When I scroll on a site I expect all of the site to move. That includes and headers or footers or sidebars.
I have a web site that has multiple sections in it, and some of those sections have articles or stories in them, and some of those stories have chapters. I have breadcrumb navigation for it. That is a navigation element. I am not building an app. There are also web sites that have menus in them, because they have different sections and they choose to let you navigate between those sections using tabs or buttons or left-hand navigation columns or whatever. Those web sites are, nonetheless, still web sites.
> When I scroll on a site I expect all of the site to move. That includes and headers or footers or sidebars.
And when I view a site on my phone, I would prefer not to have to scroll left and right to access navigational elements. Because there will probably be navigation elements. Because web sites have those. :)
Cool. Scroll up to change sections.
> and some of those sections have articles or stories in them
That's pretty spiffy.
> and some of those stories have chapters. I have breadcrumb navigation for it.
When I read an ebook, I scroll down. When I scroll down I expect the navigation elements to move with (and disappear from) the screen.
If you want to repeat your navigation elements at the bottom of the page, that'd be a nice compromise. But please do not keep navigation elements on screen.
> There are also web sites that have menus in them
Menus are not discoverable in websites. Most websites implementations of menus is god-awful. It's absolutely _not_ intuitive, ever, that hovering a mouse should open a menu. And if you click a menu, should that navigate to a new page like clicking on anything else? Or should clicking suddenly _not_ navigate to a new page but instead do something different? How do you tell the difference?
Answer: you don't. The site shouldn't use menus. Use hyperlinks.
> because they have different sections and they choose to let you navigate between those sections using tabs or buttons or left-hand navigation columns or whatever. Those web sites are, nonetheless, still web sites.
And they're trashy websites that should be apps instead.
Maybe we're talking past each other. It feels to me like you're imagining the way these things that can be designed that you find absolutely the most annoying and deciding that's what I'm describing, and that you also have super strong opinions.
Also, thanks for suggesting the documentation web sites that I work on that have left-hand navigation columns are "trashy web sites" because I need to include tables of contents that are always visible, but I respectfully decline your demand to turn them into apps, because that's stupid.
How am I meant to tell if you are using a fullscreen mobile browser vs a resized desktop window?
You aren't. Why should you assume that a mobile browser window is any different than a desktop window?
I have an Android tablet with a 13" 4K screen and a stylus. A full screen window on there is huge and you don't need a huge button.
I don't want huge buttons on my tiny iPod screen either.
Because it quite obviously is. It would be absolutely bananas if the default view for the New York Times’ homepage was a super zoomed-out full width desktop site like it was in the original iPhone demo.
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
No, web designers need to do their best to balance cost/value of changes. While this might be a hot button topic here, I doubt the general public knows or cares much. Silly and self centered to DEMAND everyone needs to change to fit a niche group of users
There's sadly no easy, widely supported, reliable way to identify what designers try to deduct from these breakpoints. Even if you correctly identify my 4K screen as a notebook, that doesn't mean you'll take into account that it has a touchscreen. And even if you detect the touchscreen, I may prefer using the trackpad instead.
Microsoft had the right idea with the prominent touch/mouse toggle on their Office desktop apps, even if the solution feels a bit clunky and awkward. In the end you'll probably just need to take an educated guess and allow the user to override.
But sadly this means instead of a simple linear progression from lowres/touch to hires/mouse, we end up with a multi-dimensional matrix of touch/mouse, lowres to hires and so on, doubling or multiplying the variations with each new variable (e.g. dark mode).
My laptop is touch, and I use touch and the mouse frequently. Most apps work fine with either.
If you do and context menu or whatever for right click, make sure you also implement them for long touch.
All clickable things should be 40px or greater.
Is there something I am missing? Some great mouse functionality that I never learned?
As for the author and his predicament, why doesn't he just zoom out? I'm pretty sure every desktop browser can do that. He can make his window smaller and have the full desktop experience. Sure the text will be a bit smaller, but you can't have your cake and eat it.
Oh wow, I can't believe I never thought of doing that. (Not sarcasm.) I guess I'm just accustomed to responsive design being so poor that any client side change borks eveyrthing.
I just tried that on Facebook, and it actually doesn't break the site, but moves it a little more toward the usability of the old design. Thanks!
Edit: With that said, "just zoom out" doesn't work on mobile: once you get to a threshold, at least iOS interprets further zoomout as "I want to see all my tabs". Bleh.
On mobile (Chrome/Android at least) you can tick the "Use Desktop" box and it'll display the full desktop site. You obviously have to pinch zoom in to actually read stuff (for the most part).
What’s worse, there was some iOS update that made double tap to zoom very rarely work.
Looking at your analytics buy matrix only tells you what is working now not what you should spent money on. If you fixed your desktop version your analytics looks a lot different next month.
As for analytics, yes, of course. But if my CVR is currently 4% on desktop, and 4% on mobile, and 2% on tablets, maybe I want to spend some money on my tablet design. But maybe tablet traffic is SO small in the bigger picture, that the money spent getting optimised for (and maintaining) tablet sizes is better spent elsewhere.
I'm not arguing for shitty design. I'm just saying it happens, and I can understand (in some cases) why.
You can look at your analytics and completely misinterpret what they mean.
I have a 2560x1600 screen. I almost never have a window fully maximized.
I have two screens at that resolution. I almost never have a window fully maximized.
I also have several 1920x1080 screens attached. I almost never have a window full maximized.
I have many windows open. Some are thin -- tens of pixels. Others are wide. Some are tall, others short. Mostly though, I get really annoyed when software decides that I can't have a window that size.
Your analytics aren't a useful metric for determining what a user wants to do or see.
They're a pretty good starting point.
Just ask your users what they want. Or give them the option to change it themselves.
No I'm not.
> If you ask the users what they want (and you have reliable sampling) you're going to get the same result - very few of them will be running 550px wide browser windows.
That's a very huge assumption. I know many people who would have 550px browser windows if those browser windows weren't cluttered with all sorts of garbage that won't go away when the window is resized.
So you're saying that a lot of people have access to privacy-violating analytics. And that the analytics don't tell you what people want. And so you make decisions based on inferred information.
No wonder the web is a dumpster fire today.
You can do analytics without doing Google Analytics. More people need to understand this. There is nothing wrong with analytics (other than code/network bloat from overuse). Every website you connect to already has your IP address, browser info, referrer site, etc.
> Just ask your users what they want.
Jesus no. Do you even understand why we do analytics in the first place? We do analytics because you can't trust users to actually say what they want. The analytics tells you exactly what users are doing.
And yes, analytics tells you that some weirdo is browsing your site at 20px wide. No one is spending money and time designing anything for the outliers.
Yes.
> We do analytics because you can't trust users to actually say what they want.
False.
> The analytics tells you exactly what users are doing.
At the cost of their privacy you get to learn what people are doing. That still doesn't tell you what they want.
The tools we use to access and share information are broken.
> What can the user do?
Just use a 1000+ pixel window width like everyone else. The vast majority of desktop browsers are used with a 1000+ pixel with, often much larger. You are just the edgiest of edge cases.
I understand you’d like the whole world to cater to your weird preference for narrower windows, but making decent experiences for all sorts of operating systems, screen sizes, browsers, interaction models and so on is already hard enough. Asking for it to be made harder for your convenience is not a reasonable request.
Of course the real content should be privileged, but the #1 problem of the commercial web is the stuffing with trackers, distractions, time wasters, etc. and put responsive layout into that and it it is death.
I am working now on an HTML template to publish a photograph and some notes about it online and it revolves entirely around "taking over the viewpoint" so that I can put in a video-game style navigation bar (choose 1, 2, 3, 4 or 5 even if you don't know what it is it loads so fast you will) that always stays on the side but the other panel can have or not have a scrollbar, the photo automatically fits if you turn it, you can zoom in, etc.
It is possible with CSS and a polyfill, but it also takes a commitment to quality: I don't cookie you, I don't have to harass you with a cookie popup, etc.
I'm increasingly convinced that styling should be taken entirely out of the hands of the site / page designer, and into the hands of the user (or at least their device).
Offer a class of page styles (homepage, index, article, gallery, discussion, etc.). Offer a standard set of styles for these. Offer a set of minimal "identity" modifications for the site.
(The Microformats concept approaches this to a high degree. As does Gemini, from another direction.)
And let the user agent (with an override for those few power users who know and care) choose which of those styles to apply. (Again, elites could modify/adapt the styles if desired.)
Yes, this means you're not going to be able to design "for X browser". Yes this means that appearance will be highly distinct across devices.
But at least those of us accessing content can read the motherlovin' thing.
(Accessibility, screenreaders, machine processing, etc., will also benefit.)
Instead of designing for three screen sizes, it is easier to design for two and give tablets the mobile experience.
It is also the most challenging size to design for as you are restricted with horizontal space compared to the much more common desktop size.
I kind of wish my browser could just set a flag that CSS can see, so that I can decide for myself how much I like hamburger buttons and four words per line of text.
Does anyone know a source to confirm this? I remember reading an anecdote years ago that users got so used to the folders being the same as the window that held their contents that they had difficulties when that metaphor broke down. That story had some good insights on user-friendliness in design.
[0]: https://www.folklore.org/StoryView.py?project=Macintosh&stor...
This of course is in part thanks to Google's "mobile first" doctrine: https://developers.google.com/search/blog/2020/03/announcing...
However, this is impossible to actually implement, because we don’t get media queries in “what percentage of the screen is visible,” we just get how many pixels (or virtual pixels) we have to work with.
One variation on the authors idea: suppose that browser vendors implemented media queries differently so they provided “screen=small|medium|large|xlarge”. Then the widths which trigger these layouts could be configured in the browser (with sane defaults), and the user could “lock” their browser to whichever query they preferred regardless of the window size.
But, that would actually be really hard to deal with on the implementation and testing side. Do you - should you? - care if a user has their browser locked to “xlarge” but then the layout breaks when the window is shrunk down to 500px wide?
At the end of the day there’s no perfect solution here.
If you "like [your] browser windows to be reasonably narrow" then you're probably mostly "alone in frequently experiencing this phenomenon".
Most people I've seen maximize (or close to maximize) their browser.
It allows you to set width and height units (as well as any other CSS style) for each component using an array or object to describe how the component should render for each screen width (as defined by you). Also has built-in React hooks for responsive variables.
I've never had a better experience building responsive sites.
I think most of what the author is complaining about is bad responsive design. Media queries, by themselves, are a powerful primitive, but they get harder to work with and balance the more complex your site gets. Better tooling helps!
Given that i am using some hn reader app with integrated browser frame, it might be also safe to assume that the proposed imperative solution to "responsive design" would break on my edge case (it's not the reason for the current articles appearance though, it's just as badly optimised in the regular browser)
> Cross-site inconsistency
The whole section doesn't present a single logical argument. The author later tries to argue that designing a completely different interface for each device type will somehow lead to a more consistent design across devices... That is completely contradictory. Also, maintaining all these different interfaces will involve a lot more maintenance work and will lead to inconsistent functionality between devices. I hate native mobile apps in part because the interface is often completely different from the website.
The whole point of media queries is to provide the most consistent experience possible between devices by sharing as much of the HTML layout and CSS as possible between all the devices. If the breakpoints are chosen carefully, it does an amazing job at this.
Responsive design is amazing. Just like any powerful tool, there will always be people who misuse it. It doesn't make sense to call something bad because it's flexible enough that it allows people to make mistakes.
People should stop blaming tools and start blaming people. Not all developers are the same. Many software developers these days are completely irrational and incapable of critical thinking... They should be working in a different industry. That's the real problem.
We try so hard to avoid hurting people's feelings that we end up blaming everything except the people. That's why so many people are completely incapable these days; most of them never received any criticism, never had any incentive to improve themselves.
This makes it sounds like most responsive site work really well, but there are some cases where people have done a bad job.
That really doesn't match my experience.
There are a variety of screen sizes that should work. I once got a very small screen android phone and pretty much no apps worked correctly on it. But the responsive design approach where elements resize and reflow, etc., is at best only a partial solution. Perhaps the UX on a tiny screen should be fundamentally different.
Responsive design presupposes various layout oriented invariants that may not actually be the most sensible way to reorganize information. This combined with the cargo cult of DRY results in some pretty bad design.
That said, available layout area and the kind of user interaction available to an interface are separate concerns. So can we have `media="touch-only"`, please?
It seems it may not be quite as simple as I described, but you could probably spoof the device width being sent to the web page
The reasoning for this is fairly simple: a majority of users visit the site on mobile devices. Sites are being developed with a single code base for the largest group of visitors, with tablet and desktop users being added on afterward almost as alternative views. Using this process doesn't always produce the best results for any browser size because it requires a design plan that considers the requirements of this method.
Desktop-only sizes and features are great add-ons if you have time. But being able to get MVP to 100% of users is the top priority.
One thing that would help responsive design are breakpoints on elements, rather than the page itself. If my article preview component knows its own width, it can "break" accordingly into a better layout. While this is currently possible with JS, CSS support would greatly improve things (and enable the concept for non-js browsing experiences).