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 <[email protected]> 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 <[email protected]> wrote:
On Mar 21, 2012 4:40 AM, "Bergi" <[email protected]> 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
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
