Hacker News new | past | comments | ask | show | jobs | submit login
Just because I have a vertical screen doesn’t mean I’m on a phone (shkspr.mobi)
547 points by edent 72 days ago | hide | past | favorite | 386 comments



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.


Am I missing something or do CSS media queries not solve this problem by providing an actual physical measurement?

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.


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...

[1] https://github.com/w3c/csswg-drafts/issues/614


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 like the idea of using relative units for media queries but it interferes with people being able to zoom and get the desired outcome.


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.


iphoneX looks like it has a css px width of 812px. They may also be trying to capture tablets, which are pushing above 1024 css px.


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.


It could be worse. One particular web app I use daily has horizontal scroll bars even when full screen (and has some off the main info at far right).


This is the unmitigated disaster that is the Azure dashboard isn’t it?


Name and shame. That's the only way it gets better.


Sounds like the Azure Dashboard, but I haven’t used it in years


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.


Users of CSS frameworks do it to cut corners and follow whatever the framework suggests.

“The small breakpoint is 768px wide? I guess below it it’s a phone, I hope you like burgers”


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


You’re getting better. :)


> sites/apps

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.


IMNSHO, more or less the case since they stopped using tables for layout.


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.


Agreed, Tablet is the only intermediate I consider. The rest is just not worth the time investment.


What tablet? Aren't we talking pretty much anything between about ~500px and ~1200px here? That's pretty much tablet zone...


You caught me, for me that means col-md with Bootstrap ;-)


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.


If desktop + mobile make up >95% of your audience it's hard to justify the cost of creating a third set of rules for the rest.


That makes sense on the surface, but you should design for all possibilities, current and future.

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.


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.


The tooling isn't the problem, time is. Every device and resolution you support takes time and at some point you hit a point of diminishing returns.


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.


For some reason people adopted 1040px-1080px as a default - I think it’s twitter Bootstrap’s fault. 980 or even less is much more reasonable.


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.


Mobile vs Desktop is not a clean division: screens run the full range of widths. Instead, developers should:

* 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...).


I had no idea that detecting coarse pointers was a thing, thanks for calling that out!


> 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 viewport width is the browser width, not the screen width. What are you saying is wrong with using the viewport width?


Uh, i wrote "viewport width is not the same as the monitor width", this is the same as what you wrote.

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.


"Mobile vs desktop" is not a distinction websites should be making. Sites should make the best use they can of the available horizontal space.

It's still not clear to me where you think this approach gives bad results?


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.


Ergonomics of using touch screen vs. mouse.

Usage while walking/moving vs. sitting/standing at a desk.


For touch screen vs mouse, use "pointer:coarse": https://developer.mozilla.org/en-US/docs/Web/CSS/@media/poin...

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.


One of the original selling points of the iPod touch/iPhone was that it could display full desktop websites...


Fair, although back at the time they came out it meant something different. Mobile-optimized websites in 2008 were horrible, stripped-down things.


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)


No, not at all in the sense as it was in 2008.


It can. As can Chrome on Android. Just request the "Desktop site" version. It's pretty unusable though, which is why we have responsive websites :-)


> 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.


God forbid we use the scroll bar.


Nobody's suggesting we not use it, and honestly I don't even know what this needlessly rude comment means in the context of the larger discussion.

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.


Horizontal scrolling perform disastrously badly in UX testing.


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.)


Unless its, say, a mapping web app. In which case, pinch-zoom adjusts the canvas map zoom, allowing regular zoom would actually break the UX.

I agree though, let me zoom on a blog post. The diagrams are often unreadable on mobile.


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?


Just confirmed it works on Firefox and Safari. Though I seem to recall seeing some sites which break that functionality with CSS.


FYI desktop Firefox has "Zoom Text Only" feature.

    View > Zoom > Zoom Text Only
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 like how it's now a "feature". This is what zoom originally did, and "full zoom" was the feature.


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?


Until 2020, it was probably uncommon. Not so sure now.


A laptop or phone 'casting' to a wide screen TV.


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.


