3 ms·

> Below are the essential elements for any web document (websites/apps) > "...width=device-width, initial-scale=1..." This is a surprising bit of opinionation

> Below are the essential elements for any web document (websites/apps) > "...width=device-width, initial-scale=1..." This is a surprising bit of opinionation to an otherwise decent presentation of head elements. Websites render quite nicely on modern phones without this line, but they generally render as if they are on a desktop browser. Using the above meta tag allows you easy access to modern approaches to mobile development.

akersten 7y ago
I'm not an expert. But in my experience, that line has been the solution to 100% of any viewport issue I've ever had on mobile, and has made webpages "just work" and render how I'd expect them to on mobile, as opposed to weird issues with font size and scrolling. I've never had that line do something I didn't want. Is there a reason mobile browsers don't automatically just do whatever that line does? Seems like the opt-in behavior should be "yes, render me like I'm a desktop site on a tiny monitor" rather than opt-out.
- Brendinooo 7y ago
  Legacy reasons. When the iPhone came out, "mobile only" sites were a wasteland of terrible UI and restricted features. iPhone OS wanted to serve full websites, and sometimes had to do weird things to beat the kind of stuff that sniffed for mobile devices, or to overcome the lack of a mouse on a desktop website. If you look at the original iPhone demo in 2007[0], the original intent was to render full web pages on the screen and rely on the double-tap-to-zoom to read content. The article that's generally credited with naming and mainstreaming Responsive Web Design[1] didn't come until 2010. [0]: https://youtu.be/vN4U5FqrOdQ?t=2502 https://youtu.be/vN4U5FqrOdQ?t=2502 [1]: https://alistapart.com/article/responsive-web-design/ https://alistapart.com/article/responsive-web-design/
  - maccard 7y ago
    Completely off topic, but it's hilarious how slow the NY times website loads in that first video.
userbinator 7y ago
allows you easy access to modern approaches to mobile development. What exactly does that mean? It reads almost like marketing copy for a new framework.
- gdwatson 7y ago
  It makes mobile web browsers be honest about the size and resolution[1] of their screens; without it, they lie and claim to have desktop-sized viewports. Once the browser is being honest about its screen, you can use CSS media queries and the like to do responsive web design, giving mobile devices content that fits them and is touch-friendly. If the browser is claiming a desktop-sized viewport, your options are to either serve a desktop layout or to do User-Agent sniffing and the like. [1] All high-res devices today maintain a distinction between a CSS pixel (approximately 1/96 in.) and a device pixel, and they give their resolution in CSS pixels. This is dishonest from the point of view of 1995, but it’s convenient and it’s what web designers expect today.
adventured 7y ago
> but they generally render as if they are on a desktop browser If you wanted to avoid using that for some reason, there is a very effective (~99% coverage) way to do it and make your site render perfectly on mobile. In your application, simply check the user agent for "mobile" and insert whatever resources you prefer to adjust for mobile (perhaps an entirely different design for example, as is sometimes appropriate) and failing that switch to desktop view resources. For common caching (you don't want to cache one universal copy of a page for desktop and serve that to mobile), if you're using Nginx as a web server and for caching, map a mobile value based on the detection of the keyword "mobile" in the user agent, something like: Map $http_user_agent $mobilekey {"~*Mobile" mobile; default desktop;} Staple that $mobilekey value to the proxy_cache_key to generate two cache versions, one for mobile, one for desktop. For most sites this is a low burden expense. The map approach also avoids the various pitfalls of attempting to use IFs in Nginx, so it's extremely performant. This approach has obvious downside risk, such as if the popular browsers decide to drop the mobile keyword from their user agent strings (there are other simple ways to target the user agent that would solve that change however). The industry overwhelmingly disagrees with targeting the user agent like this, however it works perfectly well and has for a long time.

akersten 7y ago

I'm not an expert. But in my experience, that line has been the solution to 100% of any viewport issue I've ever had on mobile, and has made webpages "just work" and render how I'd expect them to on mobile, as opposed to weird issues with font size and scrolling. I've never had that line do something I didn't want. Is there a reason mobile browsers don't automatically just do whatever that line does? Seems like the opt-in behavior should be "yes, render me like I'm a desktop site on a tiny monitor" rather than opt-out.

Brendinooo 7y ago
Legacy reasons. When the iPhone came out, "mobile only" sites were a wasteland of terrible UI and restricted features. iPhone OS wanted to serve full websites, and sometimes had to do weird things to beat the kind of stuff that sniffed for mobile devices, or to overcome the lack of a mouse on a desktop website. If you look at the original iPhone demo in 2007[0], the original intent was to render full web pages on the screen and rely on the double-tap-to-zoom to read content. The article that's generally credited with naming and mainstreaming Responsive Web Design[1] didn't come until 2010. [0]: https://youtu.be/vN4U5FqrOdQ?t=2502 https://youtu.be/vN4U5FqrOdQ?t=2502 [1]: https://alistapart.com/article/responsive-web-design/ https://alistapart.com/article/responsive-web-design/
- maccard 7y ago
  Completely off topic, but it's hilarious how slow the NY times website loads in that first video.

userbinator 7y ago

allows you easy access to modern approaches to mobile development. What exactly does that mean? It reads almost like marketing copy for a new framework.

gdwatson 7y ago
It makes mobile web browsers be honest about the size and resolution[1] of their screens; without it, they lie and claim to have desktop-sized viewports. Once the browser is being honest about its screen, you can use CSS media queries and the like to do responsive web design, giving mobile devices content that fits them and is touch-friendly. If the browser is claiming a desktop-sized viewport, your options are to either serve a desktop layout or to do User-Agent sniffing and the like. [1] All high-res devices today maintain a distinction between a CSS pixel (approximately 1/96 in.) and a device pixel, and they give their resolution in CSS pixels. This is dishonest from the point of view of 1995, but it’s convenient and it’s what web designers expect today.

adventured 7y ago

> but they generally render as if they are on a desktop browser If you wanted to avoid using that for some reason, there is a very effective (~99% coverage) way to do it and make your site render perfectly on mobile. In your application, simply check the user agent for "mobile" and insert whatever resources you prefer to adjust for mobile (perhaps an entirely different design for example, as is sometimes appropriate) and failing that switch to desktop view resources. For common caching (you don't want to cache one universal copy of a page for desktop and serve that to mobile), if you're using Nginx as a web server and for caching, map a mobile value based on the detection of the keyword "mobile" in the user agent, something like: Map $http_user_agent $mobilekey {"~*Mobile" mobile; default desktop;} Staple that $mobilekey value to the proxy_cache_key to generate two cache versions, one for mobile, one for desktop. For most sites this is a low burden expense. The map approach also avoids the various pitfalls of attempting to use IFs in Nginx, so it's extremely performant. This approach has obvious downside risk, such as if the popular browsers decide to drop the mobile keyword from their user agent strings (there are other simple ways to target the user agent that would solve that change however). The industry overwhelmingly disagrees with targeting the user agent like this, however it works perfectly well and has for a long time.