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://www.chromestatus.com/feature/6302414934114304
https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYL...
Not sure if HTTP2 push is what you're referring to.
> It must come before the <title> element to avoid faulty characters in the page title.
This isn’t quite true. Rather, any meta element declaraing a charset should occur within the first 1024 bytes, or it may be ignored.
———
Print styles: you might think that putting print styles in a separate file would let the browser not load them unless the user actually seeks to print, but in practice browsers load all stylesheets, even for media queries that will never match. I think this may be for fingerprinting reasons, but I don’t truly know. In the distant past (maybe a decade ago), print stylesheets would block rendering while they loaded in most browsers. No idea whether they still do, but I’d guess (uneducated) that they may be deferred a bit now.
In light of all this, I generally recommend a small @media print { … } block in your existing stylesheet, rather than a separate print stylesheet file.
———
The favicon prefers-color-scheme thing: don’t put too much weight on this, it doesn’t actually do what people are commonly saying it does: there is only a slight correlation between prefers-color-scheme and the colour the favicon is rendered atop. prefers-color-scheme is for content, not chrome. If I recall correctly, Chrome’s incognito mode renders the tab bar dark; and in Firefox the concept of browser theme (light/dark/all kinds of custom) is completely separate from prefers-color-scheme—so I have dark browser chrome but light content.
Understand that the favicon could be being rendered atop anything at all. Any solid colour, any image, anything. Very light and very dark greys are the most common colours for them to be rendered against, but you want to make it so that your favicon is at least not horrifically bad on any background.