Add network icon ISUPPORT token #563
Conversation
extensions/network-icon.md
Outdated
|
|
||
| ## The `draft/NETWORKICON` ISUPPORT token | ||
|
|
||
| If a server publishes a `draft/NETWORKICON` ISUPPORT token, the value MUST be a URL to an image. The URL SHOULD use the "https" scheme. |
There was a problem hiding this comment.
should there be a way for the client to say what mime types it accepts for the image to be in?
There was a problem hiding this comment.
MIME types are one thing, image size in pixels is another one… For the latter negotiation wouldn't work, the client might want to show the icon in different places, with a different size for each one.
The Web solves this by listing all possible icons, with all formats and sizes. I've decided against this approach for this spec because:
- It adds a whole bunch of extra complexity.
- It's a lot of characters. URLs might be quite long.
If we really wanted to solve this, maybe advertising the URL of a JSON manifest would be better (like Web app manifests). But I don't think we actually need this complexity.
There was a problem hiding this comment.
Something like .ico that can pack multiple sizes could work in this regard.
There was a problem hiding this comment.
.ico is a very old format, I don't think we should build on it. It's missing a lot of features one would expect from modern image formats. I don't even think my GUI framework supports it.
There was a problem hiding this comment.
one option, to move the complexity elsewhere, would be to only support svg icons.
There was a problem hiding this comment.
My expectation is that server authors will use one of the widely supported image formats (e.g. PNG or SVG).
If format negotiation is really deemed necessary by a network, HTTP supports this feature natively already via Accept.
There was a problem hiding this comment.
I think this spec should define the format and dimensions, just to keep things simple for clients. There's nothing stopping us from defining something more complex in the future if the flexibility is needed.
There was a problem hiding this comment.
I don't think this spec should leave the format entirely open-ended. If the spec allows any format, then are clients also expected to support each and every single format that could be rasterized to an image? SVG, PDF, PS, Xfig?
If we go for only HTTP icon location (which I'm not a big fan of, but anyway), then the Accept header should probably be mentioned explicitly so that clients and servers are advised to use it. And the server be required to provide at least one of (for instance) ICO, BMP, PNG. So that lightweight clients could support only these 3 formats and be assured to get the network icon, if any.
Also, FWIW, ICO format does support PNG as individual images and support alpha channel for both BMP and PNG individual images.
There was a problem hiding this comment.
+1 for using the Accept header. The server can respond with 406 if its not available in that form.
|
I think we should go with I absolutely agree that the icon would and in 80-90% of cases should use the same icon all over their network, however I feel like this would disallow theming of certain servers icons. For example, if I have I do think it would be weird if people used completely different icons for each of their servers and I don't imagine anyone would do that anyway, but I still think this should be allowed, and, although it's technically not forbidden by this here spec proposal to use different icons on each server, the name suggests it would be and could be confusing to client developers. I think outright forbidding different icons for different servers, either by suggestive language or by spec, limits things unnecessarily and I vote to change the token name to |
I asked about this recently in #ircdocs and the predominant advice I got was that this restriction should be removed from the Modern spec. |
|
Regardless of any future decision to allow draft/ in isupport, that decision has not happened yet nor even been formally proposed. So let’s continue to submit specs according to the status quo rather than desired but undecided futures. |
|
I also think we go with ICON and not preempt a need to specify whether it has to be the same network wide or can differ per server. That can be up to network operators (this includes server operators, they are necessarily collaborators) |
|
In one of the other proposals I seem to remember there was a {size} template variable which the client could use to scale the icon. Is this useful to client developers? |
No, images are small anyway and it is trivial to resize them client side. |
|
The avatar metadata key from the registry defines an optional {size} template variable. Clients can resize, but depending on the range of sizes, different resizing algorithms will produce variable results. A template variable would allow servers to provide e.g. a custom 16x16 icon whose pixels have been artisanally crafted. So it can be useful, but unsure if that's desired here. |
|
unsolicited +1 for the {size} template variable, if not for reduced data usage then for optical sizing adjustments in particularly complex logos. i need to adjust my network's coat of arms for use at 32x32 |
|
Renamed to |
|
Opened ircdocs/modern-irc#250 to discuss prefixes for ISUPPORT tokens. |
|
I still see |
|
Yes, I have intentionally left the |
Closes: ircv3/ircv3-ideas#123