It's still an option in Firefox. In the general preferences, a checkbox titled "Zoom text only".


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.

https://twitter.com/varjag/status/1050370136585187328/photo/...


Yeah, Distrelec .. I saw this too.


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".


> they're deliberately presenting their screen as 720x1080 to make the fonts bigger because they are too far from the screen.

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.


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.


I have no such intention, I was merely rephrasing what they said:

> But I find the fonts slightly too small at that resolution – given how far I sit from the screen.


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.

example: https://tv.avclub.com/the-hunt-is-on-with-clarice-the-equali...


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.


> The author's proposed solution is for sites to use DPI instead

This is untenable as well. You'll end up with microscopic websites on high DPI phone screens.


This should result in the website knowing that the screen is 7" inches (dots-per-inch / dots = inches) across and setting the style for small devices.


This requires the use of JavaScript to style a website.


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)


> Is that really an issue?

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?


What I use is @media (pointer: coarse) and (hover: none) { If you have a mouse plugged in, you get the desktop design.


I don't differentiate by type of device. I just detect aspect ratio:

@media (min-aspect-ratio: 1/1) /* wide */

@media (max-aspect-ratio: 1/1) /* tall */

@media (aspect-ratio: 1/1) /* square */


And what do you think the aspect ratio tells you? People do use portrait orientation for monitors or windowed mode for browsers.


It tells me which axis is longer, so I can responsively move the menu there. Also I flow content differently - lists get columns if wide enough.

Here, play with your window width to see: https://hypertele.fi/0000000000000000


>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.

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.


What viewport width are you providing in that case?


I typically go from width=1920 x height=1080 (or larger but with similar aspect ratio) to width=949 x height=1028

On many sites, this trigger the appearance of the dreaded hamburger menu.


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.


> Many of these sites are statically laid out

Which they shouldn't be.


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.


I can't use HackerNews on my monitor without scaling. If I press Ctrl+0 on Chrome, the site becomes unusable.


HN has chosen to use very small fonts; I also leave it a bit zoomed in.

Specifically, they have:

    .comment {
      font-size: 9pt;
    }
    .commhead {
      font-size: 8pt;
    }
If I turn off all the site's font-size overrides, I no longer need to zoom in.


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.


Both Chrome and Safari has accessibility features to set a minimum font size in their settings page. I can't see how it could be easier.


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.


So it’s not just me. I think HN is the only site I use that I’ve bothered to configure custom zoom factor for.


It's definitely not just you. And I really get sick of the people saying things like "just zoom" or "set a custom minimum font size".

When I read that, I read, "we're ableist and here's a few crumbs so we can feel better about ourselves".


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.


The example of https://www.just-eat.co.uk/ bailing out to a hamburger menu at 768px, just to deal with 5 navigation options is a bit much.


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.


Two rows?


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.


  @media and (pointer: fine) {
      your computer specific CSS rules goes here
  }
No reason to tell a tall window it is on a phone.


The auctor is also complaining about suddenly obtaining touchscreen controls, however.


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.


They don't even think that.

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.


A touch screen has @media (pointer: coarse)

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.


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.)


Because many laptop users have a touch screen.


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.


So what's your solution? How do we differentiate between a tablet user and someone who decided to shrink their windows?


Copying from elsewhere in this thread: `@media (pointer: coarse)`


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.


Safari simulates a finger press when mouse is clicked. I’m 99% sure. Will check.


People with disabilities or visual impairments often have unusual setups that enable them to read. They didn't CHOOSE to be disabled.


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.


Seems to me that proper DPI detection might lead to a better experience across all "unique" monitor setups, not just this one.

Is it extra work? Sure. I thought we referred to that as polish.


Is DPI a good measure though? Some cheap phones have rubbish DPIs while expensive monitors have very high dpi.

Not sure if this exists already but the idea method would be to use the physical size in cm of the display.


I tried dpi.lv on my 2 monitors and my phone. It said:

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.


> You've chosen to have a unique setup,

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


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.


The real real problem is that so many sites overcomplicate their design.

HN works beautifully on any window / screen size.


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.


