Suggest the /favicon.txt as default bookmark icon.

[Filius-Patris]

This issue specifies a subset of the enhancement #140.

As favicons are, by their name, 'favourites icons' (source: Wikipedia). Thus they should primarely be used as such: icons for the 'favourites' (bookmarks) tab. My suggestion is that the /favicon.txt should only be fetched when you want to create a bookmark.

How it'll work

This is how the functionality would look from a UI perspective:

• The user triggers the Bookmark dialog
• Lagrange fetches /favicon.txt
• The unicode character is prefilled into the "Icon: " field.
• It is then stored like up until now in the bookmarks.txt file.

More acceptable than #140?

@skyjake stated his opinion, that the way #140 aims to implement favicons is not according the gemini design. The most common argument heard agains this implementation is, that it causes requests which are not directly user-initiated. I think that this request is caused by the user directly enough to be allowed. Similarly how subscribing to a page request the feed, creating a bookmark requests the favicon.

Considerations

What if the server owner updates the /favicon.txt file? Will Lagrange fetch it from time to time? Or will we just keep the local copy?

Links & References

• The favicon RFC: gemini://mozz.us/files/rfc_gemini_favicon.gmi

[skyjake]

I think this is acceptable with this little addition:

• The user triggers the Bookmark dialog
• Lagrange fetches /favicon.txt if the "Fetch Favicon when Bookmarking" setting is enabled (default: no)
• The unicode character is prefilled into the "Icon: " field.
• It is then stored like up until now in the bookmarks.txt file.

What if the server owner updates the /favicon.txt file?

I think the "correct" way to do this would be to consider the /favicon.txt a subscription that gets fetched once per week or couple of times per month. However, I don't expect favicons to change very often (on the web they don't) so this is probably overkill. A manual fetch button in the bookmark edit dialog or menu item in the bookmark list is always an option?

The bookmarks list will eventually get the ability the select multiple items, so all favicons could be easily updated with a single action.

[Filius-Patris]

Yes, I'd love to see this implemented the way you mentioned.

Another option that just came to my mind was a button next to the favicon textfield, with the description "Attempt to fetch from site" (or similar), which can be pressed to fetch /favicon.txt.

Something like this: A disadvantage however would be that I don't have an intuitive way right now to show that the request failed.

 

However, I don't expect favicons to change very often (on the web they don't) so this is probably overkill.

I fully agree.

[soko7awen]

Is this still being considered? I was a bit frustrated at how #140 was treated. But this option is good as well.

[skyjake]

To be honest, this is quite far down the priority list. I have not discarded the idea, however when it comes to Gemini, the server is not intended to have much (if any) control over how the capsule is presented to the user in a client. A favicon is roughly comparable to a stylesheet in that it controls some aspect of how the client is supposed to visually represent the capsule.

[robog-two]

I think it's honestly a little silly to say a favicon is "rougly comparable" to a stylesheet. A stylesheet contains an entire programming language, complies with the thousands of words of the CSS3 specification, and must be perfectly implemented for every page to render correctly. Favicon.txt is literally just one to four unicode characters, which are already supported by Lagrange if configured by the user, and would simply need to be set with an additional gemini request based on an opt-in setting. I'm going to be frank, adding favicon support to lagrange will not ruin the "spirit" of gemini. Not even close.