3 ms·

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 th

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 phones, including iOS and Android operating systems going back at least a decade, will automatically scale your site for mobile without viewport. You customize the mobile version of your .css file for just mobile. And it's very easy these days to cross check to make sure the look and compatibility is correct (for Chrome and Safari mobile in particular). You present different site UI/UX based on the "mobile" detection; if mobile, present mobile layout, else present desktop layout. Google will punish you (SEO) slightly for the lack of a viewport tag however. This is a far easier way to design for mobile & desktop vs trying to deal with many different viewports (which is a ridiculous, backwards problem that represents an industry failure).

temac 3y ago
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?
- adventured 3y ago
  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.
  - madeofpalk 3y ago
    "works so well" is debatable. Is iPad "mobile" (honestly, I'm not sure). What if I'm on desktop and I make my screen just a bit smaller? Can I now not use the website because it doesn't bother adapting to the changing width. If this is how you want to build websites, discarding users, go ahead. But it's irresponsible to recommend this as advice to others.
madeofpalk 3y ago
Cannot tell if this is sarcasm or not...
- adventured 3y ago
  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.
depressedpanda 3y ago
For any aspiring frontend devs that might not know better: they're talking about user agent string parsing. Please don't do this. There's a reason it's an unpopular approach.

temac 3y ago

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?

adventured 3y ago
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.
- madeofpalk 3y ago
  "works so well" is debatable. Is iPad "mobile" (honestly, I'm not sure). What if I'm on desktop and I make my screen just a bit smaller? Can I now not use the website because it doesn't bother adapting to the changing width. If this is how you want to build websites, discarding users, go ahead. But it's irresponsible to recommend this as advice to others.

madeofpalk 3y ago

Cannot tell if this is sarcasm or not...

adventured 3y ago
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.

depressedpanda 3y ago

For any aspiring frontend devs that might not know better: they're talking about user agent string parsing. Please don't do this. There's a reason it's an unpopular approach.