PNGs don't load reliably in IE 7, 8

[jonathantneal]

PNGs don't load reliably in IE 7, 8

[jonathantneal]

Thank you for reporting this issue so clearly. It makes the fix so much easier to verify.

I will get to it right away, if someone else doesn't get to it first.

[tseven]

My pleasure.

I noticed that most browsers will not render the PNG inside the <svg>.
If the svg was replaced with a <div> with a copy of any classes/id of the original <svg> then it would allow rending on the stock android browser etc. Also if a title attribute exists on the <svg>, it could be used as the title and alt attribute of the replacement PNG.

How do you feel about allowing a variable to be set outside (or passed to) the script to trigger the PNG replacement as well?

This way the user can conduct their own tests (with Modernizr etc) and determine when PNG replacement is used.

[tseven]

After a bit of testing, the following code works the best for me.
I've tested it on IE 7-11, latest FF, latest Chrome, latest Safari, iOS 7.x, 6.1, 5.0, Android 2.3.3+

I'm using Modernizr and jQuery's browser object to determine which fix to use.
Ideally we wouldn't need to sniff the user agent at all.

(function(document, CACHE, svgclippaths, IE9TO11) {
    if (!svgclippaths) {
        $(document).ready(function() {
                $('svg').each(function(index, el) {
                    var svg = $(this),
                        classes = svg.attr('class'),
                        id = svg.attr('id'),
                        title = svg.attr('title'),
                        imgSrc = $('use', svg).attr('xlink:href').replace('#', '.') + '.png',
                        img = $('<div class="' + classes + '" id="' + id + '"><img src="' + imgSrc + '" alt="' + title + '" title="' + title + '" /></div>');
                    svg.replaceWith(img);
                });

        });
    }

    var oldSafari = false;
    if ($.browser.safari) {
        var versionParts = $.browser.version.split('.');
        if (versionParts[0] <= 534) {
            oldSafari = true;
        }
    }

    if (svgclippaths && (oldSafari || IE9TO11)) document.addEventListener('DOMContentLoaded', function() {
        [].forEach.call(document.querySelectorAll('use'), function(use) {
            var
            svg = use.parentNode,
                url = use.getAttribute('xlink:href').split('#'),
                url_root = url[0],
                url_hash = url[1],
                xhr = CACHE[url_root] = CACHE[url_root] || new XMLHttpRequest();

            if (!xhr.s) {
                xhr.s = [];

                xhr.open('GET', url_root);

                xhr.onload = function() {
                    var x = document.createElement('x'),
                        s = xhr.s;

                    x.innerHTML = xhr.responseText;

                    xhr.onload = function() {
                        s.splice(0).map(function(array) {
                            var g = x.querySelector('#' + array[2]);

                            if (g) array[0].replaceChild(g.cloneNode(true), array[1]);
                        });
                    };

                    xhr.onload();
                };

                xhr.send();
            }

            xhr.s.push([svg, use, url_hash]);
            /* ie9 was complaining the element wasn't ready and stopped loading the elements
            older version of safari (think android) returned an empty string
            */
            if (typeof xhr.responseText != 'unknown' && typeof xhr.responseText != 'undefined' && xhr.responseText != '')
                xhr.onload();
        });
    });
})(
    document,
    {},
     !! document.createElementNS &&
            /SVGClipPath/.test({}.toString.call(document.createElementNS('http://www.w3.org/2000/svg', 'clipPath'))),
    /Trident\/[567]\b/.test(navigator.userAgent),
    document.createElement('svg'),
    document.createElement('use')
);

Updated test files

[jonathantneal]

@tseven, would you update to the latest script and test again? This may be resolved by e4628b2

[tseven]

That seems to have fixed it.

Do you have a more elegant way of testing if xhr.responseText is defined in the IE9+ fix? IE uses "unknown" and older Android versions use an empty string.

[jonathantneal]

@tseven as a matter of fact, there is, and it was changed to it 44c7e54