HEAD – A guide to <head> elements | Hacker News Reader

HEAD – A guide to <head> elements

htmlhead.dev

497 pointsmooreds124 comments

DublinCore[1] is totally missing! It once was the metadata standard, it's understood by archives and libraries (including Library of Congress) worldwide, macOS will automatically import them into spotlight, etc.

Instead we find many of those tags (title, description, author, etc.) hidden behind the namespace of some corporations.

[1] https://www.dublincore.org/specifications/

Are these corporate 'namespaces' themselves even a standard? Isn't the prefix in meta@name just an informal convention?

> The above 2 meta tags must come first in the <head> to consistently ensure proper document rendering.

It looks like they don't follow their own advice:

  <head>
    <meta charset="utf-8">
    <meta http-equiv="x-ua-compatible" content="ie=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0">

Do what they say, not what they do!

maximum-scale has only three valid uses:

1. extreme values, like 5.0, if a browser misdetects that zooming that far is useful when it isn't (rare)

2. pure-app websites like maps or video games that have alternative scaling arrangements and browser pinch-zoom gets in the way.

3. there is no number three, and the thing you are thinking of is incorrect.

maximum-scale is an automatic usability and accessibility fail otherwise, you are bad and should be made to feel bad if you use it.

I tried to order a house online last night and I got to the "enter your email address to get your free quote" and because I couldn't zoom out, I could not see the Submit button.

OMG, I thought how much money is this company losing because their website intentionally disables a built in feature!?

It didn’t happen to be this site? https://www.dwellito.com/modular-homes/cover (example home)

Only asking because it’s a friend’s site and I helped him build the quote modal which you currently can’t zoom.

order a _house_?

I guess they won't know what business they're losing 'cos they won't know people are leaving the site because of that specific issue.

If they're on the ball, their tracking might be good enough that they can see people leaving on that step and try to zoom in on that problem area.

If they're really good, they might spot they get no sales from users with a certain resolution and try it out for themselves.

I feel like this is a bit of a humblebrag, but you can order houses online?

Who buys a whole house on the internet...?

Very odd.

house salad?

> 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...

Had no idea, thank you!

just out of curiousity, how do you deal with this problem in native apps where pinch zoom is disabled?

You can't, and it sucks. That's why the web is better, or at least why it's supposed to be better.

You can change the OS text size and apps will respond to it.

Taking screenshots and zooming in on those... a very tedious process.

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.

Is there a way to change this in JS? I'd love to, say, make sure that the zoom doesn't automatically change because I have an input element that's slightly thinner than the viewport and Apple thinks this is what people want, but still let people pinch to zoom.

Not a JS solution but if memory serves, setting the font size of in an input to 16px or greater prevents the mobile auto-zoom. At least on iOS.

If you limit it to 1.0 by default across the board, in particular, you mean, right?

This is the thing that limit the zoom-out with a pinch in safari/scroll beyond the page and see the "surface" underneath I'm assuming correctly hopefully

There's no reason to ever defeat the pinch-in behavior, it's what lets the user know the page is fully zoomed out.

maximum-scale=1.0 causes the page to be unscalable on mobile and is almost never what you want.

For a website that does follow this advice, see motherfuckingwebsite.com[0]

[0]http://motherfuckingwebsite.com/

Isn't x-ua-compatible not needed or not respected anymore? I think this for some reason... maybe I read it somewhere or concluded so; can't recall, lol.

We need more single page references like this, IMO, for all sorts of random domains. Even something like a single-page reference for how Array.from works in JS, as an example. Even if it were standalone it could later be integrated into a broader reference work. In the meantime, a "arrayfrom.dev" page, although non-general, would fill a specific niche w/ a mnemonic URL (Array.from is just an example - no idea whether or not it would be considerable in this regard).

Other "pages" (as rough-sketch descriptions) I can imagine: colors.dev, cacheperf.dev, unicode.dev, rdf/microdata.dev, parsing.algorithms.dev, querystring.dev (a micro reference for sure).

Likewise, "micro" web tools which I'm sure exist as a concept I don't know already would be very convenient (xml->json converter, linters/viewers/auditors of all sorts).

Is mdn not satisfactory for that? searching 'mdn array.from' brings up a nice one-pager on that and it works for almost any web/js documentation.

Sarcasm detector broken?

maybe? I like htmlhead.dev and it actually is a fairly underdocumented corner

Not sarcastic

> 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.

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.

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

[1]: https://alistapart.com/article/responsive-web-design/

