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
>
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
