My Current HTML Boilerplate

https://modernizr.com/

http://blog.danieljanus.pl/2019/10/07/web-of-documents/

Both correct: charset before title element, and charset within first 1024 bytes.

Older browsers would infer charset automatically if not in first 1024 bytes or undefined. So if user had possibility to change the page title (for example: profile name), they could do persistent XSS by having IE infer the title contents as UTF-7, before the actual declaration happens. Sometimes the title or other elements can also be stuffed, so the charset declaration happens after 1024 bytes.

> Older versions of Internet Explorer can be tricked into interpreting the page as UTF-7. This can be used for a cross-site scripting attack as the < and > marks can be encoded as +ADw- and +AD4- in UTF-7, which most validators let through as simple text.

Modern browsers don't fall for this, but this was a huge XSS vector back in the day (for instance, Google was vulnerable to this, and maybe still is, for its users on ancient browsers).

Does it really matter anymore with HTTP2?

https://addons.mozilla.org/en-US/firefox/addon/aardvark-duex... (based on https://www.karmatics.com/aardvark/ which is a bookmarklet hence does not work with Content-Security-Policy enabled pages)

It allows to easily and quickly remove stuff from webpages, without opening devtools. Just hover over unwanted element, keep clicking `w` (wider) until you have its whole container, then `r` to remove.

This is what the print style looks on screen on Firefox on my computer: https://ibb.co/QN6Gsjk

Pretty decent if you ask me. Sure, technically its not separate stylesheet in Wikipedias case, but media queries, but the effect is the same.

  document.documentElement.className = 'js';

Nowaways I default to "js isn't available" state, and if the script(s) is able to load, then it augments or hydrates the static markup.

.....

Because facebook/twitter/linkedin have different ways to display information and sometimes what's inside the description (for SEO purposes) is NOT the same as what you want displayed on a social media platform or other outlet for your content!

<title>, <meta name="description" ...> nearly always get used to optimise for Google and not the end user of a social media platform.

Excuse my ignorance: what the heck does this achieve?!

This is a cat and mouse game. iOS 14 doesn't respect user-scalable=no or maximum-scale, unfortunately.

What you need to do is this now, if you don't want the web browser to respond to scaling (and as much as the idiots at Apple love their high horses, there are actual use cases for this, including when you are building a webapp or when you are building a web page with your own pinch zoom logic):

    <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
    <style>body { touch-action: pan-x pan-y; }</body>

[1] https://github.com/Conaclos/origin.html/blob/master/template...

As a default for otherwise-unstyled content, it's not very user-friendly to override the user's default font and size preferences.

The browser lets me decide how I'd like unstyled text to appear. Unless you're explicitly doing typographic design, please don't arbitrarily override my choice.

Just blatantly breaking standards like this is not a good idea seen some real howlers from sprint back when I worked on x.400.

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.

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.

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.

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

[1]: https://docs.microsoft.com/en-us/archive/blogs/ie/living-on-...

https://www.w3.org/TR/2011/WD-html-markup-20110113/syntax.ht...

(The XML serialisation is still a thing, in various contexts. Serve a document with an XHTML MIME type and the XML parser will be used; or embed HTML in SVG via foreignObject and it’ll be XML serialisation you need. Also note that SVG in HTML invokes… uhh… more XMLy behaviour from the HTML parser, so that the trailing slash does have its XML meaning.)

I think for the most part, it's a pretty reasonable selection of tags. And there's almost no excuse to keep crazy old stuff around these days.

The big non-self-updating X is IE11 which the author addresses separately.

  <!doctype html>
  <title></title>
  <h1></h1>

Your boilerplate lacks all the features of this one...

JavaScript is executed differently when it’s a “module script” to when it’s a “classic script” (using the HTML spec terms), so you want a way of preventing old browsers from executing it (whether they’re syntactically compatible or not). Hence type="module", because old browsers won’t execute scripts with the type attribute containing an unknown value.

