undefined | Better HN

0 pointsnotatoad4y ago0 comments

The hints are not a hint in how to render the icon - browsers don't need hints for that. the hints are an instruction to browsers on which icon to download in the case where multiple icons are specified.

if you are safari and you don't know how to display SVG favicons, then you don't need to waste bytes downloading a favicon only to fail to display it. the HTML does not limit a site to only one favicon.

0 comments

anyfoo4y ago

Why is that not done through the MIME type and using HEAD? The server is apparently much better able to figure out the MIME type through magic numbers and file extensions of the actual file, than the author (human or not) of the HTML, as we see.

The same headers also inform the browser that they can skip downloading a favicon that they consider too big, for example.

scrollaway4y ago

HEAD support is never a guarantee, and content type auto detection is just another kind of heuristics.

anyfoo4y ago

Ugh, HEAD is not being universally supported, at least for static content? Okay, I accept that this has value then.

As for the MIME type, for image types I'd say it's more than stable enough. Certainly much, much more stable than the 6.7% error rate mentioned in the article here, I'd be surprised if it was even 1%. If you double click on an image on your desktop for example, you can in almost all cases expect that it will be opened correctly. It ceases being a heuristic entirely if you tell the webserver that *.png is image/png, and only put PNGs with names ending in ".png".

Guess those are the reasons why I got out of web development in 10 years ago, everything's held together by scaffolding and needlessly wasteful and inefficient there.

scrollaway4y ago

You might be overthinking this. I agree with the philosophy that stricter is better, but in this case what do you expect broken hints to do?

They’re not used for rendering, they’re used for figuring out what to fetch. A HEAD request would be far less efficient than knowing ahead of time what to fetch: 1 request versus 2N+1 requests.

What you suggest sounds all fine but the entire web is user input for a browser, so no matter what, you need to define how to fail. If you can fail gracefully, you might as well do so, because a failure might not even be triggered by bad code/configuration on your side but simply by flaky network issues.

2 more replies

j / k navigate · click thread line to collapse

0 comments

anyfoo4y ago

The same headers also inform the browser that they can skip downloading a favicon that they consider too big, for example.

scrollaway4y ago

HEAD support is never a guarantee, and content type auto detection is just another kind of heuristics.

anyfoo4y ago

Ugh, HEAD is not being universally supported, at least for static content? Okay, I accept that this has value then.

Guess those are the reasons why I got out of web development in 10 years ago, everything's held together by scaffolding and needlessly wasteful and inefficient there.

scrollaway4y ago

You might be overthinking this. I agree with the philosophy that stricter is better, but in this case what do you expect broken hints to do?

They’re not used for rendering, they’re used for figuring out what to fetch. A HEAD request would be far less efficient than knowing ahead of time what to fetch: 1 request versus 2N+1 requests.

2 more replies

j / k navigate · click thread line to collapse