Completely off topic, but it's hilarious how slow the NY times website loads in that first video.

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.

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.

> 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.

  <meta name="viewport" content="width=device-width, initial-scale=1">

Please 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).

We must have different devices. IMO most pages are unusable on mobile without this. I wonder if it's the device, website content, or personal preference at play here.

> 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?

No, Safari on iOS auto-formats text columns to be screen width when you zoom in (double-tap) on them... but the rest of the website is intact!

If I double-tap a column of text, it will zoom in on the part of the page to fit the width of the column on the screen, but if the column is too wide (e.g. a page with just a single 100% width column of text) the text size is still unreadably small. It won't reflow the column to fit the screen. (e.g. try visiting http://www.catb.org/~esr/jargon/html/I/ICBM-address.html, a page with no viewport directive and not even any page width CSS)

The early Android browser used to actually reflow columns to fit on the mobile screen when you zoomed in, but it lost that in the transition to Chrome.

That page is fine on my fairly old android phone while using brave. It might even be a bit jarring because the text is a bit too big.

That shows OK on iOS (6 lines of text, vs 2.5 lines on desktop Safari), without even having to double-tap.

You must have much better eyes than me (or a bigger iPhone) - at 6 lines the font size is half the size of the text on Hacker News, which is already pushing it for readability, and a third of the default font size for Safari's own "reader mode".

The 6 lines comes from iOS Safari defaulting to emulating an approx 800 point wide display (on a 400 point wide display)

Indeed, I've 20/20 vision... Setting "Larger Text" in Accessibility Settings unfortunately doesn't increase the rendered text size on that website (it should) but it also doesn't increase it on Twitter's fully mobile website.

It seems to work well for motherfuckingwebsite.com (their <head> is almost exactly the "recommended minimum" here).

But, I also have no problem with Facebook's mobile site, so maybe I just don't see the same problems as you are seeing.

I agree with this. I often prefer desktop pages because they have more functionality. Even Google's search gives you better search settings in desktop mode compared to mobile (you can't set arbitrary search dates on mobile, you can on desktop, oh and mobile search forces the horror of AMP on you). I also loathe the mobile version of reddit, even more than the new UI.

The only pages I prefer in mobile view are ones that get rid of their backgrounds and useless white space on the sides. I use HN in mobile view, but the difference is small enough that it doesn't matter.

Even the htmlhead.dev site that is linked works better in desktop mode, because it doesn't force you to scroll the code tags.

>  <meta name="generator" content="program">

Is Dreamweaver still a thing? I haven't heard of it in years, many years.

I last touched it in 2012 - but apparently, yes, yes it is:

https://helpx.adobe.com/dreamweaver/using/whats-new.html

Although, it looks like their cumulative 2019 updates are limited to the following headlines between the two:

1) added support for HTML tag highlighting inside PHP code

2) bootstrap CSS support.

... I was surprised to see it was still alive.

I use Dreamweaver all the time. It's actually a full-blooded static site generator, two decades before that was trendy. And marketing can use the visual editor to make it a content management system.

I still use a copy because no editor has a built in sftp anymore. Sublime/vs code/phpstorm are great for git projects but for remote projects you don't want to work on locally dreamweaver can't be beat. The only problem is modern code has changed syntax so dreamweaver gives warnings for valid code. I wonder if anyone has updated these.

VS Code has just come out with a Microsoft team SFTP plugin. It's pretty good, search even works. Seems to fix almost all the issues I tended to get using sshfs. Recommend giving it a shot.

Side note in 2012 my boss forced me to use Dreamweaver and took a lot of persuading to let us use the new (at the time) Sublime text. Good times.

Since you mention text editors, Emacs can be used to work remotely by its TRAMP remote access layer. Instead of /path/to/file, you type /ssh:user@host:/path/to/file. Since Emacs has a built-in directory browser, you can use it as if it was an SFTP client this way.

BBEdit does if you happen to be a Mac user.

PHPStorm and all the JetBrains IDEs have the ability to edit files directly via SFTP AFAIK.

It's under Tools > Deployment

Source: I use it daily.

You can deploy through sftp but you still need save the files locally. I could accept that but then you generate a laravel db migration file or config file is created through a package that was installed remotely. So your local copy doesn't have the new file. So now you have to resync the repo. Resyncing the repo from the root directory brings in the vendor packages locally so a resync could take an hour. You need to go to subfolder by subfolder resyncing if you want to avoid that.

Dreamweaver is open-edit-push back. Perfect when you have to make a change to a site and don't want all of the fiies locally.

