First entry for Draft (Directly fine-tuning diffusion models on differentiable rewards) codebase.

[copybara-service[bot]]

First entry for Draft (Directly fine-tuning diffusion models on differentiable rewards) codebase.

[domenic]

† It’s probably possible to deliver the favicon.ico as image/svg+xml, however this approach seems hacky and not like one we would want to promote as a best practice.

I'm not sure I agree? It's worth testing, but I think if we can keep the number of HTTP requests to 1, the fact that the request happens to have .ico in the URL shouldn't stop us from reusing it.

[j9t]

I'm not sure I agree?

You wouldn’t find that hacky, or a practice not to recommend?

But this made me curious, and I set up a quick test on some random site. whattopackforatrip.com (a small site where I could just plug in a random image) now uses a favicon.ico delivered as image/svg+xml. A quick test in a few browsers (Chrome, Firefox, Edge, Opera, Safari on macOS, also Chrome and Firefox on Android—all latest versions) is positive except for Safari (it showed a favicon before, but not in this case) and Firefox Android (likely for other reasons, see #20180).

I’d be curious about more perspectives on whether and why this could be a route to prefer, and also feedback on support of this approach, as this was a promising, but also “quick and dirty” test run. (Thanks!)

[domenic]

Yeah, in general we don't care about file extensions on the web; the fact that we requested /favicon.ico instead of /favicon is a historical accident stemming from how this was first implemented and deployed, and not meant as an endorsement that the file has to be in Windows icon format.

[j9t]

I wasn’t aware the “not caring about file extensions” mindset is that alive again (it seems to have had better times). Hearing this I feel better about “favicon.ico as image/svg+xml” as an option for who wants to use icons as economically as possible.

Do you have any other thoughts that could be interesting and useful for author decisions, anything that could be worth documenting here?

A note, recent feedback would have been helpful in #4758, to collect information in one place and to spare us from unnecessary work. I’d have loved to learn about this earlier and without filing PRs and issues we then discard. I know you and everyone on the HTML side are busy, too, but I also know there’s no interest in making this unnecessary cumbersome for anyone, so I appreciate leaving just the comment.

[domenic]

Do you have any other thoughts that could be interesting and useful for author decisions, anything that could be worth documenting here?

We could mention in a note after the favicon.ico fetching algorithm that, like with img and other image resources on the web platform, various file formats are supported. (In particular, the ".ico" on the end of the URL is a historical artifact, and not meant to imply that browsers will reject non-Windows ICO images.)

A note, recent feedback would have been helpful in #4758, to collect information in one place and to spare us from unnecessary work.

I mean, there are a lot of proposals made to HTML all the time. It would be emotionally draining and bad for the community if I added a non-supportive comment to every one that I didn't support. We usually just leave them open.

That said, in that particular case the main point is I don't think there's anything wrong with having multiple icon formats and sizes. Your PRs to show that people can use SVGs if they want, instead of multiple sizes, fit fine with that.

[uuf6429]

Both an additional favicon.svg and returning an svg (or any other format) for a favicon.ico request to me feel like extending or adding a hack on top of an existing one.

Requesting favicon.ico automatically already felt like a hack, telling people they should return a different format feels like it's making the situation worse. This also applies to e.g. <img src=xx.png> returning a jpg for example - it's totally not good practice and browsers should display a warning that something weird is happening.

A better solution in my eyes would be to request /favicon and then the servers are free to return whatever they want - in case of 404, fall back to old favicon.ico (for BC, but IMO not ideal). And all that is assuming the relevant s are missing in the html, otherwise just follow those links without any extra behaviour.

Just my two cents.

[Gunni]

What about a http header that tells the browser which icon to load? Would work for non-html too.

F.ex a link header with an icon Link: </favicon>; rel=icon; as=favicon?