Yup. Browsers load images whether they are visible or not. (And there are
practices web developers use to make things better that rely on this fact)
So that would mean that every browser would unconditionally be loading
both a .png and .svg image for every single file. Additionally text
browsers and search engines would see two images in every image block and
could have side effects.
;) It's also a horrible markup hack.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]
On Wed, 21 Mar 2012 16:51:17 -0700, Yair Rand <yyairrand(a)gmail.com> wrote:
Anything that involves delaying images until DomReady
is probably not
going
to be regarded as an improvement. Would there be any problems with just
using something like this:
<img src="//foo.png" class="nonsvg [...thumbimage, etc.]">
<img src="//foo.svg" class="usesvg [...thumbimage, etc.]">
.usesvg,.client-svg .nonsvg{display:none;}
.client-svg .usesvg{display:block;}
?
On Wed, Mar 21, 2012 at 12:41 PM, Brion Vibber <brion(a)pobox.com> wrote:
> On Mar 21, 2012 4:40 AM, "Bergi" <a.d.bergi(a)web.de> wrote:
> > Brion Vibber schrieb:
> >
> >> Ooh! We may be able to handle this like the js/nojs styles.
> >>
> >> Have a bit of JS on startup check for svg support and add a class to
> the
> >> HTML root element. Then we just need .svg .foo {} entries with the
> svg
> >> background overrides.
> >
> >
> > Wouldn't that mean loading the png thumbnails, and then onDomReady
> replacing them with svgs? I think we really should deliver an output
> that
> lets the browser choose one of them, not one plus maybe a second to
> load.
>
> This'd handle CSS background images, and doesn't have to wait for dom
> ready
> because it operates on the document's root element - always available.
>
> I'm thinking something like this in mediawiki.page.startup.js:
>
> // Client profile classes for <html>
> // Allows for easy hiding/showing of JS or no-JS-specific UI elements
> var $html = $( 'html' )
> .addClass('client-js' )
> .removeClass( 'client-nojs' );
>
> // Check for client SVG support, since we can't reliably use multiple
> // images as fallbacks for SVG -> PNG in CSS
> try {
> var svg = document.createElementNS( 'http://www.w3.org/2000/svg',
> 'svg' );
> if (typeof svg.createSVGPoint == 'function') {
> $html.addClass('client-svg');
> }
> } catch (e) {
> // can't even create SVG element!
> }
>
> Should also double-check the assumption that supporting SVG this way
> means
> supporting SVG in CSS background images. (Within modern browsers
> supporting
> jQuery, it *should* but you never know)
>
>
> > Things in <img>s still need a reliable fallback that
> Still pondering best way to handle direct <img>s... ideally we'd use
> <object> but this'll probably trigger missing plugin warnings on some
> browsers, while we want to be nice and silent!
>
> 'Crazy' methods might include something like this inline:
>
> <script>document.write('<' + 'img
data-svg-src="//foo.svg"
> data-png-src="//foo.png">')</script>
> <noscript><img src="//foo.png"></noscript>
>
> and a DOM-ready-time fixup to set the 'src'. This feels ugly though, and
> delays start of image loading a bit (though we'd probably be loading
> styles
> mostly first?)
>
> -- brion