Absolutely.

AFAIK it's the best non-code way to create sites without being tied to a hosting platform or messing with Wordpress plugins.

Why would <meta charset="utf-8"> be required if you can set it in the HTTP headers? I've also read that modern browsers (everything except IE) will look for a byte-order mark.

Quite a few of these can be set in the HTTP headers as well, but people editing templates don't always have access or know how to do it.

BTW; not all UTF-8 text has a byte-order mark, I would say most of them don't.

BOM is not valid in UTF-8 for one thing.

To be pedantic, the Unicode standard disrecommends the use of a BOM in UTF-8-encoded documents rather than declaring it invalid.

It makes zero sense to specify a byte order for an encoding in which it is irrelevant. It only persists because of a lazy vendor that can't encode Unicode correctly.

It would have been nice if every well-encoded Unicode document started with BOM and every legacy doc did not, instead of having to guess whether a doc is more likely UTF-8 or Latin-1.

Then concatenating to valid Unicode documents would no longer be valid Unicode. That is bad. And ASCII text would no longer be a valid UTF-8 encoded Unicode document. That is bad. And even when everything has finally switched to UTF-8 every tool ever will still need to handle the BOM. That is bad.

Guessing between valid UTF-8 and Latin-1 is only ever ambiguous when there are multiple non-ASCII characters in a row and all those sequences are made up of a lead byte with the correct number of trailing bytes. How often is that a problem for you in practice?

If you can't set the header, sure, put it in the head.

What I don't get is why so many say it is required in the head, even when you manage to set the header.

Probably nice for people that save the HTML document locally via curl or similar.

curl or similar could inject a meta tag.

Or we could have a default of UTF-8.

I don't dispute that it can be nice. I am just curious why so many say it is required.

I imagine it's the cumulative amount of my first example, curl, and probably other "save as html" functionality in some browsers, crawlers, s3 buckets, archival tools, and so on. I'm sure many can do as you suggested and inject the header, but suspect many don't.

Another use case might be content that is authored in a content management system. Perhaps it's the easiest way to carry your intended charset to the destination.

"Recommended Minimum" lists <meta name="viewport" content="width=device-width, initial-scale=1">. While it is indeed recommended, the site should say to actually try testing the website on a mobile device with this attribute before adding it - marking the website as mobile friendly when it's not is worse than not doing so.

This is absolutely mortifying, how much metadata do pages have to share with browsers to do that one weirdly specific thing!?

What weirdly specific thing?

You don't have to put anything in a head tag, you don't even need a head tag, but it's a good idea to have one and to at least add a charset meta tag. Everything is optional, though.

The entire point of it is for you to share metadata about your page with the browser.

My favorite weird thing that happens without certain <head> tags is the ten billion attempts to get a favicon. I don't know if browsers still try all those silly favicon requests if none is defined, but it was saddening to watch that grow to be wide spread previously.

Yes, they all still issue several favicon requests, so far as I'm aware. Having one, instead of returning a 404, can speed up the page load. Which makes 0 sense.

This is how I avoid this issue entirely:

    <link href=data:, rel=icon>

This is the smallest possible "null" favicon. It causes the browser to display nothing and ensures 0 HTTP requests for the favicon!

Does the browser display the generic "no favicon" icon, or is it just completely blank? I like the idea.

It's completely blank (tested in Firefox and Chromium).

> 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.

Express Helmet also turns it off by default and included a rationale for why (tldr: privacy leaks when there are random external links posted on a page): https://helmetjs.github.io/docs/dns-prefetch-control/

Missed the perfect headline: "A guide to giving head - all of the elements"

Surprised all icons is only:

<link rel="icon" sizes="192x192" href="/path/to/icon.png">

<link rel="apple-touch-icon" href="/path/to/apple-touch-icon.png">

I thought there was literally like a dozen different sizes and names to support all different Apple and Android devices.

You don’t even need those. Safari will automatically look for a file on the root and so does Android.

Still, I know what you’re talking about and it’s awful how many “gurus” suggest all that noise.

Yes. See this comprehensive resource [0] or sieve trough those linked at the Head project [1] - there are still bunch of tags (especially if you cannot place images into the root path) and myriad of images with varying degree of importance. Even now most resources apparently slightly disagrees with each other.

[0] https://realfavicongenerator.net/faq [1] https://htmlhead.dev/#icons

Question: how many of these are standardized? I'm not particularly interested in adding a bunch of specific, proprietary tags…

I'd go by W3 https://www.w3schools.com/html/html_head.asp

