Delivering Octicons with SVG(github.com)
github.com
Delivering Octicons with SVG
https://github.com/blog/2112-delivering-octicons-with-svg
15 comments
Does this cause the HTML sent over the wire to be bloated, i.e. the svg for the same icon could be repeated multiple times on the same page?
They say they don't inline because it doesn't make sense in their case, but if you do inline and use xlink [1], you don't duplicate data transmissions.
There are other techniques for client side-templated sites that will cache SVG icon data. For example, angular material's icon service [2] does this.
[1] https://css-tricks.com/svg-sprites-use-better-icon-fonts/
[2] https://material.angularjs.org/latest/api/service/$mdIconPro...
There are other techniques for client side-templated sites that will cache SVG icon data. For example, angular material's icon service [2] does this.
[1] https://css-tricks.com/svg-sprites-use-better-icon-fonts/
[2] https://material.angularjs.org/latest/api/service/$mdIconPro...
I expect that gzip would make the over the wire price for repeated icons insignificant.
Yes and no.
The repetitions would have to appear within 32KB of each other to be captured in the DEFLATE window [1] which, given that a lot of pages can be 100s of KBs of uncompressed text, may make that impossible.
Additionally, the zlib (or whatever) compression settings would have to be set aggressively enough to identify those duplicates as the best run-lengths to encode. Since GitHub is generating a lot of this live and delivering with low TTFB, they may be using a less aggressive than necessary setting.
[1] https://en.wikipedia.org/wiki/DEFLATE#Duplicate_string_elimi...
The repetitions would have to appear within 32KB of each other to be captured in the DEFLATE window [1] which, given that a lot of pages can be 100s of KBs of uncompressed text, may make that impossible.
Additionally, the zlib (or whatever) compression settings would have to be set aggressively enough to identify those duplicates as the best run-lengths to encode. Since GitHub is generating a lot of this live and delivering with low TTFB, they may be using a less aggressive than necessary setting.
[1] https://en.wikipedia.org/wiki/DEFLATE#Duplicate_string_elimi...
I could see this being an issue for a highly complex vector shape. But most shapes only consume a few bytes. Compared to an external image or another request for the font files.
We Atom community developers have used a lot of Octicons due to the github heritage. I hope the Atom developers provide some easy conversion utility like github used internally.
Icon fonts are awful. I'm glad GitHub made this change.
I see a bug in repository page: http://i.imgur.com/GdyeFXK.png
I see a bug in repository page: http://i.imgur.com/GdyeFXK.png
> We can animate them
> We’re not saying we should, but we could, though SVG animation does have some practical applications—preloader animations, for example.
FYI SVG animation is deprecated in Chrome 45 and later. You'll want to use CSS animation instead.
See https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_animati...
Main thing is now you can't animate SVG in 'before' or 'after' pseudoelements.
> We’re not saying we should, but we could, though SVG animation does have some practical applications—preloader animations, for example.
FYI SVG animation is deprecated in Chrome 45 and later. You'll want to use CSS animation instead.
See https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_animati...
Main thing is now you can't animate SVG in 'before' or 'after' pseudoelements.
Curious if they have any fallback for the very few browsers that can't render inline svg.
SVG support is nearly universal now: http://caniuse.com/#feat=svg -- plus, the icons aren't necessary for the UI to function, so perhaps they've forgone the fallback.
For example, the blind?
Well, in Github's case the icons always seem to accompany a label, which would already make the content accessible. SVG also provides descriptions and titles that can be read out by screenreaders. Icon fonts are 'hacked' in specific unicode characters and often screenreaders try to read these characters, leading to nonsense.
But to specifically enter the question: They hide the icons. The aria-hidden attribute makes sure that the icon is not seen by screenreaders [1].
[1] http://www.456bereastreet.com/archive/201205/hiding_visible_...
But to specifically enter the question: They hide the icons. The aria-hidden attribute makes sure that the icon is not seen by screenreaders [1].
[1] http://www.456bereastreet.com/archive/201205/hiding_visible_...
Icons kind of suck when you can just use text which is smaller and more descriptive. This is definitely an improvement over using webfonts for custom icons though.