Live data from Hacker News

The ideal viewport doesn't exist

viewports.fyi

101–110 of 202 posts

Re: The ideal viewport doesn't exist

#101

I was hoping to read some kind of solution at the end of all this huge text. Some radical way to do layouts without using viewports. Instead I got a link to buy a book from some author. Why is this even here? This is a long ad with useless data points.

There's a way to do it entirely without viewports, although it's extremely unpopular with designers. Present a .css file for mobile or for desktop, based on the presence of "mobile" in the agent string. Chrome continues to report that agent data and it's very accurate for this use case (where your primary aim is to detect mobile equivalent, else present for desktop). You can drop the viewport html tag. All major phon…

Cannot tell if this is sarcasm or not...

Re: The ideal viewport doesn't exist

#102

I'm not, and never was, a "front-end guy". I've noticed more and more quirks (bugs?) in UIs where something is off screen, or unclickable, or suffers extremely unhelpful placement that prevents or significantly impedes my use of a web site/app. Rotate phone/tablet, change font size, hide URL bar, mental note to try it on a desktop or laptop "later". This feels like the front-end version of "it works in dev".

If you’ve worked in front-end dev for a while you can be aware of all the issues. The problem, generally, is that frontend dev is taught poorly if it’s taught at all, and the barrier to entry is so low that there’s an Eternal September problem.

I'd think that eventually we'd have a large enough cohort of folks that know web dev well since the barrier is so low, but I think most people try to get out of frontend development asap.

Re: The ideal viewport doesn't exist

#103
post #2

> It’s safest to presume that users on desktop or laptop devices are not filling their entire screen with a browser. Not on literally any laptop I've ever seen. I've never seen a screen where the browser _isn't_ filling all space available to them, sometimes even the entire screen (in fullscreen mode on MacOS).

I presume you're talking about maximized windows, but that still does not equal "filling the entire screen", because browsers have their own user interface around the viewport. Go maximize your browser and enter this into your dev tools: console.log(`${window.innerWidth}x${window.innerHeight}`) Does that equal your screen resolution?

I like this because opening the dev tools has a high chance of changing innerHeight :)

Re: The ideal viewport doesn't exist

#105
post #97

Earlier quoted context omitted.

There's a way to do it entirely without viewports, although it's extremely unpopular with designers. Present a .css file for mobile or for desktop, based on the presence of "mobile" in the agent string. Chrome continues to report that agent data and it's very accurate for this use case (where your primary aim is to detect mobile equivalent, else present for desktop). You can drop the viewport html tag. All major phon…

I'm not even sure what mobile means in this context. What happens when you plug your phone on a screen? What happens when you use a tablet?

