I've been fiddling with a new iPad, with its notoriously high-resolution display (2048x1536, roughly similar to the iPhone 4's earlier 2x resolution jump on the small screen but on something "real" sized). Text renders stunningly sharp. And you know what else?
SVG.
Graphics.
Look.
Totally.
Awesome.
On this screen!
I've got a little user script which replaces rasterized SVGs with their scalable originals: https://en.wikipedia.org/wiki/User:Brion_VIBBER/hidpi.js
even without fixing up any of the pure-raster images yet, this gives a visible improvement to pages containing maps, flags, site icons, etc which are often SVG.
Similar resolution screens will likely be coming to laptops sooner than later, so we should definitely start looking into making our UI and our images look awesome. (It'll also tend to help when printing or zooming in in the browser -- for instance zoom in on the tables at https://en.wikipedia.org/wiki/Olympic_Games#Host_nations_and_cities and you'll actually see the flags, not just blurry little piles of pixels.)
I've filed a bunch of bugs about low-resolution PNG and GIF icons in our user interface, under the high-density tracking bug: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=32101&hide_reso...
over time we should make sure that our UI is consistently scalable; using native SVG icons with fallback PNGs should do.
We'll have to do some experiments to determine a good way of doing fallbacks, deciding when to render things out fully, etc. It may make sense to have some per-image controls -- for instance files that are known to render very slowly we might prefer to serve as rasters; non-SVG drawings may also benefit from loading at higher resolution on high res displays.
Anyway, more fun stuff for people to think about. :)
-- brion
On Mon, 19 Mar 2012 17:30:24 -0700, Brion Vibber brion@pobox.com wrote:
I've been fiddling with a new iPad, with its notoriously high-resolution display (2048x1536, roughly similar to the iPhone 4's earlier 2x resolution jump on the small screen but on something "real" sized). Text renders stunningly sharp. And you know what else?
SVG.
Graphics.
Look.
Totally.
Awesome.
On this screen!
I've got a little user script which replaces rasterized SVGs with their scalable originals: https://en.wikipedia.org/wiki/User:Brion_VIBBER/hidpi.js
even without fixing up any of the pure-raster images yet, this gives a visible improvement to pages containing maps, flags, site icons, etc which are often SVG.
Similar resolution screens will likely be coming to laptops sooner than later, so we should definitely start looking into making our UI and our images look awesome. (It'll also tend to help when printing or zooming in in the browser -- for instance zoom in on the tables at https://en.wikipedia.org/wiki/Olympic_Games#Host_nations_and_cities and you'll actually see the flags, not just blurry little piles of pixels.)
I've filed a bunch of bugs about low-resolution PNG and GIF icons in our user interface, under the high-density tracking bug: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=32101&hide_reso...
over time we should make sure that our UI is consistently scalable; using native SVG icons with fallback PNGs should do.
We'll have to do some experiments to determine a good way of doing fallbacks, deciding when to render things out fully, etc. It may make sense to have some per-image controls -- for instance files that are known to render very slowly we might prefer to serve as rasters; non-SVG drawings may also benefit from loading at higher resolution on high res displays.
Anyway, more fun stuff for people to think about. :)
-- brion
CSS image fallbacks may be a little annoying. Last time I checked browsers don't consider "I don't understand that image filetype." an invalid url(). In other words in: background-image: url(foo.png); background-image: url(foo.svg); Every browser jumps to url(foo.svg) and the ones that don't understand .svg's choke.
I in css3-images image() notation was defined supporting fallbacks in such a way that we could use: background-image: url(foo.png); background-image: image(foo.svg, foo.png); Then older browsers would consider image() invalid and use the url(foo.png) with the png. While browsers with image() support would use image(foo.svg, foo.png) and following the rules for image() would use the .svg and if they don't support the .svg would fall back to the .png automatically.
Of course..... no-one has bothered to implement even basic support for image().
On Mar 19, 2012 8:44 PM, "Daniel Friesen" lists@nadir-seen-fire.com wrote:
CSS image fallbacks may be a little annoying. Last time I checked browsers don't consider "I don't understand that
image filetype." an invalid url(). In other words in:
background-image: url(foo.png); background-image: url(foo.svg); Every browser jumps to url(foo.svg) and the ones that don't understand
.svg's choke.
D'oh! I don't suppose @media queries can help with this... no doesn't look like it.
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.
Not ideal but should work, with the downside that non-JS browsers don't get svg.
-- brion
On Wed, 21 Mar 2012 00:57:03 -0700, Brion Vibber brion@pobox.com wrote:
On Mar 19, 2012 8:44 PM, "Daniel Friesen" lists@nadir-seen-fire.com wrote:
CSS image fallbacks may be a little annoying. Last time I checked browsers don't consider "I don't understand that
image filetype." an invalid url(). In other words in:
background-image: url(foo.png); background-image: url(foo.svg); Every browser jumps to url(foo.svg) and the ones that don't understand
.svg's choke.
D'oh! I don't suppose @media queries can help with this... no doesn't look like it.
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.
Not ideal but should work, with the downside that non-JS browsers don't get svg.
-- brion
Another theoretical option could be to try and coax the vendors into implementing it.
Add image() into our css and poke all the browser vendors saying that Wikipedia is going to be supporting image() to give it's ui high-quality graphics so they should implement support for it. Most of the relevant browsers should be ones which are on a short release period. So we could try it for a few months to give them time to go through the releases and see if it works.
The browser vendors seam to like everything that they can prance around with demos and high-traffic blog posts for and ignore smaller portions of css. But some of these smaller parts of css3 like image(), @supports, etc... are the really important parts of it. All these new features are near worthless when a number of designs and patterns cannot be done without proper fallbacks like css was intended to have.
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.
Not ideal but should work, with the downside that non-JS browsers don't get svg.
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.
Bergi
On Wed, Mar 21, 2012 at 11:39 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.
Not ideal but should work, with the downside that non-JS browsers don't get svg.
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.
What about the lowsrc attribute? Could we put the PNG into lowsrc, and the SVG into src?
Magnus
Magnus Manske schrieb:
What about the lowsrc attribute? Could we put the PNG into lowsrc, and the SVG into src?
That sounds promising, as even made for that use :-) Does anybody have experience with that attribute, and knows about browser behavior?
Bergi
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
On Wed, 21 Mar 2012 09:41:58 -0700, Brion Vibber brion@pobox.com wrote:
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!
I actually tried that once to see if it was possible to have jpeg2000 and a fallback image in the browsers that don't support it.
It doesn't work. Forget the warnings, it just doesn't work.
'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
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@pobox.com wrote:
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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
These css based tag solutions seem somewhat exotic and seems you need to do tricks to ensure one or the other assets are not loaded by the browser.
The mark up could take advantage of noscript something like: <noscript><img src="image path"></img></noscript> <scirpt> mw.outputPngOrSvg( 'NameOfImage.svg' ) <script>
Your outputPngOrSvg could document.write the png or svg to the page so you never wait for dom ready or simply define and close a div target prior to your small inline script if you don't like the document.write idea.
--michael
On 03/21/2012 06:13 PM, Daniel Friesen wrote:
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.
Michael Dale schrieb:
The mark up could take advantage of noscript something like: <noscript><img src="image path"></img></noscript> <scirpt> mw.outputPngOrSvg( 'NameOfImage.svg' ) <script>
<noscript> is not recommended to use. It even was broken in Opera 11, and there may be other buggy implementations.
Your outputPngOrSvg could document.write the png or svg to the page so you never wait for dom ready or simply define and close a div target prior to your small inline script if you don't like the document.write idea.
It's only not one inline script, but a lot of. Still horrible markup :~|.
Daniel Friesen wrote:
;) It's also a horrible markup hack.
Bergi
On 21 March 2012 17:41, Brion Vibber brion@pobox.com wrote: ..
'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
Why I can't be just something like this (withouth any noscript, script or document-write thing)? <img src="//foo.png" data-svg="//foo.svg">
Its because will not validate or some browsers will ate data-svg?
Brion Vibber wrote:
I've filed a bunch of bugs about low-resolution PNG and GIF icons in our user interface, under the high-density tracking bug: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=32101&hide_reso...
over time we should make sure that our UI is consistently scalable; using native SVG icons with fallback PNGs should do.
We'll have to do some experiments to determine a good way of doing fallbacks, deciding when to render things out fully, etc. It may make sense to have some per-image controls -- for instance files that are known to render very slowly we might prefer to serve as rasters; non-SVG drawings may also benefit from loading at higher resolution on high res displays.
Anyway, more fun stuff for people to think about. :)
Related: http://bits.blogs.nytimes.com/2012/03/21/ipad-web-retina/.
Like nearly everything else, it's a matter of cost vs. benefit. :-)
MZMcBride
wikitech-l@lists.wikimedia.org