Live data from Hacker News

HTML Tips (2020)

markodenic.com

1–10 of 136 posts

Re: HTML Tips (2020)

#6
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 element: see also the 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-....

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... 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 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 inside the 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,…'
———

If you enjoyed this article, see also 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.

Re: HTML Tips (2020)

#7

I want a cachebust="yes" attribute that invalidates an image when it changes, yet never contacts the server when the image is unchanged.

A common technique here is to use the query string to control this, with something like ?t=‹timestamp› or ?v=‹version› or ?‹hash of file contents›. Then the server can include proper cache-control headers to say “this is immutable, never going to change, don’t bother asking me if it’s changed”.

A cachebust="yes" attribute wouldn’t be useful in practice because the server would either be serving it to everyone, effectively disabling caching (and which would be better done by actually disabling caching with the cache-control header), or need to decide who to serve the attribute to, in which case there are better solutions. In short, cache busting only works if you have some sort of cache key, which is what the query string technique is all about doing.

Re: HTML Tips (2020)

#10

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…

> 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.

I was saying the same thing but then I realized something. The thing about webp isn't about how it compares to jpg[0]. Png on the other hand, with all those logos and some with transparency. Webp can replace these with only a fraction of png-size.

Anything photographic, where quality is priority and transparency isn't required I find jpg to be finer quality.

[0] Altough that's often the narrative.

Post reply on HN