svg4everybody maintenance and alternatives

[jonathantneal]

svg4everybody maintenance and alternatives

[jorenvanhee]

It is working for me. But I had some issues with it when I started using it. For instance to get it working in different versions of Android, IE8, and safari 7.

What I do now is:

• Add the ie8 version in the head with conditional comments
• Add the standard version before the closing body tag
• Change the version number of safari in the script (see my open pull request #39)
• Svg file name should be a valid id selector (must begin with a letter [A-Za-z]). (found this one 5 seconds ago)

I can't say I tested it in all the browsers, but it works for me in a lot of browsers :)

[rarkins]

@jonathantneal have you considered opening up for contributors?

You should all vote for Internet Explorer to support SVG external content. That's the only browser that still doesn't.

In the meantime there is #38 to fix the latest Internet Explorer in Windows 10 Technical Preview.

What #39 does is not too useful, we talked about it and I think the best way would be to also add a check for Version/7.0 and less to support certain Safari versions that reports AppleWebKit/537, but still lacks support.

Obviously checking the user agent is not too reliable. The best alternative is to allow the script for every browser no matter what.

The only hope is that browsers that lack support disappear. A realistic expectation for the old WebKit-based browsers, but Internet Explorer is here to stay with us for decades.

[jonathantneal]

I am open to contributors. Who would like to help?

@jonathantneal I think you should merge #48 first. The minified JS was not updated with the changes from 1b17243, so they lack support for the WebKit browsers.

[renestalder]

@jonathantneal according to the open pull requests, there are enough people who want to contribute.

[jonathantneal]

@renestalder, I hope so. I need people I can trust to review pulls and keep things in motion.

[davidhund]

Forgive me for asking but I am unclear on the current state of browser support.

For example: I am running into issues with Android 4.3 (AppleWebKit/534.30) and an older iPad iOS 5.11 with AppleWebKit/534.46.

Both seem to work when I inline the sprite.svg (so use seems supported) but not when the sprite.svg is external.

Could S4E fix the above so that I do not need to inline the sprite.svg? Or potentially use PNG fallbacks for these browsers?

@davidhund I checked Android 4.0, 4.1, 4.2, 4.3 and 4.4 and many other WebKit browsers and when they support SVG the script works as expected. A number of WebKit browser such as Safari 7.0 isn't supported though, see #39.

Other than that I think svg4everybody is unreliable, because it relies on the user agent and I wouldn't use it.

If you use SVG for icons you are much better off with Grunticon or any other solution that embeds the SVG in CSS.

[jonathantneal]

@Vorzard, does grunticon allow you to style the shapes and colors of an SVG via CSS? If not, I'd not compare the two. It's apples or oranges, since an SVGMap also reduces the requests.

@jonathantneal It's not apples and oranges, Grunticon 2.0 also offers the very same functionality as svg4everybody with their new loader.

[jonathantneal]

How does any solution that embeds the SVG in CSS allow you to style the SVG, say via a fill property targeting a class?

@jonathantneal That wouldn't work. I am talking about Grunticon's new loader that does the same as svg4everybody.

[renestalder]

@Vorzard Do S4E and grunticons loader do the same? Do they inlining the svg in HTML? I mean that's exactly what I want to prevent because I know this is possible and can be done very easy in different ways, as using php include or SVGInjector.

The whole thing with using SVG's <use> feature with external files is, that it's just perfect in the way you can still manipulate it and how it caches in the browser.

[davidhund]

@Vorzard @jonathantneal Thanks, so inline SVGMap's should work, but not externally linked ones?

My current use-case is simply having a convenient SVG sprite-map. I don't need to style icon parts. A.t.m. I am using inline SVG with fragment-id's and I would like to avoid inlining the complete sprite.

Considering the complexity of 'support' it would be awesome if we could compile a simple 'support table' for SVG Sprites, listing all the OS'es/browsers and their support for SVG (with S4E) with various use-cases. What do you think?

@renestalder Yes, both inlines the SVG in the HTML dynamically using AJAX. SVGInjector does the very same.

Caching is the same.

• With the AJAX technique the browser downloads the SVG sprite, caches it, then the script inlines it so it can be a part of the DOM.
• With external <use> references the browser downloads the SVG sprite, caches it, then makes it available as part of the DOM.

PHP include is something different. That inlines the SVG statically, so the browser must download it with every generated HTML file. That's not so good for caching.

@davidhunt Yes, inline SVG sprites work in all browsers that support SVG and SVG fragment identifiers. See http://caniuse.com/#feat=svg-fragment.

External <use> references are not supported by Internet Explorer and a number of older WebKit browsers, so external SVG files cannot be made part of the DOM.

I opted for inlining the SVG in CSS, and provide a limited number of variants of an icon by generating separate icons using SASS (compression takes care of the extra size). I also provide a font fallback for those older browsers. I can basically display vector icons in every browser from Internet Explorer 8 to Opera Mini using this method. Additionally I manipulate the opacity of some SVG icons to provide hover effect.