Hacker News Reader

Comment by jefftk | Hacker News Reader

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.

View on HN

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

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.

¯\_(ツ)_/¯

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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.

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”

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?

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?

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.

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.

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

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)

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

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.

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

I love that Chrome on Android lets me zoom into any content on any site, regardless of how bad the devs borked the UX. (Yes, devs, if you don't allow me to zoom using the browser's built-in capabilities, you have borked the UX, and should be ashamed of yourselves.)

If you have a windows 10 laptop, pinching on the touchpad seems to give you the same zoom functionality now. vastly superior than the one built into the browser

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.

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.

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

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

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

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

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

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

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

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.

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.

Reply on news.ycombinator.com