On Mar 21, 2012 4:40 AM, "Bergi" a.d.bergi@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