Once you have that, you commonly want to bifurcate on modules support, so you want a way of saying “don’t execute this if you support modules”. This can be done with feature-detection code, to the effect of “does it support modules? if yes, do nothing; if no, load the code, probably by adding another script tag with the correct src to the document”, but this is inconvenient and causes at least mild inconvenience with security measures like Content-Security-Policy. So the solution was to put another attribute there that new browsers could use as the inverse of type="module": nomodule.

Perhaps it’s a big ol’ sigh, but as is very commonly the case with such sighs, they make a good deal of sense when you understand the reasons and history involved.

Language detection is much easier than synthesis, and one would think that a good synthesizer would devote the 0.1% of their engineering time necessary to have good language detection as well.

"Why can't we assume UTF-8 unless told otherwise?"

And this I really do not understand either. I lost hours to restore data, that got lost in conversion from various text encoding formats, discovered too late.

Because the <title> is often something like "My Content | The Example Blog", which is a redundant information on social media cards so you set og:title to "My Content" only.

> Why can't it use the favicon for apple-touch-icon?

Because the favicon usually is a 32x32 icon that is small and only seen in the tab of the browser, whereas the apple-touch-icon is physically huge, and so requires more resolution.

> Why can't it use the URL for the url?

I assume you're talking about the canonical link tag? This is to prevent SEO penalties - specify a canonical link and Google will prefer your site as origin for the content over spammers that don't bother setting the tag, or in case you run an old-school site with dedicated mobile and desktop sites (see https://developers.google.com/search/docs/advanced/crawling/...).

> Why can't we assume UTF-8 unless told otherwise?

Historical baggage, mostly - the default charset for old content unless specified was either US-ASCII or its superset ISO-8859-1/latin1 (the HTTP/1.0 spec defaulted to US-ASCII, see https://tools.ietf.org/html/rfc1945 section 3.4 and the HTTP/1.1 spec, section 3.7.1, https://www.ietf.org/rfc/rfc2616.txt that defaults to ISO-8859-1). And there is a lot of old content that would break if this default assumption would change.

Because you can have multiple URLs for the same content and you need a way to say "by the way if you want to link to this page here's the proper URL"

For example, if you have example.com/blog/foo, it's possible that m.example.com/blog/foo, example.com/blog/foo/, example.com/index.php?path=/blog/foo, example.com/index.php?p=1234, example.com/blog/foo?textonly=1 etc etc all point to the same blog post and in many cases you simply can't set up a redirect because the URL is valid.

On the rest: I mostly agree.

<title> versus og:title is commonly stupid, especially because consumers will tend to fall back to the <title> tag anyway (though in theory they should differ, with <title> normally including the site name, but og:title not supposed to); og:url and rel=canonical are even more stupid, because consumers will fall back to using the actual URL, so their only purpose is cases where the content is actually found at multiple URLs. (“But og:title and og:url are mandatory for OpenGraph validity!” you say? Please, you didn’t even put the prefix="og: https://ogp.me/ns#" attribute on the root element. No one does. No one cares. And I don’t think anyone cares for at least og:title and og:url either, though <meta property=og:description> versus <meta name=description> is uglier, and you can’t even merge the two or Twitter ignores the thing.)

Why can’t we assume UTF-8 unless told otherwise? Historical reasons, mostly. The web is an old place. Rejoice that everything new is done purely in UTF-8, and be comforted that even some of the older things are slowly shifted to a UTF-8 default over time, as the impacts of doing so become smaller.

The Apple icons are a more complicated historical mess. Be glad it’s down to only one stupid extra tag now, rather than a dozen or so, for each of their different device sizes. The time has come when they could fairly reasonably merge it back into icon, since they’ve given up on all of their fancy appearance of their icons.

https://techcommunity.microsoft.com/t5/windows-10/windows-10...

See https://hsivonen.fi/utf-8-detection/

    <!doctype html>
    <title>Your website: title</title>

    <h1>Title of your site</h1>

    <p>
    Here begins the text of this page.

You expect people to paste the MIT license into their website source in order to use your "minimal" headers?