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...
What's wrong with using something like: @media (min-width: 8in)
To determine if someone is using a larger screen (or window)?
Edit:
https://hacks.mozilla.org/2013/09/css-length-explained/
Seems like 8in is just short-hand for 8*96px. Thanks for nothing, web standards.
I understand they had to start with something and 20 years ago no one expected thre will ever be monitors with DPI > 96 but I don't understand why the situation hasn't changed yet. Now that we have many physical screen sizes with vastly varying densities.
In my opinion, devices with a screen are like a sheet of paper. Imagine a tablet or Remarkable eink. You can print only that small font on such paper. If the font is too small, we can use a magnifying glass or, in case of electronic devices, clever scaling mode.
If that was implemented, buying a bigger monitor would actually mean we could fit more content, wider newspaper there.
The current situation is just a mess with designers just randomly guessing how it's gonna look on most current devices and using media queries to somehow automagically solve it all. But it is not uncommon to see a website on a huge hi-DPI monitor in such a way that a heading takes 1/4 of the screen height and there are empty unused paddings everywhere. I.e. if you buy a bigger monitor, everything just gets bigger, including most of fonts, unnecesarily. Sometimes all you get is three columns of text instead of one. Sometimes. If media queries are set up reasonably well. But even then, on high-resolution screens there is sometimes big empty space on the left and right side because it is just "highest-width" media query and designers didn't expect you would have so many pixels horizontally...
* 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.
> 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.
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.
¯\_(ツ)_/¯
Unfortunately, the horizontal scrolling UX with substantial wasted whitespace on the sides remains.
Someone else mentioned bootstrap in the other thread too.
Maybe because these Frameworks are hugely popular, their defaults amplify the impact. Definitely these values are tweakable.
“The small breakpoint is 768px wide? I guess below it it’s a phone, I hope you like burgers”
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.
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.
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.
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.
That said, sane breakpoints can usually avoid unexpected hamburgers on the desktop.
I learned this lesson the hard way. The client was on desktop. The users were 40% phones. Everything was great for months and months.
Then one day the owner of the company that owned the company tried to look at the web site on her grandkid's iPad. Fan met shit that day.
* Lay out content based on the viewport width, in CSS pixels.
* Use larger tap targets for coarse pointers (https://developer.mozilla.org/en-US/docs/Web/CSS/@media/poin...).
This is wrong because the viewport width is not the same as the monitor width or the DPI: especially on big monitors running the browser fullscreen is very hard to use (my browser rarely exceeds more than ~50% width on a 2560x1440 monitor and even when i use a 1366x768 monitor - which btw is at 22", not some tiny laptop one - i very rarely use it maximized).
As for why it is wrong, it is because you can't rely on it to make a Mobile vs Desktop distinction - i already provided an example why.
It's still not clear to me where you think this approach gives bad results?
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 :-/
Usage while walking/moving vs. sitting/standing at a desk.
Most "mobile" usage is actually stationary, typically seated. If you really need to change layout based on motion you can use the accelerometer, but I can't see why you would?
what would be really nice would be element-size-based media queries. you can use javascript to do it but that sucks
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.
Should the space given to sidebars increase? Should those sidebars disappear? What about headers and footers? How will the overfloat be treated? A single line, double lines? What about captions underneath images? How do you handle text that happens to be embedded within images themselves, or even on top of images?
"I don't care if headers look weird"
It goes beyond things looking weird, it really does break websites.
Given that we're increasing the text 2x or 3x, it's an important question whether or not we're also increasing the width of the scrollbar 2x or 3x.
I agree though, let me zoom on a blog post. The diagrams are often unreadable on mobile.
It doesn't help with everything, but the triple-tap zoom is quite useful.
View > Zoom > Zoom Text Only
How is a web site supposed to know if you're someone sitting in bed with the screen a few feet away, or someone sitting at a desk with a screen a few inches away?
That's on the user. Learn how to use your browser, device, and operating system's zoom features.
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.
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.
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?
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/...
They're only working correctly if you ignore the intent and only look at the technical implementation. The technical implementation is flawed and doesn't accomplish the intent.
The stupidest thing to do at that stage would be to say "ah I see you're running a low resolution on a huge screen, let me make all the text tiny".
As I read this I:
1. am wearing my computer reading glasses +1.5
2. have my browser set to zoom HN by 125%
3. am reading distance from the screen
I know programming and tech in general is a young man's game, but let's at least try not to be ignorantly ageist & ableist.
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.
> But I find the fonts slightly too small at that resolution – given how far I sit from the screen.
You conflated that with sitting too far away. There are a lot of reasons why that might not be correct, including presbyopia. I think it's unlikely OP is sitting at that distance by accident, since it's pretty easy to move a monitor closer, so one of those reasons is more likely to apply than is your assumption.
For now I stand by my assumption that OP wanted the fonts to be bigger because they were too far from the screen to read them at their current size. Though I fear I can't see why their reason for wanting fonts to be bigger would matter. I could have omitted OP's reason for wanting the fonts to be bigger but I thought a brief description would help keep the discussion related to the article.
The main thing I was advocating was that software should allow fonts to be bigger regardless of physical size, but clearly I've somehow allowed my argument to be horribly misconstrued.
Sorry, as long as the site still works it’s simply not worth it.
example: https://tv.avclub.com/the-hunt-is-on-with-clarice-the-equali...
This is untenable as well. You'll end up with microscopic websites on high DPI phone screens.
Users with NoScript will just have to live without some functionality. I'm sure they are used to that already, since a large fraction of websites use JS for styling. (I use NoScript)
Setting aside the debate about separation of concerns. Yes, it has notable performance and UX implications.
> Users with NoScript will just have to live without some functionality.
Why should we prioritize OP's use case over that of NoScript users?
@media (min-aspect-ratio: 1/1) /* wide */
@media (max-aspect-ratio: 1/1) /* tall */
@media (aspect-ratio: 1/1) /* square */
Here, play with your window width to see: https://hypertele.fi/0000000000000000
My experience has been the exact opposite of what you're saying.
And the result is, 90% of the time, a site that goes from usable to unusable.
On many sites, this trigger the appearance of the dreaded hamburger menu.
Which they shouldn't be.
Specifically, they have:
.comment {
font-size: 9pt;
}
.commhead {
font-size: 8pt;
}
In general, CSS already provides a bunch of generic font families and sizes. So a page could style something as e.g. "sans-serif" and "large" - and then the browser should figure out what this actually means according to user settings. The problem is that very few sites actually use these. But for those that do, the browsers do the right thing - and, again, most of them let you configure what the generic font families map to.
When I read that, I read, "we're ableist and here's a few crumbs so we can feel better about ourselves".
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.
Agree. I sometimes browse the web on my TV - and I sit about 2 metres (or 6 feet) away from it. So the TV screen occupies a similar portion of my field of view that a phone would, and I usually browse at 150-200% zoom.
DPI might help you figure out the size of the screen, but it doesn't tell you how much of a person's field of view that screen occupies, which is what really matters.
"CSS pixels" are kind of a roundabout way to conceptualize it, but they solve the problem of proper readability once the OS scale is correct for the user. The combination acts as a proxy for field of view.
Then there's detection of course/fine pointing devices, as already discussed, to further augment the layout for proper target area.
I don't believe anything else will matter if the above is accounted for.
@media and (pointer: fine) {
your computer specific CSS rules goes here
}
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.