Convert to octicon SVG library

[jolheiser]

This is an exploratory PR looking to (incrementally) replace the webfont Octicons with SVGs using https://gitea.com/go-icon/octicon

The version of octicons we use is one of the last before they abandoned webfonts and moved to only SVGs.
The vendored library basically converts the SVGs into Go-code that can be used to inline them.
Updating it is trivial compared to a webfont (not to mention we can't update it otherwise, as noted above)

For this draft, I updated the repository header icons for a preview.
Images are with no avatar, though it also updates the icons placed after the repo name if there is an avatar.

[guillep2k]

Our current bindata.go system compresses the resources into a virtual file system, so Gitea's executable stays compact. Perhaps there's a way of compressing this too?

How will this affect custom templates that currently use the octicon font?

[lafriks]

I think I would prefer that icons would stay purely in client side (css/webfont/js)

[silverwind]

Inline SVG is certainly the way to go, it will for example allow to have multi-colored icons and allow proper targeting/sizing via CSS. Webfonts are just a ugly hack in my eyes.

[lafriks]

Problem is that we can't really use them in dynamic client side scripts/vue components than

[jolheiser]

Our current bindata.go system compresses the resources into a virtual file system, so Gitea's executable stays compact. Perhaps there's a way of compressing this too?

To be honest, I don't know how much it can compress inside the Go code it lives in.
Gitea binary size (on Windows):
TAGS="bindata sqlite sqlite_unlock_notify" make build

• Without this library: 61.3MB
• With this library: 61.4MB
  Sorry, I know that's not a great comparison, but it seems to be fairly small.

How will this affect custom templates that currently use the octicon font?

Currently, it won't. The two can live independently of each other.

I think I would prefer that icons would stay purely in client side (css/webfont/js)

Unfortunately we cannot ever update octicons then, as they no longer have a webfont. (Though there are some third-party libraries that seem to be attempting to re-create the webfonts)
This library still renders on client side, all it does is spit out the correct SVG XML.

[silverwind]

Problem is that we can't really use them in dynamic client side scripts/vue components than

There are ways to achieve that. The backend could serve a "spritemap" in HTML and individual images could be referenced via <svg><use xlink:href="#icon"></use></svg>.

https://github.com/cascornelissen/svg-spritemap-webpack-plugin
https://css-tricks.com/svg-sprites-use-better-icon-fonts/

[lafriks]

@silverwind I don't mind svg icons but I don't like that icons are being generated in html templates from go code

[silverwind]

Yeah, agree on that one, that kills them for any frontend usage. Ideally I'd like to see us having a directory of SVGs to be bundled into one file via webpack or similar. Then, both backend and frontend code can load them via use tags.

[lunny]

@guillep2k I have sent a PR #7109 to add compress to embbed resources. But that may have some conflict with macaron static middleware. That needs more work.
@lafriks we can store the generated files.

[guillep2k]

The performance aspect of using SVGs is a hairy problem. There are pros and there are cons:

• A font resolves all icons at once, and they are all cached. It will be the best solution if performance is the only concern. There may be an equivalent option with SVG (more on this later).
• Out of line SVGs require an extra HTTP request, but once requested the resources can be cached. They can also be gzipped.
• Inline SVGs do not require an extra HTTP request, but the information is sent over the network every time an icon is shown and also increases CPU usage due to extra data for compression (when gzip is enabled).

There may be a technique to send all possible icons in a single SVG file to the client and resource from that, a concept similar to a spritemap but in the form of a XML file with all the SVGs inside as snippets, managed by a web worker that can slice by ID. I've never tried this, so I don't know if it's taxing for the user agent, but from the network point of view it should be on par with the font option.

[jolheiser]

I think ideal usage would indeed be a spritemap.
If someone wants to use webpack and some plugin to bundle SVGs into a spritemap, that would probably be one of the best options.

I only went this route because I am more comfortable with Go than the JS ecosystem.
But it sparked the conversation, so I'll count it as a win. 😉

[silverwind]

@guillep2k spritemap is one single request, just like a webfont. It can be inlined in HTML too, thought that will not be so easy for us as HTML is not in webpack (yet).

[silverwind]

Thought it could be baked right into a go template too I guess in a readable format like

<svg xmlns="http://www.w3.org/2000/svg" style="display: none">
  <symbol id="codepen" viewBox="0 0 64 64">
    <path etc.../>
  </symbol>
  <symbol id="youtube" viewBox="0 0 64 64">
    <path etc.../>
  </symbol>
  <symbol id="twitter" viewBox="0 0 64 64">
    <path etc.../>
  </symbol>
</svg>

then include that template in index.html and <use> wherever required.

[guillep2k]

@guillep2k spritemap is one single request, just like a webfont. It can be inlined in HTML too, thought that will not be so easy for us as HTML is not in webpack (yet).

Oh, that's what I was talking about. I didn't know the term spritemap was used beyond bitmaps. 😝

Inlining seems inefficient, because we won't be able to cache it. Seems to me that it's better off as a separate resource, that can be cached.

[jolheiser]

Closing this PR, it seems we've come to a proposed solution.