Some remarks, with some opinions, some caveats, and some extra info that I find interesting: 1. Lazy loading: generally speaking, just don’t do this. It’s much

Some remarks, with some opinions, some caveats, and some extra info that I find interesting: 1. Lazy loading: generally speaking, just don’t do this. It’s much better than doing it in JavaScript (especially when combined with a blurry image until it loads, which I and many others find surprisingly disconcerting), but if you’re not very close to the server (which very commonly means “if you’re not in the USA”) then it commonly just means that the images won’t be loaded when you scroll to them. Also there’s the whole load-the-page-then-go-offline problem, which I feel is more common than most realise. Instead, I say: if you care about the image, you very probably shouldn’t use lazy loading on it; and if you don’t care about it, hey, why not just remove it? 2. Telephone and SMS links: the unfortunate trouble with these is that you can’t detect whether they’ll work or not. If they don’t work, they’ll probably just mysteriously do nothing, and you can’t reliably detect that, because your code may not be able to detect if it did do something. This is all just something to be aware of. 4. The <meter> element: see also the <progress> element. Two similar elements that differ in semantics as to which you should use. 6. Fieldset Element: a point in the demo that’s not ideal is that the gap between the radio button and the label isn’t clickable. One way of fixing most of this is to start the label immediately after the radio button, with the leading whitespace inside it rather than before it. But depending on user agent and content styles, even that may well be insufficient, leaving a tiny gap. In a situation like this, the ideal is to put the radio button inside its label, and make the label `display: block`, or something else that achieves this effect (if done carefully, you might even find `display: grid` suitable nowadays). 7. window.opener: it suggests including rel="noopener" or rel="noreferrer" in order to remove the opener; I think it’s worth noting for explanation that noreferrer implies noopener (because you could access the referrer through the opener): https://html.spec.whatwg.org/multipage/links.html#link-type-noreferrer https://html.spec.whatwg.org/multipage/links.html#link-type-.... 10. The `spellcheck` attribute: this is actually a tristate attribute: it has states true, false, and default (which mostly means “inherit”). `spellcheck="true"` can be written more briefly as just `spellcheck` (which, in the HTML syntax, is equivalent to `spellcheck=""`). See https://html.spec.whatwg.org/multipage/interaction.html#attr-spellcheck https://html.spec.whatwg.org/multipage/interaction.html#attr... for more info. 12. HTML Accordion: I have just two general remarks on web design here. ① If you’re using something like this for FAQs, please strongly consider not using an accordion, but instead having a table of contents with links to each question, followed by the questions (as headings) and answers (as paragraphs); or if you’re not willing to do that, please provide an “expand all” button through JavaScript. ② On the web, accordions have historically regularly been implemented so that at most one item of any set will be open: that opening another closes any that was open. Please don’t do this. It’s a pain. I just want to read stuff, I don’t want to have to interact further. (See also my “expand all” request in part one.) 14. `download` attribute: this can also take a value, which will be used as the filename. This is useful if you generate a file client-side as a data: URI. It’s not so useful outside that, actually, as you’re probably better to get the server to set the filename via the content-disposition header, or if you’re generating a file client-side with a blob: URI, use File instead of Blob so that you can set the filename. 15. .webp: significantly overrated, in my opinion. It doesn’t give anywhere near as big a boost in compression relative to properly-done JPEG as people think (like under 10% a lot of the time). Now AVIF, that’s another matter. 16? Video thumbnail: an interesting thing that has just occurred to me on this is that the poster attribute doesn’t let you provide multiple formats like <picture> does. Hmm, so you probably keep serving a JPEG here instead of WebP, AVIF or whatever else. Wonder if anything can ever be done about that. I can imagine them making poster="#foo" followed by <picture id="foo"> inside the <video> work. Eek, this similarity to svg:use made me realise that you can actually achieve this goal with SVG already: the code below ought to do it; ugh! poster='data:image/svg+xml,<svg …><foreignObject …><picture xmlns="http://www.w3.org/1999/xhtml">…</picture></foreignObject></svg>' ——— If you enjoyed this article, see also https://markodenic.com/css-tips/ https://markodenic.com/css-tips/ from the same author on CSS tips, discussed here nine days ago at https://news.ycombinator.com/item?id=26945263 https://news.ycombinator.com/item?id=26945263.