Then again were all slaves to the whims of Alphabet and Facebooks for traffic.

W3Schools is not W3C, and is frequently inaccurate.

Re: them being inaccurate: that was true many moons ago, but it seems they’ve cleaned up and are more accurate now IMHO.

They're less inaccurate than they used to be -- I'll give them that. But I still wouldn't rely on them as a source.

MDN is often a better alternative to W3Schools. They cover a lot of "web" things, not just JS docs.

This is specifically elements which are allowed in the `head` element of the document.

I recently read somewhere that for backwards compatibility reasons no new element types can be added within `head`. This causes a lot of overloading on the existing ones for elements like <link />.

I don't have any supporting evidence though.

The HTML syntax lets you omit the </head> tag. Any start tag not in the finite list of elements will implicitly start the body and go there.

    <html>
    <head>
    <title>I am in the head</title>
    <foo>I am in the body!</foo>
    </head>   <- this is a parse error and is ignored

HTML even lets you omit the <html> and <head> tags, so the following is valid and equivalent:

    <title>I am in the head</title>
    <foo>I am in the body</foo>

I've described how this works for SGML here [1], but it also applies to HTML.

[1]: http://sgmljs.net/docs/sgml-html-tutorial.html (see slides linked from TALK)

Screw it, let's abandon all markup and content: https://mathiasbynens.be/demo/css-without-html

(Explanation: https://css-tricks.com/using-css-without-html/ )

I havent heard of that but looking through RFCs might be the way to find out.

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.

White space ;)

Immediately found a bunch of elements I had never heard of. This is really neat.

Especially <base>

<base> was super nice in the old days when I worked with servers without subdomains for staging/testing, it made it pretty trivial to have domain.tld/website and domain.tld/testing/website ... granted, those were dark days and I'd never use that approach now, but it was appreciated.

Out of interest, what would you use instead these days?

Oh, usually <base> is still bound to the server root name, but in most cases an SPA or what-have-ye will be served off the base subdomain with client side routing hints - then everything can just be referenced using stripped down relative URLs.

Actually though, for the server-side processed stuff we are still using <base> to make sure that /fancy/bespoke/url/style URLs doesn't try to grab assets from /fancy/bespoke/url/style/styles/main.css - I guess it's less that I don't use it and more that now-a-days I rarely set it to anything other than domainname since I'll just materialize a new subdomain if I need to do something fancy.

A combination of sane, centralized routing and view layout, relative paths, and getting the scheme/host from the framework or environment config if really needed.

I've found this especially useful when rendering proxied web pages

Would love to see if/how these apply to html email/email-clients.

Email clients don't give a shit about your html. They will straight mess you up

ICBM tag with targeting coordinates hmm

They link to a helpful explanation: https://en.wikipedia.org/wiki/ICBM_address

tl;dr you should not expect to actually be targeted with an ICBM unless you foolishily also include elevation information.

Those dark grey on black comments are annoyingly hard to read. Web inspector to the rescue.

Bit light on the use of the Hreflang

Does anybody remember that funny thread where some dev here was saying "who calls it HTML5 anymore" as if everyone else was out of touch with stagnating irrelevant skills that would immediately throw red flags during a phone screen?

It just gave me a chuckle thinking about it

Thanks for the guide!

I mean, I'd call it html unless searching for the list of features that were bundled as html5 specifically. My understanding is that html5 was only versioned at all to differentiate it from legacy html versions. It's a living standard at this point, discrete versions are avoided at all costs. Just look at the doctype, if the intention was to continue versioning as before why did they leave the 5 out of the doctype?

Uh... what do people call "it" now-a-days? Serious

Mostly HTML5 in my experience.

Less seriously, sometimes it's referred to as "Oh, whatever happened to XHTML 2.0, I was so looking forward to that, oh well guess we're using HTML5" but this is usually at conferences.

I think people understood my comment neither correctly, and ,it seems, nor in the same way? Anyways, what I was asking was whether there exists a new name for html5? Have people dropped the 5? Comically, it was always a vague, tattered umbrella term from the get go (whenever used to refer to anything else than HTML5 the language/spec).

The spec which was once called HTML5 is just called HTML now. They dropped the version number since it is continuously updated rater than versioned.

Maybe just HTML?

It's kinda like how sometimes you use "Javascript" but in some contexts you're talking about a specific version (e.g. new features) and will instead mention it by a version name.

"web dev" according to that guy from the old thread

sure, I've heard that context too

Javascript thick clients.

Reply on news.ycombinator.com