That's very straightforward. Obviously the user agent is reported by the browser/device as mobile or not (it either includes that keyword or not). In nearly all cases mobile means smartphone or tablet, whether Android or iOS, Chrome or Safari. iPad commonly includes the mobile keyword in its user agent string, unless desktop is enabled by default and then they'll just get the desktop version (you could trivially detect for the iPad keyword and force mobile; given the userbase size of iPad it would probably be worth it, it'd take seconds to do). This approach covers such a comprehensive percentage of users that it's only going to be an issue if you absolutely need to cover every single possible variation, and then you have to do it another way to go from 99% to 100%.

Your desktop browser doesn't include the keyword "mobile" in the agent string. Your Safari browser on iOS does, ditto for Chrome on Android.

So here's the iPhone 13 Max user agent string:

"Mozilla/5.0 (iPhone14,3; U; CPU iPhone OS 15_0 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0 Mobile/19A346 Safari/602.1"

The "mobile" keyword gets you what you want.

Here's iPhone 8:

"Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.34 (KHTML, like Gecko) Version/11.0 Mobile/15A5341f Safari/604.1"

The "mobile" keyword gets you what you want.

ChromeOS desktop (Chrome browser), Mac desktop (Safari), Windows desktop (eg Chrome or Firefox). They don't include the "mobile" keyword.

It's not flawless, getting to 100% requires a lot more effort. This approach is far beyond good enough however, particularly for an average site. If you're building a giant enterprise app and want to appeal to every possible user and you have a team, maybe you'll throw a lot more resources at getting the small number of problematic edge cases.

And if you're using Nginx, which I commonly do, you can map the agent key in your http segment, eg:

map $http_user_agent $mobilekey {"~*Mobile" mobile; default desktop;} (or vise versa)

and then you can utilize that for caching related tasks (attach it to your proxy_cache_key to differentiate a mobile vs desktop cache).

And as I've noted, this is widely despised by the HN crowd despite the fact that it works so well and so easily.

Re: The ideal viewport doesn't exist

#106

Responsive sites have to be like elastic 'jelly' and accommodate every view-port resolution. The only exception being non-mobile-friendly web apps, in which case some sort of manifest should be read by the browser and presented to the user clearly stating mobile isn't supported and they should use a desktop browser instead. Then there's the progressive web app (PWA) debacle, where users don't even know what a PWA is…

Our product is the exception here (desktop only web app).

We basically just account for 800-1300px width range and call it a day. On the low-side, we show a "desktop only" overlay. On the high side, we block the content from expanding.

Re: The ideal viewport doesn't exist

#107

Earlier quoted context omitted.

There's a way to do it entirely without viewports, although it's extremely unpopular with designers. Present a .css file for mobile or for desktop, based on the presence of "mobile" in the agent string. Chrome continues to report that agent data and it's very accurate for this use case (where your primary aim is to detect mobile equivalent, else present for desktop). You can drop the viewport html tag. All major phon…

Cannot tell if this is sarcasm or not...

Nope, it works very well. I have been testing it routinely for a decade now.

The core to it is simply getting the "mobile" keyword out of the user agent string. That takes care of nearly everything, from there all you have to do is a simple css split for either desktop or mobile.

It very effectively covers all the major browsers, all the major platforms, going back at least a decade.

Re: The ideal viewport doesn't exist

#108

> "The main point we’re trying to get across is that you simply do not know how users are going to visit your website or web app. Instead of making design decisions on strict, limited breakpoints, keep in mind the sheer amount of fragmentation there is in viewports." I don't know how useful this is. setting breakpoints allows some sanity in the build and testing process otherwise you have an infinite scope for issues…

There's one thing I absolutely will disable and that is the MFing pull to refresh. I hate that feature more than pretty much anything else about the Internet.

Users can't, for some hideous reasons that should be illegal due to accessibility concerns, disable it, and it is an excellent way to accidentally throw away your work several times a month if you don't have very steady hands, depending on if the back button decides to not restore.

Re: The ideal viewport doesn't exist

#110
post #5

I wish more pages took the pointer and resolution media queries into account. So many times I open windows side-by-side on my desktop and end up with the menu collapsing into a hamburger menu which fills the entire screen when clicked. Many phones today have very high DPI and very low precision in touch, so it makes sense to have massive visual elements and buttons, but my desktop with the same size in pixels as my p…

This. Unfortunately today, the desktop is an afterthought and everything is designed for “mobile first”. I even see this in SaaS apps that should actually never be used on a phone. Or desktop OSes like windows and mac are increasingly using mobile paradigms on the desktop. There is so much whitespace, huge fonts, huge buttons, hamburger popup menu everywhere (aaaargh!!) Basically it boils down to the “information den…

It sounds like you are talking about gmail web at md2 era. The giant sidebar item that can only literally show 6 item on a 1080 screen. The giant mail row that display only 10 or maybe 15 mail on whole screen. And new mail button on right bottom that requires you move your mouse across the whole screen to write a new mail.

It really makes me wonder 'wtf? Who designed that, did he actually try to use it by himself?'.

At least it seems they steps back a bit now. Also they moved the new mail button back to top left.

Post reply on HN