Sites are not detecting a portrait screen and deciding that they're displaying on a phone. Someone who switches their monitor to portrait, or resizes a window to be taller than it is wide, is still going to get the desktop view.
In this case the author is scaling their resolution, and so their browser is presenting itself to sites as 720px wide. Sites see that and show a layout optimized for a screen of that width. Those sites are acting correctly.
The author's proposed solution is for sites to use DPI instead, but this would thwart the preferences of users who use scaling because they want the whole site to look bigger.
I would add to this that the specific sites in question have fairly unreasonable media-queries: The Guardian breaks to mobile at 980px, and Just Eat at 1024px. On my MacBook Pro with default scaling, these are both more than 50% the width of the monitor; i.e. if I size the window to half-screen, I'm in mobile mode on these sites. For reference, in sites I make I usually set the mobile breakpoint closer to 768px (note that this isn't a question of increasing pixel-density on phones; "CSS pixels" are virtualized to approximate the same physical size across devices, though they get affected by display-scaling too).
So IMO it just comes down to some sites doing a bad job of picking responsive breakpoints.
Edit: Out of curiosity I checked MDN, and their media query tutorial has you set the mobile breakpoint at 40em. Default font size at least on desktop is 16px (again, virtual pixels which scale with display-scaling and device size), which comes out to a breakpoint width of 640px: https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
There's no more a "break to mobile at 980px" than a "break to mobile at 1140px", it's just the one you have a problem with. A responsive site scaling at multiple breakpoints isn't like switching to a mobile site just because it changes its "More" menu to a hamburger. The problem seems to be your choice of hardware coupled with your split-screen window size plus your want of three rows over two at a specific site; remove one and the problem goes away. To me The Guardian is scaling perfectly well and trying to paint it as switching to mobile is disingenuous. I'm amazed reading stuff like this at HN (well maybe not as most "hackers" can't design if their life counted on it). The Guardian is a good example of a perfectly well working responsive website.
You absolutely do not want to scale the page to the same physical size on different screens because you also need to take into account distance between screen and your eyes. Text on phones can be smaller physically than text on a desktop monitor because you hold your phone closer. As an even more extreme example, think of browsing the web on a TV screen while sitting on the couch and how small the text would be if it is physically the same as it is on your phone.
This is more or less what we have at the moment, with DPI scaling ensuring that 16px in CSS roughly is the same amount of physical distance. On a phone with a 2x DPI scaling (like an iPhone), that’ll render as 32 physical pixels.
w3c never wanted to implement physical units [1], saying OS are not reporting screen DPI reliably, etc.
I understand they had to start with something and 20 years ago no one expected thre will ever be monitors with DPI > 96 but I don't understand why the situation hasn't changed yet. Now that we have many physical screen sizes with vastly varying densities.
In my opinion, devices with a screen are like a sheet of paper. Imagine a tablet or Remarkable eink. You can print only that small font on such paper. If the font is too small, we can use a magnifying glass or, in case of electronic devices, clever scaling mode.
If that was implemented, buying a bigger monitor would actually mean we could fit more content, wider newspaper there.
The current situation is just a mess with designers just randomly guessing how it's gonna look on most current devices and using media queries to somehow automagically solve it all. But it is not uncommon to see a website on a huge hi-DPI monitor in such a way that a heading takes 1/4 of the screen height and there are empty unused paddings everywhere. I.e. if you buy a bigger monitor, everything just gets bigger, including most of fonts, unnecesarily. Sometimes all you get is three columns of text instead of one. Sometimes. If media queries are set up reasonably well. But even then, on high-resolution screens there is sometimes big empty space on the left and right side because it is just "highest-width" media query and designers didn't expect you would have so many pixels horizontally...
The current situation is not a mess; it works pretty well:
* Manufacturers configure their devices to ship with reasonable default settings, where is CSS pixel is roughly the same apparent size for everyone.
* Users who want content to be displayed larger or smaller can change their device scaling, which then makes their CSS pixels larger or smaller.
* Web developers can write for CSS pixels, knowing the content will display at a reasonable size for the user.
> if you buy a bigger monitor, everything just gets bigger, including most of fonts, unnecessarily
It sounds like you're probably sitting closer to the monitor then expected? Lower your device scaling and things will be a better size in all programs including the web browser.
> on high-resolution screens there is sometimes big empty space on the left and right side because it is just "highest-width" media query and designers didn't expect you would have so many pixels horizontally
I think this is also running into user preferences and design. If I'm reading an article, and there is just one stream of text, I'm quite happy for it to take a 40em strip down the middle of my screen. If the text ran edge to edge it would be much harder to read, because it's hard to keep your place when jumping to the next line.
I think you're conflating "bigger monitior", "higher resolution", and "high-dpi".
> But it is not uncommon to see a website on a huge hi-DPI monitor in such a way that a heading takes 1/4 of the screen height
> if you buy a bigger monitor, everything just gets bigger, including most of fonts, unnecesarily.
I don't think this is the case at all? The web and browsers handle DPI scaling incredibly well. I don't think I've ever ran into an issue with it. Remember that Apple has been shipping high-DPI monitors for the past 15 years, and I've never experienced these issues of a website of a website not handling this. More or less, the browser completely abstracts this away - you have to purposefully screw things up to render things at different sizes depending on DPI.
I have many dissatisfaction for YouTube Music. One of my problem is that the Web hides some buttons/elements like +1 button when the window < 1280px (IIRC) even though there are empty spaces.
I just checked and the iPhone X has a height of 812px. It has a width of 375px. The regular iPad has a width of 768px, and the iPad Pro has a width of 1024px. So you could be right about them trying to capture all tablets, though a hamburger menu on the enormous iPad Pro sounds just as ridiculous as it does on a vertical monitor
The hamburger is more for "better" touch navigation though. I know these devices work fairly good with standard hover type states now, but the UX could be argued to be better when optimized for touch inputs.
Sizing is another matter entirely, in which I would agree, yea a tiny hamburger menu on an iPad Pro is likely bad. We all have engineering budgets though and in the grand scheme of things, iPads are likely a small fraction of the visitor base for these sites, so I get it.
Agreed completely. One mistake that designers/developers do though is to completely give up under 1000px so we get this swaths of whitespace and a hamburger. That’s a waste of estate and a waste of my time.
I've emailed one of YC's huge successes multiple times over years about how it's frustrating to have horizontal scrolling on a browser that's half of a 1080p display wide (i.e., nearly 1000px).
Unfortunately, the horizontal scrolling UX with substantial wasted whitespace on the sides remains.
I've found sites using Material UI guidelines (heavy use of cards and navbar hamburger) especially culpable to this. Huge gap of greyish whitespace with a hamburger in the left.
Someone else mentioned bootstrap in the other thread too.
Maybe because these Frameworks are hugely popular, their defaults amplify the impact. Definitely these values are tweakable.
Yeah, I still very often get "here is the desktop design, here is the mobile design". Depending on who is developing the designs depends how that's going to translate.
I have all the time in the world for developers that reflow the page and remove/adjust elements at different breakpoints (based on the design) between 'desktop' and 'mobile' so the experience is good for everyone. Sadly, most people don't bother.
I believe true webdesigners are in decline. You have lots of people who do this as a side gig after reading a few tutorials. In a way that’s a nice compliment for the accessibility of the tech, but not accessibility for the end user.
Same with “We only tested this on Chrome.” of sites/apps, of which are there are many, as I can attest, as I never use Chrome.
It's just plain hard to keep up with front-end tech. Most people use front-end dev work as an entry point. They quickly realize there are more sane jobs available on the backend and migrate there.
> I believe true webdesigners are in decline. You have lots of people who do this as a side gig after reading a few tutorials.
In decline from when? Picking it up after reading a few tutorials has always been a common way to get into web work, and if anything I feel like it's been getting more professionalized over the last twenty years.
Just the general gist over the last few years. I am not saying there are no really skilled professionals, I am just seeing a lot of lower par work from jobs I take over. Plus just by surfing the web and noting the quality.
I’ve been doing web development since 2007, and I’m struggling to think of an era that had more professionals doing front end than we have now. I’m not sure my experience agrees with you
I don't think apps are as relevant to current discussion. For apps (not public websites), there are different requirements depending on the target audience.
I wouldn't be mad at a B2B web app being desktop only, no mobile CSS.
But I agree that web apps should still be compliant with safari + FF + Chrome.
Convincing a client to pay for time to spend checking the design and tweaking it in the space between the breakpoints can be more hassle than it's worth.
That said, sane breakpoints can usually avoid unexpected hamburgers on the desktop.
You convince them in the same way you convince a PM to give you time to write tests for your work: you don't give them an alternative. "You want this done? That'll be 20 billable hours." And your estimate includes the time needed to do work you're willing to sign your name to. When I hire a plumber or an architect, I tell them what needs doing, but I expect and trust that they'll put in the work (and bill me accordingly) to ensure that it gets done properly, even though I don't understand all of the specifics of what doing those jobs properly entails.
that's something I don't understand. the Dev tools in Chrome and Firefox make it really easy to test through every resolution without problems. every UI change I make I view in all possible resolutions and its quite obvious of something breaks and I adjust accordingly.
If it takes too much time, you are probably doing something wrong like having hardcoded layouts for different resolutions instead of using reflow as much as possible.
Even with all reflow it's hard. Should I reduce a width a little bit more so that it become 3 columns instead of 2 on iPad vertical at risk of having some line wrapped? Things like that.
For my day job working on a UK e-commerce site that gets roughly 100,000 uniques a day, our split is 70/30 for mobile/desktop. Unfortunately within the company it’s closer to 1/99. So no matter how many times I repeat the phrase “mobile first”, the higher-ups just don’t get it. Luckily I can make rational decisions for them!
I like to start on the desktop but build in a way I know the objects will flow. Then I set up a tester with a bunch of breakpoints and check as I go and make micro adjustments to each element that is "off". Then you can set the element inspector to the side and just keep shrinking the screen to make sure nothing is awry as the width gets less and less. I don't really have X sets of 'rules', just elements adjusting at the point it feels right to adjust them.
Yes, and webdevs have been trying for over 10 years now to figure out how to get this right. Has no one just stopped to consider having a browser send a `prefersMobileView` or `viewport:phone` or anything like that? I can remember back a few years ago, an iPhone 6+, turned sideways could get a desktop view on some sites... simply because it met the requirements set by the author. Now, the author's assumptions were wrong of course, but all we have to go on, is literally guesswork. We're told constantly NOT to use user-agent strings, but honestly, it's like we really need something to key off of. I know the A List Apart folks would have us create content that can be viewed on ANY viewport, but I consider that a tad bit unrealistic. I've been out of Front-end dev for a few years though, so perhaps things have changed.
> Lay out content based on the viewport width, in CSS pixels.
This is wrong because the viewport width is not the same as the monitor width or the DPI: especially on big monitors running the browser fullscreen is very hard to use (my browser rarely exceeds more than ~50% width on a 2560x1440 monitor and even when i use a 1366x768 monitor - which btw is at 22", not some tiny laptop one - i very rarely use it maximized).
The problem is that the horizontal space only tells you how many pixels are available, not how big whatever you use those pixels for ends up on the screen.
The precise vs coarse isn't helpful either for something like this because this isn't just about clicking vs tapping, it is about how the end result looks - and there are PCs with both very small monitors and very big monitors (and relatively large monitors with low DPI or small monitors with very high DPI). CSS pixels only help for setting sizes/positions, but not layout.
AFAIK the best that can be done nowadays is resolution media queries but that isn't available everywhere (at least according to caniuse).
Of course in practice i expect none of the above to be used and have my browser simply zoom out whenever i reach many sites just because i do not want to maximize my browser :-/
CSS pixels are good for layout, not just sizes and positions, because a pixel (in a browser) now represents an apparent size. That is, if the user has a large device far from their face, or a small device close to their face, a pixel represents a similar portion of their vision. If they want things larger, they can adjust the scaling so a pixel represents a larger apparent size, or the reverse.
This is never true in practice though and what you describe is just about sizes and position, you can't change the layout with CSS pixels - you need resolution media queries for that.
Most "mobile" usage is actually stationary, typically seated. If you really need to change layout based on motion you can use the accelerometer, but I can't see why you would?
IMO the best solution is to just have natural breakpoints (i.e. when a part of the design of the given page would cease to work, add a breakpoint to change the format of that component, rather than at predefined points) and then for logged in users have an option to request the desktop design, which you can do by simply setting a viewport to 1000px width and leaving everything else unchanged
what would be really nice would be element-size-based media queries. you can use javascript to do it but that sucks
I think we really need to be able to more cleanly separate content from the design, and let the browsers, a.k.a. user-agents, decide/override more. Browsers have ceded too much control over layout and visual structure to web designers, who go on to make (often incorrect) assumptions about how the user wants to interact with their content.
the problem is that there is no distinction between a webapp and a document, the line is thoroughly blurred. For documents, you can probably just override a fair bit of schenanigans and things will still work, if look somewhat ugly, but for a spreadsheet app that's a rube goldberg machine of javascript and continuously regenerated html and css, it'll just turn it into a broken mess. the browser has become the de facto cross compatible application platform, which requires handing a lot of control to websites.
That sounds similar to a CSS proposal called container queries, which has been a much-requested feature for many years. Currently the only native way to do responsive design is to make styling changes based on attributes of the viewport (like width). But like you say, it would be nice to have dynamic layouts for every individual component of a website. Container queries do that.
yeah I heard of those, I was blanking on the name, thanks for pointing that out. Another thing I really want would be position:device-fixed; but that one doesn't even seem to really be on the table for the most part.
Isn't that still true in 2021? I haven't been particularly fond of the mobile view of most sites I come across. I force desktop-view on my phone fairly frequently just to get at features/pages I want.
It is still maybe a little bit true, where some sites will make some things only possible to do on desktop, but when the iPhone came out mobile sites were generally incredibly minimal. They needed to be, to handle existing devices and browsers, which were much less powerful than the iPhone.
Mobile websites pre 2008 tended to be WML over WAP. If they existed they were terrible, probably created by an intern once and not updated, because very few people used mobile phones for internet access (other than say linking their PDA or notebook to their phone via IRDA)
> The author's proposed solution is for sites to use DPI instead, but this would thwart the preferences of users who use scaling because they want the whole site to look bigger.
The author's problem is not things becoming bigger.
Larger was the goal after all of settings that scaling.
The author's problem is things optimize for mobile interaction.
Like making thing touch controlled,
Or making buttons disproportionately large to make easy to click with thumb.
This doesn't address the author's central argument, which is that websites need an effortless way of letting fonts become bigger without affecting the entire layout. I've wanted it too. I don't really care if some text gets cut off on headers and looks weird, I just want to read stuff from the comfort of my bed with my laptop a few feet away.
This was tried in the mid-late oughts was it not? It is nearly impossible to logically derive what should increase in sized and what should not.
Should the space given to sidebars increase? Should those sidebars disappear? What about headers and footers? How will the overfloat be treated? A single line, double lines? What about captions underneath images? How do you handle text that happens to be embedded within images themselves, or even on top of images?
"I don't care if headers look weird"
It goes beyond things looking weird, it really does break websites.
I love that Chrome on Android lets me zoom into any content on any site, regardless of how bad the devs borked the UX. (Yes, devs, if you don't allow me to zoom using the browser's built-in capabilities, you have borked the UX, and should be ashamed of yourselves.)
If you have a windows 10 laptop, pinching on the touchpad seems to give you the same zoom functionality now. vastly superior than the one built into the browser
If you're using a mobile browser on Android that doesn't allow overriding websites that disable zoom (or using a website that defines font sizes in vw/vh), check your accessibility settings, there should be a shortcut for triple-tap to enable a zoom function. Some devices have other magnifying functions as well. My tablets and phone all have the basic magnifier function; my LineageOS (android 7 & 8) tablets additionally have a screen zoom/dpi setting to modify how large both pictures and text appear, and my samsung tablet (Android 10) has this and also a text zoom function. There's also a minimum view width setting in developer options since at least Android 8, to ensure interfaces aren't too small on mobile (this only goes one way though-- there's no maximum view width and no height controls).
It doesn't help with everything, but the triple-tap zoom is quite useful.
This is one of the main reasons I prefer using a website on my phone as opposed to an app. Some apps allow me to zoom others don't. The browsers lets me do that regardless.
I didn’t know this! And inability to do this is a huge pet peeve (as well as not being able to zoom OUT and get a desktop-like view on my phone). Does this work on any browser for iPhone?
On mobile: all browsers have "force enable zoom" + test scaling in accessibility settings; Additionally Opera supports reflow on zoom (Settings > Text options > "Text wrap").
I don't really care if some text gets cut off on headers and looks weird, I just want to read stuff from the comfort of my bed with my laptop a few feet away.
How is a web site supposed to know if you're someone sitting in bed with the screen a few feet away, or someone sitting at a desk with a screen a few inches away?
That's on the user. Learn how to use your browser, device, and operating system's zoom features.
> I just want to read stuff from the comfort of my bed with my laptop a few feet away.
That's not what laptops are for.
I think that's a typical snide HN/Stack Overflow-type answer, and I don't mean it rudely, but it does have some bearing on this conversation. What's the intended form factor of a laptop? What are the top 10 intended form factors? I'm not sure "reading from 'a few' [several] feet away, while I'm laying down in bed" is in that top 10 list.
Are there devices better suited to that form factor? I don't know.
>What's the intended form factor of a laptop? What are the top 10 intended form factors? I'm not sure "reading from 'a few' [several] feet away, while I'm laying down in bed" is in that top 10 list.
I mean, I guess less so now that everyone has phones and maybe an e-reader, but... that's not such a weird use case. That's basically how I spent the later half of high school.
> What's the intended form factor of a laptop? What are the top 10 intended form factors?
Isn't the real questions why we allow devices or their makers to decide the "intended use-cases" and accept that many other use-cases are often near impossible. The PC revolution was about a general purpose computers, and laptops should imho still be general purpose computers; not machines for which some overlord in Mountainview or Cupertino checks on every button pressed whether I am allowed to do what I intend to do.
Politics aside, I am the only one who has the impression that with every new release of macOS or Firefox features get removed, that enabled me to personalize and optimize my workflows before?
That's how zooming (ctrl+scroll) in the browser used to work: It increased font sizes. It has been abandoned because it just wreaks havoc on the layout and is impossible to handle properly.
It was so standard, it wasn't even called "zooming", because it wasn't. It was called "increase text size". It worked well for most reasonable sites, certainly a lot better than an actual zoom typically does.
I just have bad eyes. I complained once about text size here and a lot of people just said, "use your browser zoom", completely ignoring how layouts not scale or reflow.
> Sites are not detecting a portrait screen and deciding that they're displaying on a phone.
You wish!
A few years ago one website of a huge electronics component supplier did exactly that. I notified the webmaster, to which they responded that I represent a corner case in their new mobile-first strategy and it's a wontfix. However after politely inquiring how many of their customers source industrial supplies from their cellphones it was eventually reversed.
You're missing the forest for the trees here. Sites are using pixels as a proxy for physical device size. Which obviously breaks. I doubt people actually intend to display mobile view on a 720px, 12" wide device.
They're only working correctly if you ignore the intent and only look at the technical implementation. The technical implementation is flawed and doesn't accomplish the intent.
But the OP is using pixels as a proxy for screen size as well, they're deliberately presenting their screen as 720x1080 to make the fonts bigger because they are too far from the screen.
The stupidest thing to do at that stage would be to say "ah I see you're running a low resolution on a huge screen, let me make all the text tiny".
I think their point was that if you want fonts to be bigger, there are settings to do that. (or should be even if the world isn't perfect yet) Same to a lesser extent for other ui features.
In reality, as of today, so far, neither desktops nor apps are that good where you can have the display set at it's correct native resolution, while having buttons, menus, icons, text, window controls etc all scale to preference.
But saying that that's what should happen rather than lie to the software about the hardware, is not agist or ableist.
I think the point was simply that fundamentally, lying to the software about the hardware is always inherently doomed to produce some form of incorrect result, and when it does, it's not the tech's fault for failing to second-guess, work-around, and essentially thwart your actively dishonest misconfiguration.
You're not disagreeing with the argument or conclusion of that post, though: it would be bad for sites to look at dpi and determine the native screen width without factoring in zoom level, because doing so would make text unreadable for you.
Without accusing you of any -isms, OP merely said that, given how far they sit from the screen, the font is too small.
You conflated that with sitting too far away. There are a lot of reasons why that might not be correct, including presbyopia. I think it's unlikely OP is sitting at that distance by accident, since it's pretty easy to move a monitor closer, so one of those reasons is more likely to apply than is your assumption.
Since tone carries very badly let me say up front that I'm mostly just confused by this entire discussion.
For now I stand by my assumption that OP wanted the fonts to be bigger because they were too far from the screen to read them at their current size. Though I fear I can't see why their reason for wanting fonts to be bigger would matter. I could have omitted OP's reason for wanting the fonts to be bigger but I thought a brief description would help keep the discussion related to the article.
The main thing I was advocating was that software should allow fonts to be bigger regardless of physical size, but clearly I've somehow allowed my argument to be horribly misconstrued.
More to the point he is using multiple edge cases at the same time and dislikes the result he’s getting. He then suggests other people accommodate him.
Sorry, as long as the site still works it’s simply not worth it.
The A.V. Club took flak for turning all their lists into slide-shows on desktop. Their response was to tell people to adjust their browser width to force the mobile view. When you load a page, it preloads the assets for both views and switches based solely on window width. If you play an embedded youtube video and try and toggle full screen mode, the site reverts back to slide-show and breaks the video.
That's horrific. And the content is off center at full res so they can load their sidebar that well, isn't so much as off to the side as halfway into the center of the screen.
Is that really an issue? Javascript is basically universally supported on the web.
Users with NoScript will just have to live without some functionality. I'm sure they are used to that already, since a large fraction of websites use JS for styling. (I use NoScript)
When people lay out desktop sites, 960px is the smallest common minimum design width. Many of these sites are statically laid out, and if rendered with the width of 949px would require horizontal scrolling.
Yes, if these sites were not statically laid out, and instead gracefully handled any size they happened to be rendered at, providing a viewport width of 949px would not be a problem.
Personally, I'm not a fan of having a web site designer thousands of miles away from me just decide what font and text size I should be using to read their web site. Why not let the browser more easily control/override this? We already have PDF if your content truly needs pixel-perfect layout. Browsers have kind of dropped the ball. They're limiting user choice and slowly turning into desktop publishing platforms rather than being agents of the user.
Most browsers have a "minimum font size" setting, which would be applicable here.
In general, CSS already provides a bunch of generic font families and sizes. So a page could style something as e.g. "sans-serif" and "large" - and then the browser should figure out what this actually means according to user settings. The problem is that very few sites actually use these. But for those that do, the browsers do the right thing - and, again, most of them let you configure what the generic font families map to.
It could be easier in Firefox where it applies per language, with no "just set everything" option (at least Latin and Other are needed for english). I highly recommend using it, although it does break sites occasionally (seems like less often these days).
And it would have been avoided entirely if HN simply used relative font measures (em/rem) and allowed the user just set the damn base font size in the browser settings.
Do you also think every site should come with a built in screen reader? Accessibiliy should be about enabling everyone to use the website - using additional tools if needed - not to dumb it down to the lowest common denominator. If zoom / min font size breaks things complain about that, otherwise don't force giant fonts on everyone else.
As it happens though, with the navigation design they chose, the entries wouldn't fit at that width.
They certainly could have added an extra breakpoint where the navigation becomes smaller before bailing to a hamburger, but of course that does add complexity.
I suppose, but "Deliver with Just Eat" is a pretty long, and an overall odd choice for a top menu item. Wasn't clear to me that it meant "drive for us". And that's what's eating the width.
I prefer to browse with portrait-mode windows, and often find that sites give me the mobile layout unless I stretch the browser out wider than I'd prefer. It is annoying.
> The author's proposed solution is for sites to use DPI instead, but this would thwart the preferences of users who use scaling because they want the whole site to look bigger.
Agree. I sometimes browse the web on my TV - and I sit about 2 metres (or 6 feet) away from it. So the TV screen occupies a similar portion of my field of view that a phone would, and I usually browse at 150-200% zoom.
DPI might help you figure out the size of the screen, but it doesn't tell you how much of a person's field of view that screen occupies, which is what really matters.
Yes, field of view is what really matters, but scaling at the OS level (like TFA's author is doing) is a good way to correct for unusual fields of view. Got a higher-than-typical DPI and/or ridiculously far away screen and/or vision impairments? Scale the OS up. Got a screen with lower-than-typical DPI and/or touching your nose and/or amazing vision? Scale the OS down. You need the entire OS scaled, not just web pages.
"CSS pixels" are kind of a roundabout way to conceptualize it, but they solve the problem of proper readability once the OS scale is correct for the user. The combination acts as a proxy for field of view.
Then there's detection of course/fine pointing devices, as already discussed, to further augment the layout for proper target area.
I don't believe anything else will matter if the above is accounted for.
I feel like I must be missing something, because I don't understand this author's point at all.
"Lots of websites think “Vertical Screen == Mobile User”!"
No, they don't - They think a 720px wide screen is a tablet user, which is probably a fair assumption.
I could equally write "Just because I browse zoomed in 500% doesn't mean I'm on a mobile"
When you zoom in, things get bigger, so fewer of them will fit on the screen... You have a choice between horizontal scrolling, or the website showing you the version of itself designed for smaller viewports.
Looking at the "How it should render" screens - I just checked the Guardian site, and that is exactly how the website looks at 1080px wide. The author admits that because of their zoom solution they are running at an effective width of 720px, so maybe just.. don't do that??
The proposed solution doesn't seem to solve anything, because physical size of the screen isn't the full story, it also depends on how far away from the screen the user is - which the browser can never know.
I have one 1920x1080 monitor and one 1440p monitor. On both monitors, I regularly make it so that each screen is used by 2 applications.
A lot of websites think 960x980 is mobile. *half* of a 1080p screen.
It's bad and a huge assumption on their part that their website should only be seen in full-screen mode, or half of some 4k screen when the most popular resolution is ignored in a productivity usage.
To expand on this, my work responsibilities often but don't exclusively involve monitoring logs or graphs, and usually I have one monitor dedicated to this. My goal is to encourage myself to look at it every time I remember to do so, and greasing the wheels means tiling windows so I don't have to touch anything. I'm peeking at them like my rear view mirrors.
If I haven't set up a vertical monitor, that's two browsers with half the screen (or 55% with some clever overlapping to clip margins). If I got around to rotating my display, that's could be a portrait window or still only 1100 pixels wide.
I'll play devil's advocate here and say it's not objectively "bad". Looking at the analytics of our most trafficked sites the "tween" widths (where 960px falls) are such a small fraction of overall traffic that convincing a client to pay for queries targeting that dead zone would essentially be a non-starter.
Ideally, would every website deliver aggressively optimized experiences across all viewport widths - sure. But at the end of the day someone is paying the bills.
And, admittedly, 90% view and everything seems to be how it’s supposed to be afterward.
My bigger problem is designers probably not using the website on normal machines, but instead on their 4K or 5k perfect color machines and assuming it works everywhere.
Hell, the sites may just think it means the user has a narrow window. And that's reasonable. A nice thing about the responsive web is you can have a small browser window and it should work.
Why don't browsers tell the server whether the user has a touch screen? This seems like a perfectly reasonable thing that the website should know before delivering the page, and users who are hyper privacy focused could toggle a setting to not send this info.
Thanks. Does the server really send the info to construct all possible page configurations for all possible devices? And if so, why are the websites still rendering with touch-interface objects when we doesn't have touch, as reported by OP? (The lack of touch screen ability seems like it should trump things like screen resolution.)
Laptops and desktops can have touchscreens too. When having a small viewport less stuff fits on screen and thus a different design is required, we may associate this with our smartphones but they also work for mouse/keyboard input.
I know large screens can have touch. I'm asking why they are sending the instructions for rendering a page requiring touch controls to devices that don't have touch interfaces. (Seems like a waste of bandwidth, but maybe it ends up being insignificant overall.)
As a product manager, my immediate response is... not worth the time.
You've chosen to have a unique setup, which is fine, but your use case represents some absolutely miniscule fraction of users. On top of that, it's not even that websites are unusable, just that they're not ideal.
When you decide to do weird/special/unique stuff, don't expect the world to adapt to you. You can rotate your monitor back or live with it. The idea that companies should spend engineering/QA/PM resources to deal with this is... vain.
You don't need to rotate your screen; just shrink your browser. I know that lots of people like to use fullscreen windows, but that makes me feel claustrophobic; text ought to be formatted in narrower columns for comfortable reading, so I like narrower browsers. This often fools websites into sending me the phone layout, which is unhelpful and annoying.
Don't think that's quite right either. Pointer coarse would just refer to the device used for pointing. Using a tablet with a mouse would be "pointer: fine" but it's still a tablet.
As always, the issue isn't black and white. There is no solution that always works, because it depends on what you're targeting. If you want to scale elements to be easier clickable for people who might devices where it's harder to click/tap accurately, then "pointer: coarse" makes sense. If you're thinking about scaling elements on the website, some other solution fits better. Which one? Again depends on what you're aiming for.
The spec distinguishes between "pointer: coarse" and "any-pointer: coarse", where the former only asks about the primary pointer. I'd assume that tablets would leave "pointer" unchanged even if a mouse is plugged in, though I haven't verified that.
And aside from that, shouldn't a tablet where a mouse is being used as the primary input show buttons sized appropriately for a mouse, rather than larger ones? The whole idea of making buttons bigger on mobile is to accommodate thumbs, so it seems like this media query is exactly what we should be using.
> Using a tablet with a mouse would be "pointer: fine"
I would want to check this empirically before accepting it as gospel. At least on the iPad, a mouse pointer is kinda halfway between a finger and a classic mouse pointer, and having to guess, my guess is that Safari doesn't change the designation just because there's a mouse plugged in.
This discussion isn't about screenreaders or accessibility - and there is nothing to suggest that being delivered a mobile version of a site would make it less accessible by default. In fact, speaking as someone with a blind family member who has done extensive reviews of highly trafficked sites - the mobile version is often vastly more accessible than the desktop version of many top ranking sites.
All of that aside, I think you're being disingenuous in trying to strongarm this as some sort of rebuttal to parents comment.
Accessibility features are almost always not worth it purely from a profit point of view. They get added because as a society we decided that everyone should go out of their way to accommodate these users because they have no choice and should not be locked out of life.
The author here can simply deal with it or turn their monitor the other way.
This isn't about them. This is about a guy who chooses to have his monitor vertical. Don't take things wildly out of context in an effort to make it sound like people have made points which they absolutely have not.
But is this unique? Lots of people prefer to have windows that are significantly taller than wide - just like books are. I'd love to see some hard data on this.
> The idea that companies should spend engineering/QA/PM resources to deal with this is... vain.
The author gets a mobile layout not because of the portrait mode but because of zooming on the websites. Most responsive websites do not care about whether the screen is in portrait or landscape.
The real problem is that designing for different screen sizes, especially with responsive design, is very difficult.
For my personal projects, screen size is the factor used to determine layout. Mobile/tablet/laptop/desktop is irrelevant. My goal with smaller viewports is to make the layout as similar as possible, without the user having to scroll horizontally. Because I don't want to change the layout too much, I do not use hidden navigation menus.
Hamburger menus are terrible - I see them as a design copout.
Lolno. I have to make Firefox take only half the screen, otherwise HN will render wiiide lines with text. I cannot read lines with >200 characters, then I miss the mark when jumping to the next line when it's multiple lines in a paragraph. HN is also the only site I have zoomed in on desktop, as the font is unreadably small on high dpi devices.
And on mobile I find it impossible to hit the upvote arrow.
I prefer that way, way more than going to, for example, Github and doing a code review and the website refusing to give me more columns to look at in side-by-side view, because they think that the number of lines they've enabled is perfect and want to have the sides of the screen be full of whitespace that you have to modify the layout of the website to get rid of.
Or random blog sites that become a narrow column of text and a *huge* amount of whitespace on either side.
Browsers should have more say. In a perfect world, the web developer should not even need to know the browser's width or height, whether it's a phone or computer, or what kind of input devices are available. The developer should simply provide some kind of semantically tagged content (text and images), a list of suggested colors and fonts, and let the browser make the final call, based on what's best for the particular platform and screen size.
Somehow we've gotten to this world where the web designer expects almost-pixel-perfect control over the layout of every little thing on the page, user's preference be damned. You're not laying out a magazine page in a desktop publishing application!
I can read long lines just fine, and I like that the full width of the viewport is used.
Because HN is designed so simply, you can trivially get the layout you want (half width lines) and I can also get the layout I want.
If HN instead tried to artificially limit the viewport in code (which is something lots of web developers do), they would break all sorts of other use cases for no reason. That's what I mean when I say websites tend to overcomplicate their design.
I read HN on mobile all the time, what is the problem with it? The only issue i've noticed is being a bit harder to tap the show/hide branch icon but it is a minor issue.
That's why i like to keep an 19" TFT screen as a third display on my desk, most websites render perfectly on it and i can always have a browser in the foreground.
And yet quotes don't wrap to any specific size, so you end up with an awful horizontal scroll bar.
There is no way to format your text, even stuff that's available since MS Word 1.0, such as bold or italic. Even science papers have formatting so I don't buy the "overuse of styles" BS.
There is no way to have avatars or some other ways to distinguish users (or mods!) to make this place feel more like a community in real life. I've gotten used to it but it still sucks.
The contrast is super low.
HN is an MVP for a super minimalist forum that wouldn't fly for any other kind of community except for the intersection between hackers and wannabe entrepreneurs.
Yes, because avatars and signature blocks (which are useless, I agree), couldn't possibly be designed to be tasteful and fast to load. Especially avatars. A 30x30 image of any kind would be enough to convey more info about the speaker.
Now try a screen reader (on a mac, Edit > Speech > Start Speaking will do nicely).
Spoiler: You mean mathematical sans-serif bold small l, mathematical sans-serif bold small i, mathematical sans-serif bold small k, mathematical sans-serif bold small e, mathematical sans-serif bold small t, mathematical sans-serif bold small h, mathematical sans-serif bold small i, mathematical sans-serif bold small s?
Why don’t people point out how terrible screen readers are then, instead of criticizing people posting online who cannot be reasonably expected to stay up to date with Unicode and screen reader functionality?
Yes, I know people do things like that (mostly on Twitter, it seems), but I wouldn't recommend it; it'll interfere with searchability, copy/paste, etc., and generally make the text less interoperable. The mathematical alphabets in Unicode are intended for specific technical uses where the typeface is an inherent part of the symbol's identity, not for styling normal text.
I’m much happier that it isn’t a “proper” community with avatars & such, fwiw. Much like I’m not fond of small talk, I’m also not fond of the obligations that come with social media.
If you weren't aware https://news.ycombinator.com/formatdoc may be helpful. There are some basic options for text formatting on HN, including italics and bold.
Sure. Now let's say you're shopping for a brand new rug for your living room. Are you going to buy it from a site the looks like HackerNews? If so, I'd venture to say you're in the minority. A used rug from Craigslist, perhaps, but a brand new rug costing hundreds, you're going to want a site that looks VERY professional.
So you’re saying “professional == follows modern design fads” as a proxy for how legitimate a site is. And maybe you’re right that is a somewhat useful (if unreliable) proxy for legitimateness, but it’s not an argument that it’s good design.
Actually I've bought rugs and computers from websites not much more complex than HN. Both sets of transactions went smoothly and quickly with no issues. I wish I could say the same for some very flashy websites I've used. On some I can't even get a delivery estimate until I've submitted credit card etc.
HN is almost useless on mobile. Tiny UI elements that are hard to hit, people using code blocks for quotes that cut off after the first few characters, etc
At least it allows for pinch zooming, which is (IMO, of course) an acceptable compromise. Maintain readability for the text while still making it possible to hit the UI elements.
Pinch zooming works on HN, which helps me hit the buttons. I might prefer slide-to-action like narwhal's Reddit interface, but I'm OK with HN not being quite that fancy.
Almost all websites are pretty minimal in terms of their
features, but they're built as if they were an in-browser image
editor.
Reddit is barely more than HN with pictures and a LOT of bloat
inbetween. It could be as minimal as 4chan-style imageboards if
you add voting and a slightly different comment view.
Youtube is just a tiled list of thumbnails or an embedded video
player followed by a list of thumbnails. It could work 100%
without JS outside of the video controls. Instead it's a huge,
slow mess. It's also inconsistent; in my case it scales the
list of videos from subscriptions to about 50% of the browser
window's width, leaving a chunk of empty space on the sides. The
startpage with basically the same layout always uses the full
width.
100% agree. The kneejerk reaction of "well HN is so simple, of course it has a simple design" has the causation backwards. You only realize how simple HN is because they stick to a simple design!
99% of websites are (could be) just static text and images. Facebook, Reddit, CNN etc could look like HN. Amazon could look like craigs list. The amount of sites that actually need and are enhanced by JS bloat is very low.
A message board like HN is more difficult than you think to get right across a wide range of screen sizes, just because comments can nest many levels deep. HN arguably has problems of its own in that regard.
I can't downvote (I think?) and I don't miss it. I use an android client (Materialistic) that doesn't even provide me with an option to do so, and I haven't looked for a way to do so. If I disagree with a post or comment and don't want to add a response, I just move on. If I'm in the browser, I'm probably not even signed in unless I want to upvote or save something.
It’s not that hard to display a few paragraphs. It’s hard to display complex pieces of information while also making them look good to the client (which, we should remember, pays our bills)
It does clamp text at some max width. If you have a couple 1440p monitors try stretching the browser window across screens.
Its actually one of those cases where the old news print model of multiple columns would work well, but that is much harder than it should be with CSS, so pretty much no one does newsprint style scrolling where you read all the columns and then scroll to the next set.
I'm curious what your menu solution is. I agree hamburger menus besmirch the good name of the hamburger, but for longer menus they feel like at least an acceptable solution.
I like gear icons, sometimes they don't map to exactly the semantics of what is in a menu, but if there are no other possible menu elements than I know to go to the gear icon.
I've become used to the hamburger menu, but it still doesn't catch my eye (Chrome's now three dot option is even worse at this), gear looks noticeably different than the rest of the UI and so I can easily spot it for options.
> Hamburger menus are terrible - I see them as a design copout.
I am genuinely interested in why. The only reason I can think of, is that they may me unintuitive, but I think this is becoming less and less of a problem.
Hamburger menus are an accepted and pervasive design element. That does not means it’s good design, but it means that users are familiar with the concept. Familiarity goes a long way to ensuring good UX.
Just use the word "menu". The hamburger menu (and its cousin, the three vertical dots) have no analogy to the real world.
Sure, it has become more common, but for anyone not already familiar with it, it is utterly useless. You have to be willing to click random things to discover what it does.
From personal experience, I had to train both my wife and mother to look for them, neither of whom had the patience otherwise to figure out these cute designs. They may be common at the sites you look at, but that doesnt help people who have only used sites without them, or only used portions of sites accessible without clicking on them.
His proposed solution -- measuring screen size in physical display points -- is futile.
He writes it directly in his article:
> My monitor’s native resolution is [w × h device pixels]. But I find the fonts slightly too small at that resolution – given how far I sit from the screen. [So I use DPI scale factor R, what] translates to an effective screen resolution of [w/R × h/R virtual (CSS) pixels].
(In his case it is 1080 × 1920 / 1.5 = 720 × 1280). Measuring screen dimensions in physical display points, like
var dppx = window.devicePixelRatio;
var screenWidth = screen.width * dppx;
var screenHeight = screen.height * dppx;
reveals nothing about your preferences and conditions.
The moment he decides to get another second vertical monitor and put both just a bit farther he will be back on the square one.
You may have super tiny device with super high density display close to your nose, look at a screen on opposite side of your room that can have same density (what would be a bit wasting resources, but anyway) or look at super large billboard screen across the road.
Until the page will know exactly:
- how far is the screen from eye of its observer,
- observer's eyesight conditions,
- and observer's perceived visual size preferences,
there will be no way to solve virtual pixel problem the way that will make everyone happy.
You can query for aspect ratio in CSS, yes. This can be useful for figuring out whether it's better to place something as, say, a sidebar vs a footer. The sites they are complaining about, however, are only looking at the horizontal dimension.
I think primarily that's for constraining a div's aspect-ratio. Like making sure you have a div that's always 16:9 to hold a video player. I'd be interested in hearing other use cases, though.
The aspect ratio media query just lets you apply certain CSS to the page depending on the viewport aspect ration. It does not set an aspect ratio on an element.
Maybe there’s something I’m missing, but I’m not sure how knowing the aspect ratio of the screen would help make an element 16:9. If my browser is narrower or wider, that doesn’t affect how I would style the element.
I feel like this is a more complex problem to solve than it seems at face value or the author implies, especially considering tablets of varying dpi.
CSS dpi media queries are unsupported in Safari mobile and desktop, so that increases the complexity significantly.
Beyond that, the fact is most web layout is still done in px or other non-fraction-of-the-width units, so it’s often a matter of the wider layout simply being broken at smaller widths, rather than just refusing the display.
There’s a good reason why there are no real DPI media queries: You should not decide how big things appear on the screen, that’s up to the user. The user has the ability to change resolution or to change the website’s zoom level, you should never access the real size and decide that a button must be exactly 1cm wide in real life on every screen for everyone.
Just design for the default and then people will zoom or change resolution if the default isn’t enough.
Yeah, I was trying to find a way to create a toolbar with buttons and make sure the buttons are not too small or not too big. DPI info is not present and different tricks to work around this will fail on different phone models.
I wish I could ask the browser "what are the dimensions you the browser use for your buttons" so I can use same dimensions too and the user could configure this in his browsers and everything would follow it.
In theory this is what css { font: caption } should do. There are other font shorthand’s for menu text, icon labels, dialog box text, etc. that should clue you in to how a particular system UI is scaled, if browsers are doing it right. (Of course they also might not because of fingerprinting risk)
Note that this is different from { font-family : system-ui } which doesn’t include size information.
Caniuse sadly doesn’t have much info on font: caption support.
This post makes it sound like this is an issue that could only possibly affect 1 user, the one guy with a vertical screen running Linux with a nonstandard scaling factor. But I have the same problem (worse, even). I run a bog-standard MacOS w/ Safari machine and but I browse the web at 1.25x and I don't maximize my browser window. That also punts me into the "you must be a tablet" bucket, except I don't have the luxury of 1280 vertical pixels!
The real problem here is actually that developers make sure their site looks reasonable at the phone and desktop breakpoints, but it's rare that someone specifically designs for the "tablet" breakpoint.
Quick examples:
- https://pkg.go.dev/net/http this website is terrible to use at the tablet breakpoint, the main content is literally pushed below the fold for me
- https://neutrinojs.org/installation/ they threw away the right-hand and left-hand navigation so that they could make a page that is much too wide to read comfortably
It's a difficult one though - say I have left menu, and a sidebar on the right, and a central column with my copy. Very roughly, at about ~1350px (so neatly displayed on a generic 1440 laptop) I have about 250*2 (500px) for my sidebars, about 800px for my central column, which at a decent font size will give me a 'right-ish' about of words per line, and a few more pixels for gutters.
As you start to make that smaller - 1200, 1100, something has to change. We can maybe adjust the font size in the main column, maybe there's some flexibility to shrink the sidebars (but maybe there isn't, because we need an ad in there, and that can't be resized). So we have to adjust - lose a sidebar to a hamburger menu, or change our horizontal menu at the top to include the most clicked links (and not the ten links we have before). Maybe the search bar becomes an icon, because it's more important we push the "Buy Now" button than give people an option to search, etc etc.
It's an art - what do people need the most? What will make them convert? What can we remove first? What resolutions are most used, and how do we optimise for that?
I see your point, and I'm not complaining about that.
As you point out:
> Maybe the search bar becomes an icon (...)
I'd already be ecstatic about that.
I'm talking about features which are essential to a website that just disappear completely because the owner thinks "no one on a tablet will ever want to use this".
Haha, yes, it's definitely a balancing act! Thankfully analytics and heatmaps are a good start to figuring this out (even without applying common sense fundamentals)!
We use a web-based time tracking system that appears to assume that you're either on a device with a touch screen, or have an ultra wide display. You can't easily scroll side to side without touch, so the second best option is full screen on a ultra wide screen, so you don't need to scroll.
I long advocated that website started to use the more of the width of the screen on desktops, to avoid unnecessary scrolling. However, I just a frequently have two windows next to each other.
There's no real good way of satisfying all use cases, but it generally seems like desktops are being neglected when company design websites. Previously mobile seemed to be hacked on to an existing site, now everyone seems to go the route of: If it's good enough for mobile, it's good enough for desktop users.
As with every engineering project, there's always a point where you have to look at how few people are within a certain use case and decide it's not worth the effort to cater for them
As a vertical PC user, you're in the vast minority, and you can't really be surprised that people don't want to spend the extra time (and money) developing to support your edge case
On work, I know a couple of people who use vertical screens (including me). At home I have a large 43" 4K monitor (no scaling). A lot of websites think it would be something like a 23" 4K monitor and everything on the website is super large.
As rule of thumb, as more fancz the website is, the more is the website broken if you don't use just a 08/15 monitor.
The proposed solution for developers doesn't work any better; DPI is correctly calculated on desktop, but nearly always wrong on phones. So fixing sites for vertical desktop monitors will break them in most phones.
I’d express it much more strongly than you have: doing what this article suggests is catastrophically wrong. For layout purposes you must not look at physical resolution. Physical resolution should only be used so that you can render on scaled displays at higher quality, e.g. by choosing a higher-resolution image, or by scaling your canvas by devicePixelRatio so you can draw more precise lines.
The proposed solution is not just no better, but far, far worse.
Wait, so sniffing on screen resolution is the way web developers distinguish desktops from mobile? That's just crazy.
There should IMO be a preference sent, "I'm on a portable, touch-enabled device". I'm guessing it doesn't exist because it would add a bit to the fingerprint.
> Wait, so sniffing on screen resolution is the way web developers distinguish desktops from mobile? That's just crazy.
No, it's not how it's done. And there is generally no logic trying to see if it's a mobile or not. One just have various designs for various sizes. When he has a 700px wide display, what else can the website do than collapse the content when it's not enough space for it?
The general idea with well built responsive design is to build a site that works at any width, reflowing as things would break. You can try it by just resizing the window of most popular sites to be progressively smaller.
It’s honestly been a significant improvement over dedicated mobile layouts and for the most part works pretty well.
the way that web developers generally do responsive design is to use media queries checking the width of the screen they are on, as opposed to the device width.
This is the suggested way because if you check the device width you know that they are on a small device and thus probably mobile but your styling changes for small windows (less wide windows) do not get applied, so 'best practice' is to check the actual screen width. Hardly anyone checks the height because for web development height is generally not that important.
But this is often not useful because a lot of web solutions style things based on JavaScript and CSS and while the CSS will rerender automatically based on changing the screen size the JavaScript needs to detect you've changed the screen size and then rerender. So then there is a discussion as to how many people really resize the windows and do we need to catch this resize to do a rerender even though doing so is irritating and can be a resource hog (fixable by extra code but maybe better not to code at all!)
But there are lots of other ways to detect if you are on a mobile device, you can detect if touch screen events are enabled etc. but then what if you have one of those weird desktops that became possible a few years ago (I nearly wrote popular instead of possible) where your laptop's monitor also has touch screen events.
As a general rule it is best to do things based on the capacity of the system, and not by what type of system it is, but as the capabilities of our systems exist in infinite combinations it follows some things will just fall through no matter how exacting you try to be - maybe especially if you try to be too exacting.
It's a bad habit, but it's pretty common. Really, there's two distinct things to consider when building responsive design. One is viewport size (and really just width in most cases) and the other is touch vs mouse. Vertical monitors is one case, but so is touch-enabled monitors or mouse-enabled handhelds. Most of those are considered small enough edge cases, that it's not worth investing. Most websites look kinda crummy if you use a phone in landscape too.
I used to insist that designers never say "phone, tablet, desktop" and instead say "small, medium and large" but it never stuck.
Client hints (proposed successor) are the same thing but more selective. That is a site has to request extra information rather being given right away. Among them are platform and mobileness.
In this case, "portable, touch enabled device" wouldn't match what we're talking about. Someone with a large tablet should receive the version optimized for larger screens.
The website is saying "if your screen is at least this big, I'm going to show you the version for big screens". The OP has an unusual setup where their big screen is reporting as a smaller screen.
> Someone with a large tablet should receive the version optimized for larger screens.
Not necessarily, because the “smaller screen” layout tends to be linked to the touch one e.g. larger active targets, while the “large screen” layout is optimised for precise pointing devices (mice) and may be nigh impossible to interact with using fingers.
Screen resolution is, more or less the best approach.
Layouts need to fit a size, not a device, so that's why media queries based on the screen size are usually the best approach. If I resize my browser to make it smaller, I should get a layout to match that. If I'm using Safari on iPad, docked to the side of the screen, I should get a layout to match that. These are all about screen sizes, not "mobile vs desktop".
For testing interaction cabailities, there are the @media (pointer: coarse) and @media (hover: hover) media queries for testing touch vs mouse, and hover capabilities, but it's important to not rely on these for mobile vs desktop layouts otherwise tomorrow a MS Surface user will post "Just because I have a touch screen, doesn't mean I'm on a phone".
Best practice dictates "mobile-first responsive design" with "progressive enhancements." So designing first for mobile and touchscreens seems ideal, and then adding special features for larger resolutions, and, in a separate media query, for devices with (hover: hover).
> Wait, so sniffing on screen resolution is the way web developers distinguish desktops from mobile?
There’s really no other information since “physical” dimensions are completely fake: a CSS inch is 96 CSS pixels which are “one pixel at 96 dpi at an arm’s length”.
Yes, they define a bunch of @media filters in css for different known screen widths. You usually get a surprising look when pointing out that it is crazy. “How else would you know that?”
Something as simple as “use-case: handheld | bellyheld | desktop” property? Css designers missed this opportunity completely.
You don’t, because you don’t know how far from that screen a user is. User can override default mode in a browser’s toolbar. That’s what OP wants but has instead to jump through dpi/font/scale hoops to achieve it. You may want to use desktop, tablet or mobile look that is not related to your device width.
I think the most important factor is not really screen resolution or size, but "cursor precision".
I'm fine with HN on mobile, but it is really hard to press the buttons with my large fingers on a mobile screen. But much easier on a 800x600 monitor using a ball mouse. For HN I don't really mind, as a pinch to zoom.
To check for touch, there is `Navigator.maxTouchPoints` but this might backfire on some laptop which have touch screen (which you usually use for drawing rather than UI, but your mileage may vary).
But I think the core issue is much earlier in design. Many websites and app have complicated design/UI while it could be simpler, and they split their UI into mobile and desktop very early in the design process, which leads to two very different version. And while I agree that mobile and desktop are different experience, I think you can keep them close in term of UI and UX.
For example, let's say you want tooltip, on desktop this is a normal UI control which is natural, but on mobile it is not, so instead of using tooltip on desktop and "think of something" when doing the mobile version, we need to design early for both. Today, many website and apps are designed with a "mobile first" mindset, and this cause problem when used on desktop. The solution is not better detection of either platform, but better design to keep them as close as possible.
Of course, there is also the issue of scaling text vs scaling the whole site, and this is not very well handled by many website, even with the "let's use em/rem units".
One of the best features of my Lenovo Chromebook Duet (a 10" ChromeOS tablet) is that it reports itself as a laptop with 1920x1200 screen so you get actually usable webpages and not the mobile crap.
I have 3 monitors. Once of them is portrait mode because it's easier to read longer posts and articles this way.
I've never had such a problem as described by the blog post, but my resolution doesn't drop to 720px like the author.
Scaling the size of fonts has always been discouraged, even by Windows. I used to use larger fonts on Windows way back and it would mess up the spacing of many apps, because it's just so uncommon. I fought against the wind for years and gave up.
I remember learning how to get my site to display decently on different screen sizes. I got an abridged history of past attempts: "handheld" CSS media type, then media features "device-height/width, resolution, pointer, orientation, aspect ratio", some people try to use the User Agent, others target a huge list of specific device resolutions, webkit has a device pixel ratio?, it all seemed like a huge mess.
Then it turns out the solution isn't CSS it's the HTML "meta" tag:
> that can leave some sites too small to read properly. I need to zoom out the page
Well, then all I can say is that the CSS breakpoint is doing its job perfectly. It switches to layout you can read at this (emulated) screen size. There is nothing to fix.
Look, I don’t think it’s unreasonable to assume that a 720px wide device is a phone. As a webdev I completely zoned out when he started talking about DPI and such. Nobody is going to completely change their methodology around breakpoints because of like a .01% edgecase, when the current one works great the remaining 99.99% of the time.
The reason I consider this a true edgecase is that he combines a vertical orientation of the monitor with scaling. That is just bound to cause problems. Had the width been 1080px most websites would at least have given him the tablet layout, which would be more usable on a desktop monitor.
I'm kind of confused about this - I'm sure the author experiences real problems, but I wonder if there's something else at play here?
I've never actually seen screen aspect ratio media queries used in practice, nor have I really seen them advocated for. When I load www.theguardian.com on my portrait monitor (1441 x 2561) I get the desktop layout https://imgur.com/a/ZpUI95Z
Absolutely yes design your breakpoints around screen width. Using aspect ratio seems like a poor choice.
Even then - when I set my resolution to the same 1080 × 1920 the author states, The Guardian still renders the "desktop" layout. The more compact layout from the doesn't kick in until 739px.
Maybe it's their font-scaling settings are getting in the way and changing the viewport resolution?
The “solution” he gives for website devs is to “stop naively using screen resolution”. But the thing is, an iPhone 12’s resolution is 2532‑by‑1170-pixel at 460 ppi - bigger than his 1080×1920.
And of course realistically he is probably seeing sites with breakpoints built entirely on min-width/max-width, which gives the size of the browser canvas.
The Guardian, for instance, has a lot of "@media (max-width: 71.24em)" in its CSS. Screen height? Zero fucks given. I turned my desktop monitor to portrait and I can change between desktop and phone versions by shrinking my desktop window and/or changing the font size. Which feels like a perfectly sensible way to tackle the problem if you are coming from a place where you are thinking in typography.
eat.co.uk? Tons of "@media print, screen and (max-width: 768px)". Screen height? What's that?
popsci.com? A lot of "@media screen and (max-width: XXXpx)", where XXX varies a lot - every number is different, the lowest is 325px and the highest is 1720, someone's been thinking about a lot of edge cases in that layout.
----
The fundamental problem of "I am getting the mobile site on my desktop" still applies, but his theories as to why are wrong.
Really I feel like he is sitting in the middle of a very small edge case. Not many people use portrait screens on their desktop. And of those people, how many are bumping the effective resolution by changing the scaling? Finding a solution that can work properly for him, and not fuck things up for people with failing vision (and maybe even run afoul of accessibility laws by doing that) is gonna be a lot of work for very little return, and he should just bump his font size down a little and live with that, or do some CSS injection on every single offending site if he has a lot of time to blow on this.
At least these sites have a desktop oriented UI. Modern Gnome just assumes you're always on a phone (even though the phones capable of running Gnome are still extremely niche.)
Ironically, the author of dpi.lv (https://lea.verou.me/) doesn't even bother to have a "desktop-friendly" site. On desktop everything (font, header, images, buttons) is huge and ~50% of the vertical space is wasted. Not the best calling card for someone living "at the bleeding edge of web standards". Or maybe it looks Ok if you view it on a Mac?
It looks fine on mobile to me, scrolling is free, and filling 100% of the screen with information has nothing to do with if a person is "at the bleeding edge of web standards".
That's my point, it looks (probably?) great on mobile, but on desktop it's a mess. Maybe that's what they mean by "bleeding edge" - only that it's the eyes of some of the users doing the bleeding...
Cool, that's the theme WordPress recommended to use as default in 2020? Maybe I should ask them to buy me a Hi-DPI monitor... that would display a bit more content, but actually I'm afraid the lonely column of text in the middle of the screen would look even worse.
I appreciate this pain in the exact opposite way! Just because I’m on a wide (or big) screen doesn’t mean I’m browsing with a wide window! I’m the guy throwing off your resolution stats if you do analytics, I do all my non-phone computing at a desk with a 42” 4K screen @1x. As in:
- My available pixels suggest HiDPI, but that’s wrong
- My browser window is probably twice as tall, and half as wide, as you think
The worst I usually encounter gratefully is bad scroll position content disclosure (sites designed to show or transition content on scroll assume a certain height and don’t even check, or mistakenly assume I’m looking at a different header than I am).
I’ll say it’s actually hard to accommodate my use case. I built a site that uses scroll position to progressively present content and my own browser window was harder to accommodate than any other (at this time on a 27” monitor with the same pixel density before 4K/5K was common). Regression testing the more common screen/window choices was a huge slog. It’s almost definitely such a weird set of circumstances that almost no site would bother. I don’t blame them. It’s very challenging and very unlikely to be your visitor who needs it.
Mobile has some unique characteristics that don't fully allow agnostic design, namely:
- viewport changes size due to soft keyboard
- address bar hides/unhides during scroll down/up
For certain types of apps, like games, it's important to know whether a device is actually "mobile" regardless of size/resolution. Sniffing user-agents might have to come back into vogue. Who knows where "mobile browsers" will end up - maybe some giant 60" kiosk app, or other places.
Barring that though the article brings up good points and searching the web for how to detect mobile usually brings up the error-prone portrait/landscape resolution detection that the article discusses.
The full solution requires the knowing the resolution and the dpi to get an estimate size of screen in inches. At least with that we can be safe until next article "Just because I'm a 100" kiosk app, doesn't mean I'm on a phone".
Wholeheartedly agree. And this apply not only to vertical.
I have a Samsung Tab A Tablet (Model SM-T510) that has better resolution than my notebook (A Lenovo T430). A page that displays very well in the Lenovo (1366x768) displays like crap in the tablet (1920x1200) even when using it in the landspace position.
In the past I'd respond: just because I have javascript disabled doesn’t mean I’m on a phone. But unfortunately developers have dropped supporting HTML completely for even older cell phones. There's no more mobile.twitter.com that serves HTML for example.
> I have tried “Fractional Scaling” – it works OK on Wayland, but leaves all the fonts looking soft and fuzzy.
Ah, there we go. The real, underlying problem is that the scaling that would make this problem go away doesn't work for you.
Scaling the fonts instead of fixing the underlying issue and then deciding that all of web development is wrong for optimising for CSS pixel count (like one should) instead of manually doing DPI calculations (which everyone gets wrong, very often, and probably Javascript just to do a basic layout) is a silly solution.
Look for a blurry-font-rendering solution instead of a change-the-way-everyone-develops-websites solution, it's a lot easier to convince people that it's a real problem.
Width-based media queries are simply a corrupt idea altogether. In addition to the problem complained noted in the post, they give rise to other pathological behaviors I encounter daily. I increase the zoom of a page to better see an image, only to have the image shrink due to a layout change. I shrink a window to remove a huge empty margin, only to have the text recede even further.
They way they're implemented in browsers, width media queries are a UI antipattern. They violate the principle of least astonishment because their boundaries are invisible, causing the user to be surprised every time.
Sounds like a quick hack from developers. I'm guessing here maybe some fluid, generalized mobile design for a vertical layout. When developing for front-end I like to simply see how my layout may look generally with a horizontal / vertical view but with a responsive layout in mind and not necessarily mobile resolution.
I could see how someone might put in a quick, unideal hack and do a scaled to fit. I'm curious how often people are seeing this as I don't have a vertical monitor setup anymore.
Many years ago, when I was a little kid in dark 90s,my dad was picking up some cargo from the country's largest dairy company at the time. So we end up walking through the narrow passages of the production line and eventually end up at the account sitting in front of her very modern PC with a vertical screen!It wasn't even tilted,it was made that way! I looked at it and it looked so impressive. It took many years for me to see again someone using a monitor like that.
I've had a second portrait monitor for about 15 years now, and highly recommend it. I don't have many issues possibly due to my screens being 4k.
However, the responsive decision point is regarding the width of the viewport or window. To my knowledge sites don't care about the height at all. So the fact it is in portrait orientation (vertical) is not pertinent.
Once in a while I do have to zoom or resize the window if its size is not large, but it is not a burden that I really notice.
Forget the arguments about counting pixels for a moment... Mobile browsers have a "request desktop site" switch that seems to work pretty reliably, even though the viewport is still tall.
Yet when I tile my browser to the left or right of my giant 4k display, I frequently get a mobile site with text that you can read from across the street. Is there a way to jusr get a "request desktop site" switch that performs the same magic on my desktop browser?
I think the bigger problem is the design pattern of "mobile-mode vs desktop-mode". The document isn't meant to escape hatch on size, individual elements are.
It is common for serious users of time-line-based animation and compositing software as well as layer-based software such as Photoshop and Illustrator to use one display in portrait for the timelines and layers. I know I do.
I have tried using it for web-viewing, especially to find media assets such as stock footage and typefaces but usually have to move the browser to portrait because the sites usually don't display correctly on portrait.
I've been using 3 vertical screens side-by-side for years. Like web pages, source code is also long and (usually) not too wide. Being able to see that complete method / function without scrolling is invaluable to me. Square screens would also suit me well, but they don't exist, sadly (apart from very expensive Eizo).My current resolution is 3x 1440 x 2560, so luckily I don't get mobile versions of web pages.
The first DPI detector site detects my 55" 4K monitor as 442 DPI (5120x2880 at 13.3") when entering my resolution and diagonal size in inches gives me 80 DPI. The other one detects it as 192x192 DPI which is a much larger number. Maybe the first number means it should be 80x80 DPI but either way 192x192 is much larger. Maybe I'm missing something.
It would be really nice if there was something in the browser header to indicate whether 1) The user had a touch interface and 2) The user had a persistent on-screen cursor (both may be true) but, leaking that information also opens the door for more accurate browser fingerprinting so I guess, once again, we can't have nice things because of advertising.
I don't understand why websites don't place a button on mobile views that let the user switch to desktop view and vice-versa. That way if you guess wrong at least there is an avenue to get the correct view without messing with window sizes and monitor resolutions. Save the choice and they only have to correct the website once.
Similar issues here since working from home on my 19 inch CRT.
Easy solution, hold ctrl and scroll down with the scroll wheel. That zooms out a bit and the websites pop back to normal again.
Had similar issues with the crosshair in halo reach on PC, it was an oval instead of a circle. Luckily they fixed it a few months ago.
I think many developers/designers ignore device and dpi detection now. It has become too complicated, and the benefits are too few.
@media rules with min-width or max-width is really all you need; just make sure the breakpoints aren't so ridiculous that you serve the "mobile" version of your site to desktop users.
That still doesn't work very well. I have Firefox on one half of my 1440p monitor and vertical tabs down the left side. Web pages I see are tall and narrow, and many fall back to mobile style controls.
Just a quick note about a very prominent user of vertical screens: Professor Martyn Poliakoff, known for the Periodic Videos channel (which I highly recommend).
https://www.youtube.com/watch?v=Oy8ZMFXS_5E
Browsers should provide to websites the user's (typical) distance to the eye, and preferred zoom level. Maybe also the preferred type of input, to tell mouse users from finger users.
Obviously pixel count and screen ratio is complete nonsense, in this almost-glorious day of sweet variety of gadgetry. It will only become more of a nonsense, until we all switch to neural interfaces.
But since designers only have what CSS&JS provide, they cling to the pixel count and DPI, choose a font size according to someone's eyesight, and stick to that. This is bogus, and leads to fonts from something like two mm in height (ahem HN cough) to almost a centimeter, so I either have to stick my nose to the phone screen, or hold the phone at a full arm length and scroll like mad. And browser zoom is no help in this model.
Meanwhile, in the real world, all that matters is the visual angle of the font or image, and the user's eyesight. The first is dictated by the distance from the screen, and the second determines how much the content must be zoomed in from the perfect-vision scenario. In fact, since I wouldn't want the content to grow and shrink when I move my arm somewhat or lay back in the chair, perhaps devices could use some default visual-angle values according to their form-factor and typical usage, then adjust for the user's chosen zoom level, and report only one value to websites: either preferred visual angle, or zoom level from some global anchor value—whichever of the two is better to use for calculations.
With this info, the screen's pixel resolution affects only one consideration: whether a given line of text or other content would fit in the screen horizontally at the preferred visual ratio—or it must be broken or scrolled.
the author must be aware that his use case (vertically oriented monitor) is such an obscure demographic, that almost no company will invest in time to optimize this experience. His complaining about this situation is pure self-centered arrogance.
There is effectively zero benefit of optimizing for this use case.
I have the same problem, not because I have a vertical screen setup, but because I usually split my screen in two parts. I rarely have a website open in full screen, as I'd rather have a chat-window/terminal/editor/other browser window open in the other half.
On iOS it just changes the UA. This means that regular CSS-only responsive sites don’t change at all, unlike what the other 2 comments are suggesting. Maybe on Android it’s different.
People also assume phone users only hold it vertically. Most popular apps don't even allow landscape orientation. They can't even cope with varied screen sizes and orientations. I've actually found bugs when I forced them to try via split screen view.
I was just using my browser in half-screen mode on reddit and I got this: https://i.imgur.com/z5Sb7Mj.png ... my screen is a bad resolution ~37in TV...
If a client asks for it, I'll do it. Otherwise the use case for people with vertically oriented non-phone screens is so tiny that it isn't worth the effort. What are we realistically talking about here? One in twenty thousand, if that?
Some websites look and / or work better on phones.
Feature request to web browser developers: My screen is horizontal. I want a menu option to open twin windows, side by side, each taller than it's wide. Then emulate a mobile web browser in each.
Some sites go as far as to assume that I’m on mobile because my user agent says ARM. I’m getting a mostly blank page on amazon unless I’m changing arm to x86_64 in my user agent string, then it magically becomes usable.
That's both sad and hilarious! It reminds me of the rumor[1] that Microsoft had to go from Windows 8 to Windows 10, skipping 9, because too many clueless developers were grepping the version string for "Windows 9" in a flawed attempt to detect the Windows 95 and Windows 98 operating systems.
There have been attempts to define physical units (Firefox used to have a unit called mozmm which tried to be one physical millimetre), but eventual consensus is that (a) you can’t actually figure this out, because screens don’t tell you their exact physical sizes; (b) if it’s not accurate, there are exactly zero genuine use cases for it; and (c) even if it was accurate, it would still almost never be correct to use it. Remember that you don’t know the viewing distance, either—letters being 5mm high is all very well twenty centimetres away, but at four metres it’s utterly illegible.
I did that vertical monitor orientation before, it's honestly odd and a little hilarious trying to read long threads starting from top of screen and reaching the bottom screen.
This is an excellent post. I wrote about the new landscape of the web [1] a few weeks ago and how responsive web design is a complete failure in addressing that.
There are so many fallacies!
1. Tablet != mobile.
2. Mobile != Watch.
3. Desktops can be in portrait mode.
4. EV Cars like Tesla Model 3/S are closer to tablet than desktop.
The UA doesn't tell you anything about the screen the person is viewing on or the size of their window. If I resize a window on my desktop to 450x1000, showing me the layout for narrow screens is likely the best option.
Because a single user agent and present websites at multiple sizes.
Consider an iPad which can display a website at three vastly different sizes. Full-width, half-width, and roughly 1/5th width docked to the site. They should have at least two different layouts.
What if the person is using an Android phone connected to a monitor? As someone said in another thread: you design a view for a screen size not a device.
No. Just simple heuristics that work for most users at the expense of people who admit, like OP's opening statement, "I’m a weirdo".
Building responsive client UI is hard. In my experience here, the falsehoods HNers believe about clients is that it's somehow not hard. Or just a silver bullet away from being easy (like replacing JS with $faveLang). Or that resources are infinite such that every defect is explained by incompetence (except for, presumably, that HNer who is intimately familiar with resource finitude in their own life).
It's 'hard' largely because the standards bodies and browser makers fail to provide simple and expedient means to do the most basic of operations, making every little thing a designer wants to do a giant hack.
For something so universal ... there should be a very clear and unambiguous function call and at least a rational way to move through the fragmentation molasses.
More like testing for an infinite number of resolutions is expensive so developers only test on the main ones and the ones used by hackers on Pop_OS Linux that rotate their screen 90 degrees are out of luck and default to one of the tested resolutions :)
A collection of deep-deep dives on various topics would be a fun thing for someone who can build a nice website to do (You don't want to see my attempts at being a designer).
For example, "What every programmer should know about memory" covers memory but what about (as you say) screens.
Portrait viewing for screens bigger than tablets are edge cases of edge cases.
The rabbit hole is websites are supposed to cater for every screen size by pixel is ridiculous. At some point the user should respectfully use normal orientated/ sized device.
I wish for once that requesting “Desktop version” on my phone would actually give me a desktop view, not the same exact mobile view. Sizing based on viewport (a “responsive design” principle that I hate) gives me hamburgerized unusable mess.
I want to be able to zoom out to see the same page features as I would see on desktop. A lot of websites USED to work this way on ios Safari before “responsive design” became a thing. Now, there’s no way to get a typical website to give you a desktop-like layout when you “zoom out” because it automatically detects your viewport and forces you to hamburger no matter that you selected “Desktop version.”
I understand why mobile view exists. It’s more comfortable to read for probably most people. But by ignoring “request desktop site” because of the hubris of “responsive design,” it means that there’s no way for you to get desktop-like functionality & experience on your phone browser. That is a reduction in functionality from the smartphone experience of 5-10 years ago on many site that’d give you a desktop-like layout if you zoomed out.
An example of this frustration is that on a forum I frequent, if the viewport is below a certain size, user avatar thumbnails are hidden and text tables of values are all reflowed to an unusable mess where before I could zoom out and get a desktop-like view where the tables (which are just fixed-width straight text, entered by forum users) could be seen clearly.
The refusal to allow some way to get a real desktop-like view in “responsive design” is user-hostile.
One of the things "Request desktop site" is supposed to do is report a larger effective viewport. For a responsive site, that should switch it to a desktop view. Does iOS Safari not do that?
Good question. Now that you mention it, I do not know if the problem is on iOS Safari or the website. EDIT: I just tried it on HN (which is usable enough for me as-is, I’m just using it as a test), and it seems my effective viewport remained unchanged.
In this case the author is scaling their resolution, and so their browser is presenting itself to sites as 720px wide. Sites see that and show a layout optimized for a screen of that width. Those sites are acting correctly.
The author's proposed solution is for sites to use DPI instead, but this would thwart the preferences of users who use scaling because they want the whole site to look bigger.