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