SVGs might be better not in the HTML?

[AdamPS]

Recently there have been several articles with lots of clever ideas for other ways to handle SVGs. The key benefit I see is page-loading speed. I wonder if it would be worth improving RRSSB along these lines - well at least I can explain my reasoning and you can see what you think. It would not change the JS, would simplify the index.html, and move the corresponding SVG code to an SVG/CSS file.

Sorry this is a quite long...

Here are some articles describing alternative techniques:

• http://24ways.org/2014/an-overview-of-svg-sprite-creation-techniques/
• https://css-tricks.com/svg-sprites-use-better-icon-fonts/

The potential benefits in detail:

• Caching. If the user visits different pages (or the same page but it has changed), they are loading the same SVG HTML over again, whereas other techniques allow caching of SVG/CSS files.
• Duplication. On some of our sites, the front page is blog/news listing multiple nodes, with social buttons for each. In this case the page HTML contains the entire SVGs 5-10 times over!!!
• Server performance. The page generating program (Drupal in our case, or whatever) has to assemble the SVG HTML into each page, and if pages are cached (and perhaps they can't be - e.g. search results page, or if the user is logged in), the SVG HTML takes up cache space. If the SVG is a separate file, then it can be served directly by the web server (Apache or whatever), this is fast, and doesn't bloat page caches (server or client side).
• Code maintenance. It's great that you are active on this library. However every time you release a new version of index.html, all the library users need to run a series of steps to extract the relevant parts (typically converting into PHP or similar), swap the hard-coded URLs for parameters and so on. The Drupal module that integrates the library is significantly out of date for the SVG sections I think. Hence it would be great to have the minimum possible data in this file. CSS, JS, SVG files etc don't have this problem - library users reference these files directly in the form you ship them.

The articles I reference largely assume a requirement to be able to use CSS to style elements within the SVG. RRSSB appears to do that, but minimally (one line? {fill:#fff}). Maybe if that line were moved into each SVG, then the SVG files can be standalone. This way much simpler approaches would be possible, a bit like this site does: http://www.metoffice.gov.uk/public/weather/forecast/gcvwr3zrw. This is basically a bit like "SVG fragment identifiers", a little less neat, but much more compatible.

[joshuatuscan]

We did it this way so that the color of the icons can be easily determined by CSS. As far as I know that isn't possible with sprites or referencing external files. While we currently only have each icon being white, users of this project could potentially modify any piece of the SVG with CSS. This makes the project much more customizable. Also, I don't think some extra text in the HTML file is contributing to any performance problems. It is just text after all.

[dbox]

Hey @AdamPS, thanks for your thoughts!

Rrssb is extremely lightweight. The inline svgs are minified. IMHO performance/size is a non-issue, especially considering the tradeoff.

For now I'd prefer to stick with the svgs in the html for a few reasons:

• ease of installation: Not having to deal with actual image files is awesome, plus the new minified svg content makes copy/paste even easier.
• customization: As @joshuatuscan said. What you see out of the box is just the start of what you can do with rrssb. I should show a demo page of all the ease ways to customize it.
• File size tradeoffs - You mentioned svgs sprites, but that would require downloading all the icons at once, including several that you don't need to load. (Plus there are browser support issues with SVG sprites.)

If you still feel strongly about an "svgs as images" alternative, feel free to fork the project, and we'll be glad to link it up in the readme.

[connorwyatt]

As I recommended in another issue, maybe try using SVGInjector, then you can use AJAX requests to get your SVGs and it is quite a small and simple js library :)

[connorwyatt]

@dbox Would you like to see this in 2.0? I am putting the html in the js file but I could use ajax to load the icons? What do you think?

[dbox]

I think it'd be much easier to implement without having to deal with images and image paths, plus we lose some of the customization.

[connorwyatt]

So you think we should hard code them in rather than ajax loading them?

By the way when I say ajax load I just mean that you would put in the options iconLocation: "/images/rrssb/" for example, and then the icons would be in that folder and the script would load them from the icons folder.

If you want to change the svg you can just alter the svg file and it will be loaded with the changes next time

[dbox]

I know but you can't recolor them via css if they are linked images ...
On Thu, May 21, 2015 at 8:48 AM Connor Wyatt [email protected]
wrote:

So you think we should hard code them in rather than ajax loading them?

By the way when I say ajax load I just mean that you would put in the
options iconLocation: "/images/rrssb/" for example, and then the icons
would be in that folder and the script would load them from the icons
folder.

If you want to change the svg you can just alter the svg file and it will
be loaded with the changes next time

—
Reply to this email directly or view it on GitHub
#103 (comment).

[connorwyatt]

You can, you just inject the raw html so it is svg elements

If you just use image tags with the image path as the src then you can't though

[dbox]

But maybe this is super rare use case. And if someone wants to recolor then
they do so in the actual svgs....
On Thu, May 21, 2015 at 8:50 AM Daniel Box [email protected] wrote:

I know but you can't recolor them via css if they are linked images ...
On Thu, May 21, 2015 at 8:48 AM Connor Wyatt [email protected]
wrote:

So you think we should hard code them in rather than ajax loading them?

By the way when I say ajax load I just mean that you would put in the
options iconLocation: "/images/rrssb/" for example, and then the icons
would be in that folder and the script would load them from the icons
folder.

If you want to change the svg you can just alter the svg file and it will
be loaded with the changes next time

—
Reply to this email directly or view it on GitHub
#103 (comment).

[connorwyatt]

Fair enough, I'll leave it out then?

[dbox]

May need to hear @joshuatuscan's thoughts, but I think I might be having a change of heart on this issue based on the new plugin style call referenced in #49.

In the current setup, you manually include or exclude <li>s, which means the browser wont load unused icons.

The 2.0 setup reverses this though. If svgs were hard-coded, the JS would have a lot of unnecessary icon bloat right? Vs images which would only be called if needed.

I also think ~99% people use the defualt icon settings, so losing the ability to recolor the actual icon via scss is maybe not the worst thing. (Someone could still do it via the actual icons.) And everything else is still customizable.

[connorwyatt]

Yeah you're right, the icons would have to be in the js file if they arent loaded by ajax.

You wouldnt lose the ability to style icons though by using ajax to include them, they would still be svg elements in the dom rather than an img tag.

On my site http://connorwyatt.io, which has just gone up so I can show you, the logo in the top left next to Connor Wyatt is injected via ajax and if you add look at the css, the colour is determined by a css rule

[dbox]

Wait, you're saying you can ajax-load the inline svgs?

[connorwyatt]

Yeah exactly :)

On 21 May 2015, at 15:49, Daniel Box [email protected] wrote:

Wait, you're saying you can ajax-load the inline svgs?

—
Reply to this email directly or view it on GitHub #103 (comment).

[dbox]

So in this scenario:

• No extra icon bloat
• Icons still editable via css
• No need to bother with an image folder

Correct?

[dbox]

Or you'd still have to have the image folder, but the ajax would just be referencing it and writing it out as inline?

[connorwyatt]

Exactly because you can:

• Leave the SVGs in files.
• They are still inline so CSS rules still work.
• You could load the SVGs either from a CDN (e.g. GitHub), or from a folder in the site if you prefer (e.g. the bower_components folder or in the images folder). You could have a choice between local or CDN SVGs then.

[connorwyatt]

Yeah exactly but you could have a CDN if you wanted because github allows you to access the raw files like this: https://raw.githubusercontent.com/kni-labs/rrssb/master/icons/facebook.min.svg

[connorwyatt]

You would have to keep the icons the same though or the users' links would break

[connorwyatt]

Up to you which you think is best

[connorwyatt]

I don't know whether that would be disallowed due to same domain issues though?

[dbox]

So, one of my main arguments before to not linking to the SVGS, was, in the current setup you don't even need the images in your folder structure.

But now, the tradeoff boils down to:

Ability to change the white icon vs css
vs
Slight performance issues listed above by @AdamPS (mostly when used for multiple instances on one page, which also is rare)

Correct?

[connorwyatt]

Kinda but there is no tradeoff because you can still style them with CSS and you get the performance benefits

[dbox]

But not the caching right?

[connorwyatt]

I think you would still get the caching because ajax has a setting to turn it off with jquery: http://api.jquery.com/jquery.ajax/ - Look for the cache setting

[dbox]

Okay, perfect.

[connorwyatt]

Awesome I'll write that in then :)

[connorwyatt]

I'll use the 2.0 thread from now on

[AdamPS]

Great, thanks guys!