News for hackers. Stuff that matters.
Re:HEAD – A guide to <head> elements by combatentropy on Monday September 30, 2019 @06:27PM (#21120253)
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.
Re:HEAD – A guide to &lt;head&gt; elements by gog on Monday September 30, 2019 @06:37PM (#21120328)
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.

Re:HEAD – A guide to &lt;head&gt; elements by kevin_thibedeau on Monday September 30, 2019 @06:45PM (#21120376)
BOM is not valid in UTF-8 for one thing.
Re:HEAD – A guide to &lt;head&gt; elements by SpaceManiac on Tuesday October 01, 2019 @02:54AM (#21122673)
To be pedantic, the Unicode standard disrecommends the use of a BOM in UTF-8-encoded documents rather than declaring it invalid.
Re:HEAD – A guide to &lt;head&gt; elements by kevin_thibedeau on Tuesday October 01, 2019 @03:26AM (#21122826)
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.
Re:HEAD – A guide to &lt;head&gt; elements by erik_seaberg on Tuesday October 01, 2019 @03:29AM (#21122849)
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.
Re:HEAD – A guide to &lt;head&gt; elements by account42 on Wednesday October 02, 2019 @06:54AM (#21135049)
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?

Re:HEAD – A guide to &lt;head&gt; elements by combatentropy on Monday September 30, 2019 @07:51PM (#21120754)
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.

Re:HEAD – A guide to &lt;head&gt; elements by tyingq on Monday September 30, 2019 @06:32PM (#21120302)
Probably nice for people that save the HTML document locally via curl or similar.
Re:HEAD – A guide to &lt;head&gt; elements by combatentropy on Monday September 30, 2019 @07:50PM (#21120745)
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.

Re:HEAD – A guide to &lt;head&gt; elements by tyingq on Monday September 30, 2019 @07:56PM (#21120779)
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.