> 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.

Except you're ignoring mobile devices.


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.


No, the say that HN does it works regardless of screen width. If the site were to assign a fixed width, it would conflict with mobile devices.


This is why CSS has "max-width".


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.


>And yet quotes don't wrap to any specific size, so you end up with an awful horizontal scroll bar.

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.


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.


> There is no way to format your text, even stuff that's available since MS Word 1.0, such as bold or italic

Are you entirely sure about that?


Ok, now do bold ;-)


You mean 𝗹𝗶𝗸𝗲 𝘁𝗵𝗶𝘀?


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?


If screen readers do that, why? That seems useless even when those characters are used for their intended purpose.


They're just reading the character name. I don't know of any screen reader that actually makes an attempt to read math reasonably.


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?


ʇxǝʇ uʍop ǝpᴉsdn sʇɹoddns uǝʌǝ NH 'uɐǝɯ I


There is no formatting support for it, it seems you can use Unicode bold formats or something. Doesn't seem approachable or trivial...


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.


There is no bold.


𝗔𝗿𝗲 𝘆𝗼𝘂 𝘀𝘂𝗿𝗲?


Stop tricking people. Yes you can use unicode for all kinds of fun stuff, but that's not formatting, it's a hack.


I’m sorry, it was not my intention to mislead anyone. Yes, it’s all trickery with copy-and-pasted Unicode bold characters.


You would have gotten away with it too, if it weren't for those meddling kids!


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.


For a site that sells rugs, good design is design that accommodates all users and sells as many rugs as possible.

So an accessible site that follows modern design fads is probably the best thing to have (if that sells rugs).


If one of the goals of design is to serve as a signal for how trustworthy your business is, then it is absolutely 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.


Amazon is a design garbage bin, but it doesn't seem to be reducing their sales.


I would definetly pick the store with the hacker newsish website!


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.


Any site allows pinch zooming if you use Firefox and toggle a setting.

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.


> you end up doing a lot of horizontal scaling to read block quotes

what block quotes?


Exactly. Most of the time, recoverable flaws are better than immutable bad design.


I generally agree. But thumbs up/down is difficult on mobile with my fat fingers, even worse since I've had nervr damage.


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.


HN is a pretty minimal site though - it is just a message board.


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.


What? I can’t count how often I accidentally downvoted a post because I can’t hit the correct arrow on mobile!


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.


But it doesn't break your ability to zoom, so you at least have the option to (quickly) fix it.


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.


It works beautifully for it's indented audience.

I think many people, my parents included, would have trouble navigating HN on a phone. Especially upvote/downvote.


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.

I consider that to be an utter failure.


There's a lot of "literature" about the shortcomings of hamburger menus and "junk drawer navigation" that come up when i google the topic.


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.

(And that's quite OK, I think.)


I don’t think this has much to do with your vertical screen as much as it’s the narrow viewport.


Absolutely. When I read the headline, I frowned, because I’d call it quite rare for sites to mishandle my 1080×1920 displays, though not unknown.

But then I read to “720×1280”, and… well of course, what did you expect?


Exactly. CSS does not check that your screen is taller than it is wide. What it sees is a narrow viewport.


The CSS could very well be checking that

// 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)



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.


No, it's not.


I'd be interested in hearing other use cases.


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.


Oh, sorry, I was reading an article about the new CSS aspect-ratio property and mixed it up with the CSS aspect-ratio media query.


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

- 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.


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.


What about the min-resolution media query?

  @media only screen and (-webkit-min-device-pixel-ratio: 1.3),
 only screen and (min-resolution: 120dpi)
 {
  /* High DPI code */
 }


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.


Just because my horizontal resolution is around 1200, I am not on a tablet.

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.


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)!


This is the worst when you're displaying two sites side by side on a 1080p screen.


This drives me up the wall. You would think it's such a common scenario!


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.


It's one of the reasons I have a vertical monitor. 1080 horizontal doesn't seem to trip it.


At what horizontal resolution?


960x980.

1920x1080 in half.

It’s a regular problem I run in to.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: