Fun fact: there's no way to do logical grouping for head elements. (eg no divs allowed)
Why would this be useful? Other than for human legibility, but I feel like that can be accomplished with line breaks and comments.
HEAD – A guide to elements
81–90 of 129 posts
Re: HEAD – A guide to <head> elements
#82Earlier quoted context omitted.
> maximum-scale is an automatic usability and accessibility fail I wish more people realized this. As somebody that's visually impaired, it makes mobile browsing quite painful for me.
Just FYI in case you didn't know, both Firefox and Chrome on mobile allow you to force zoom even if there's a viewport restriction. Check accessibly settings.
And Safari has completely ignored user-scalable, minimum-scale, and maximum-scale since iOS 10
https://webkit.org/blog/7367/new-interaction-behaviors-in-io...
Re: HEAD – A guide to <head> elements
#83> Completely opt out of DNS prefetching by setting to "off" Why is this included in these guidelines? EDIT: See reply. Thanks!
That's not a recommendation, the site is just documenting it.
Re: HEAD – A guide to <head> elements
#84Please no. IMO this makes most pages unusable on mobile. Most websites, e.g. news websites with long-form articles, shouldn't be using mobile pages / responsive design / zoomed-in layout at all. Web apps (Twitter, GMail), maybe. But most mobile pages are far more unusable than desktop versions (looking at you, Facebook and Reddit).
> news websites with long-form articles, shouldn't be using mobile pages / responsive design / zoomed-in layout at all
Do you mean you actually prefer having to scroll left/right/left/right/left/right when reading a long article?
Re: HEAD – A guide to <head> elements
#85Earlier quoted context omitted.
> maximum-scale is an automatic usability and accessibility fail I wish more people realized this. As somebody that's visually impaired, it makes mobile browsing quite painful for me.
just out of curiousity, how do you deal with this problem in native apps where pinch zoom is disabled?
You can change the OS text size and apps will respond to it.
Re: HEAD – A guide to <head> elements
#86Would love to see if/how these apply to html email/email-clients.
Re: HEAD – A guide to <head> elements
#87wat.. ok
Re: HEAD – A guide to <head> elements
#88Earlier quoted context omitted.
With iOS you don't need to do this. You can enable zooming as a system-wide feature. You can even zoom parts of the screen, like a magnifying glass. You can find all of these settings under Settings -> Accessibility -> Zoom.
android has the same thing. you can activate an accessibility setting and then a triple tap will zoom in everything system-wide
Unfortunately the UX of that feature isn't great, so it's only useful in some cases. Often I find the screenshot method easier/faster.
Re: HEAD – A guide to <head> elements
#89> Is Dreamweaver still a thing? I haven't heard of it in years, many years.
Absolutely.
AFAIK it's the best non-code way to create sites without being tied to a hosting platform or messing with Wordpress plugins.
Re: HEAD – A guide to <head> elements
#90> 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…
> 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.