Hacker News Reader

Comment by shadowfaxRodeo | Hacker News Reader

Someone correct me if i'm wrong but I've been doing a bit of research and I'm pretty sure you can remove these:

    <link rel="icon" href="/favicon.ico">

by default if a supported icon isn't found in the markup all browsers search for favicon.ico at the site's root.

The same is true for apple touch icon, you can just remove it:

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

I've tested this and it works fine on apple devices.

   <meta charset="UTF-8">

By default servers add the charset as an http header. So you don't need to declare it in the document — in the case of offline where there are no http headers, the browser works out what encoding to use. And since utf-8 is the only valid charset for HTML5 it should be the default. I've tested this a bit, and it seems to work.

View on HN

> I'm pretty sure you can remove these: <link rel="icon" href="/favicon.ico">

The presence of the SVG favicon, with the same rel, may throw the default-finding off. I haven’t tested it, but I would expect various older user agents that don’t support SVG to fall over if you omit the favicon.ico link once you’ve provided the SVG link.

> By default servers add the charset as an http header.

This is not true: it depends entirely on the server configuration. Maybe one serves `content-type: text/html`, maybe another serves `content-type: text/html; charset=utf-8`. The reason people recommend <meta charset="utf-8"> is so that you don’t depend on server configuration that the authors of the HTML commonly can’t control, and which may not always be possible: specifically, what happens if someone saves your HTML page locally?

> And since utf-8 is the only valid charset for HTML5 it shouldn't be the default.

UTF-8 is the only valid charset for HTML now, but that doesn’t mean it’s the only supported charset. See https://html.spec.whatwg.org/#determining-the-character-enco.... The default varies by locale and even user configuration (see the table in step 9). If the default was changed to UTF-8, many non-English old documents would break. Maybe eventually the default will be changed anyway, at least where the short <!doctype html> doctype is used.

That's a good point about the favicon mix. I really want to get a difinitve answer to all this. I'll do some tests when I have time.

I guess that should read most servers? I'm not much of a backend dev, but every default I've seen has included the charset in the headers.

I realize I'm blowing against the wind on this one!

On a site by site basis it seems that you really can get rid of it. I've only tested my own sites offline in various browsers and they work fine without the meta tag.

One example of a site that doesn't use it is YouTube, and I figured that can't be an accident.

> in the case of offline where there are no http headers, the browser works out what encoding to use

For file: URLs, Firefox and, a bit less reliably, Chrome do work out that an HTML file is UTF-8. Safari does not.

> And since utf-8 is the only valid charset for HTML5

Correct.

> it should be the default.

It isn't. See https://hsivonen.fi/utf-8-detection/ for why.

Having <meta charset="UTF-8"> in the boilerplate is good advice.

> the browser works out what encoding to use.

Historically, letting the browser guess anything at all has been a disaster. Although IE is all but dead now, there's no guarantee that another browser won't try something similarly reckless in an attempt to be a little too convenient.

So i guess the question is — should we keep markup for the case where someone downloads our webpage on a legacy browser?

For me the answer is yes, if people are using an old netbook on a dialup connection and they save your site locally to save data. That could be a good idea. I'll do some testing though because I think even old IE defaults to utf-8.

The edge cases are hard to test. IIRC the weirdest issues had something to do with valid UTF-8 content the first X bytes of which also happened to be valid in some exotic charset related to the user's locale. English users would rarely come across such issues.

IE defaults to the locale-dependent legacy Windows code page.

> And since utf-8 is the only valid charset for HTML5 it should be the default.

In actual practice, firefox will try latin encoding if the first few kilobytes are ASCII7 and the document is not indicating its encoding.

Then that's a bug in Firefox that needs to be fixed, not worked around.

I have run into issues using KaTeX and some other rendering libraries without the <meta charset="UTF-8"/> tag. There are likely other problems that could occur without it.

Reply on news.ycombinator.com