Just because I have a vertical screen doesn’t mean I’m on a phone
shkspr.mobi
shkspr.mobi
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 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.
That said, sane breakpoints can usually avoid unexpected hamburgers on the desktop.
I learned this lesson the hard way. The client was on desktop. The users were 40% phones. Everything was great for months and months.
Then one day the owner of the company that owned the company tried to look at the web site on her grandkid's iPad. Fan met shit that day.
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.
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.
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.
Unfortunately, the horizontal scrolling UX with substantial wasted whitespace on the sides remains.
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.
“The small breakpoint is 768px wide? I guess below it it’s a phone, I hope you like burgers”
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 agree though, let me zoom on a blog post. The diagrams are often unreadable on mobile.
It doesn't help with everything, but the triple-tap zoom is quite useful.
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.
Given that we're increasing the text 2x or 3x, it's an important question whether or not we're also increasing the width of the scrollbar 2x or 3x.
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.
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?
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.
View > Zoom > Zoom Text Only
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.
My experience has been the exact opposite of what you're saying.
And the result is, 90% of the time, a site that goes from usable to unusable.
On many sites, this trigger the appearance of the dreaded hamburger menu.
Which they shouldn't be.
* Lay out content based on the viewport width, in CSS pixels.
* Use larger tap targets for coarse pointers (https://developer.mozilla.org/en-US/docs/Web/CSS/@media/poin...).
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).
As for why it is wrong, it is because you can't rely on it to make a Mobile vs Desktop distinction - i already provided an example why.
It's still not clear to me where you think this approach gives bad results?
Usage while walking/moving vs. sitting/standing at a desk.
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?
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 :-/
what would be really nice would be element-size-based media queries. you can use javascript to do it but that sucks
example: https://tv.avclub.com/the-hunt-is-on-with-clarice-the-equali...
Specifically, they have:
.comment {
font-size: 9pt;
}
.commhead {
font-size: 8pt;
}
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.
When I read that, I read, "we're ableist and here's a few crumbs so we can feel better about ourselves".
This is untenable as well. You'll end up with microscopic websites on high DPI phone screens.
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)
Setting aside the debate about separation of concerns. Yes, it has notable performance and UX implications.
> Users with NoScript will just have to live without some functionality.
Why should we prioritize OP's use case over that of NoScript users?
@media (min-aspect-ratio: 1/1) /* wide */
@media (max-aspect-ratio: 1/1) /* tall */
@media (aspect-ratio: 1/1) /* square */
Here, play with your window width to see: https://hypertele.fi/0000000000000000
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...
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.
¯\_(ツ)_/¯
What's wrong with using something like: @media (min-width: 8in)
To determine if someone is using a larger screen (or window)?
Edit:
https://hacks.mozilla.org/2013/09/css-length-explained/
Seems like 8in is just short-hand for 8*96px. Thanks for nothing, web standards.
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...
> 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.
* 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.
@media and (pointer: fine) {
your computer specific CSS rules goes here
}
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.
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".
As I read this I:
1. am wearing my computer reading glasses +1.5
2. have my browser set to zoom HN by 125%
3. am reading distance from the screen
I know programming and tech in general is a young man's game, but let's at least try not to be ignorantly ageist & ableist.
> But I find the fonts slightly too small at that resolution – given how far I sit from the screen.
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.
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.
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.
Sorry, as long as the site still works it’s simply not worth it.
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.
"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.
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.
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.
https://twitter.com/varjag/status/1050370136585187328/photo/...
"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.
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.
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.
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.
CSS can be used to style elements accordingly: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/poin...
No need to get the server involved.
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.
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.
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.
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.
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.
/eyeroll
All of that aside, I think you're being disingenuous in trying to strongarm this as some sort of rebuttal to parents comment.
The author here can simply deal with it or turn their monitor the other way.
Is it extra work? Sure. I thought we referred to that as polish.
Not sure if this exists already but the idea method would be to use the physical size in cm of the display.
Resolution: 3360 × 2100 Diagonal: 13.3″ Resolution: 2560 × 1440 Diagonal: 13.3″ Resolution: 2160 × 1080 Diagonal: 13.3″
(my monitors are 15.5" and 27" diagonal, my phone is 6")
Maybe I'm crazy for using my phone in landscape mode, but I'm not sure how I'm supposed to tell which of those measurements is a phone.
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.
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.
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.
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.
I consider that to be an utter failure.
HN works beautifully on any window / screen size.
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.
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.
I think many people, my parents included, would have trouble navigating HN on a phone. Especially upvote/downvote.
And on mobile I find it impossible to hit the upvote arrow.
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.
Except you're ignoring mobile devices.
Or random blog sites that become a narrow column of text and a *huge* amount of whitespace on either side.
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!
So an accessible site that follows modern design fads is probably the best thing to have (if that sells rugs).
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.
Are you entirely sure about that?
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?
HN doesn't have a "quotes" feature. Some users here have the unfortunate habit of abusing the code formatting feature for quotes.
>There is no way to have avatars or some other ways to distinguish users
Thank god. There's a lot I miss about forums, but avatars and huge signature blocks are better left in the trashbin of history.
That isn't an acceptable compromise, you end up doing a lot of horizontal scaling to read block quotes and zooming to touch UI elements.
It's not the worst, but it is trivial to do better.
what block quotes?
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.
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;
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.
(And that's quite OK, I think.)
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.
// The viewport is in a landscape orientation, i.e., the width is greater than the height.
@media (orientation: landscape)
// The viewport is in a portrait orientation, i.e., the height is greater than or equal to the width.
@media (orientation: portrait)
But then I read to “720×1280”, and… well of course, what did you expect?
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.
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.
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.
Just design for the default and then people will zoom or change resolution if the default isn’t enough.
@media only screen and (-webkit-min-device-pixel-ratio: 1.3),
only screen and (min-resolution: 120dpi)
{
/* High DPI code */
}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
- https://developer.mozilla.org/en-US/docs/Web/API/Window/aler... they throw away the left-hand navigation and replace it with whitespace on the right-hand side
These examples aren't particularly "rude offenders", this is just par for the course.
It's amazing how many websites are incredibly unusable when displayed 2-up on my 27" monitor.
There's so much screen estate, but I often literally have to resize the window to fullscreen to find a search or login field.
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.
1920x1080 in half.
It’s a regular problem I run in to.
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?
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".
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
The proposed solution is not just no better, but far, far worse.
Shrinking the viewport so it is toothpick shows me the phone screen view. I don't think they are selecting on aspect ratio alone.
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.
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.
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.
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.
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”.
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".
It’s honestly been a significant improvement over dedicated mobile layouts and for the most part works pretty well.
Something as simple as “use-case: handheld | bellyheld | desktop” property? Css designers missed this opportunity completely.
I used to insist that designers never say "phone, tablet, desktop" and instead say "small, medium and large" but it never stuck.
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?
That's what the user-agent is[0]. And all major browser engines have/had a Mobile token on relevant devices.
[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_de...
[0] https://www.zdnet.com/article/google-to-phase-out-user-agent...
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".
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.
Then it turns out the solution isn't CSS it's the HTML "meta" tag:
<meta name="viewport" content="width=device-width, initial-scale=1.0">
@media (max-width: 35rem)
If you were mobile-first, you'd use min-width media queries rather than max-width.
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.
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'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.
Maybe it's their font-scaling settings are getting in the way and changing the viewport resolution?
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.
- 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.
- 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".
Is there a good npm lib that does the above?
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.
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.
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.
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.
The width of the window is probably dropping below a breakpoint when he reorients the screen.
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.
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 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.
https://support.mozilla.org/en-US/kb/font-size-and-zoom-incr...
That keeps the layout/images/etc the same, while bumping the font px/em.
@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.
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.
There is effectively zero benefit of optimizing for this use case.
Come on UX designers out there, don't be lazy and remember to always include the max-width/min-width attributes in your @media queries :)
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.
1: https://www.pcworld.com/article/2690724/why-windows-10-isnt-...
So it seems like we've broken desktop accessibility in favour to the mobile one.
1in = 25.4mm = 72pt = 96px
Seems there is failproof solution missing there for recognizing tablet, desktop and mobile.
Btw. many websites break also on quadratic screens ;)
var dppx = window.devicePixelRatio;
var screenWidth = screen.width * dppx;
var screenHeight = screen.height * dppx;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.
Some people try to implement fancy heuristics that fails for some users but not enough to care to fix.
"Just because I am dressed this way... does NOT make me a WHORE"
We used to do this before responsive design took over.
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.
For example, "What every programmer should know about memory" covers memory but what about (as you say) screens.
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).
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.
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 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.