Well, the future is here -- Apple is now shipping a laptop with a high-resolution 2880x1800 screen ("MacBook Pro with Retina display"), optimized for a sharper display at traditional screen sizes. I have one here on my desk and oh, is that screen beautiful. :)
We can reasonably expect such displays at laptop sizes to trickle down to other models and manufacturers over the next couple years, starting with power users and moving down to generic consumer machines. They're already standard on many smartphones and some tablets.
For now, MediaWiki takes limited advantage of high-resolution screens. In supporting browsers, text renders beautifully, but icons and images are low-resolution and can look blocky or blurry like in this image: < http://upload.wikimedia.org/wikipedia/mediawiki/a/a3/SF_infobox_in_lo%2C_mix...
Sharper maps and diagrams like this will be nice in content, but we have to fix our user interface images too!
Some general guidelines for anybody working on code that includes icons or images: * where possible, always create assets as SVG and generate the PNGs from the scalable original * INCLUDE THE SVG IN SOURCE CONTROL! * If SVG isn't suitable (say for a photo), create a double-size version even if you're not ready to use it yet.
We'll develop some best practices about how to switch in high-res versions and whether it's better to use the SVGs or double-sized PNG rasterizations. You don't need to use them now, just make sure the images are there when we're ready to use them.
If your code includes PNG or GIF assets that were made from SVGs but you didn't store the SVGs in source control, please try to find them and add them -- otherwise you or someone else will have to recreate them at some point. If you used a non-SVG format like Illustrator, slap those in -- they can be converted later.
Some older images don't have source versions (or were made pixel-by-pixel) and will need to be redrawn.
-- brion "living in the future" vibber
Le 18/06/12 22:28, Brion Vibber a écrit :
Some older images don't have source versions (or were made pixel-by-pixel) and will need to be redrawn.
And that topic, I am pretty sure we have a team on commons whole sole purpose is to vectorize bitmaps image.
Basic project page: http://commons.wikimedia.org/wiki/Commons:Transition_to_SVG
I am pretty sure volunteers there will be to help since they have years of experience in redrawing.
My concern are images inside articles, where a big screen user will want |500px but a small screen one |120px. Maybe we should move to a size specification dependant on the clientWidth.
On Mon, Jun 18, 2012 at 4:43 PM, Platonides Platonides@gmail.com wrote:
My concern are images inside articles, where a big screen user will want |500px but a small screen one |120px. Maybe we should move to a size specification dependant on the clientWidth.
That's really a separate issue, which is that a large portion of image uses in content should probably be changed; trade hardcoded sizes for galleries and priority markers, perhaps. And of course replace the crappy old link-to-image-page with a sensible click-to-zoom.
-- brion
On Tue, Jun 19, 2012 at 5:19 AM, Brion Vibber brion@pobox.com wrote:
On Mon, Jun 18, 2012 at 4:43 PM, Platonides Platonides@gmail.com wrote:
My concern are images inside articles, where a big screen user will want |500px but a small screen one |120px. Maybe we should move to a size specification dependant on the
clientWidth.
That's really a separate issue, which is that a large portion of image uses in content should probably be changed; trade hardcoded sizes for galleries and priority markers, perhaps. And of course replace the crappy old link-to-image-page with a sensible click-to-zoom.
I had once talked about this (click-to-zoom) feature on wikimedia sites in irc. Wikipedia could have something similar to sites like Facebook or Google+ where the images float over the page. I have tried an extension FancyBoxThumbshttp://www.mediawiki.org/wiki/Extension:FancyBoxThumbs which enables such a feature, with some enhancements it can be more awesome.
This also concerns me but luckily it's concerning others too. This is an interesting article here about the current state of adaptive images if you haven't read it: http://html5doctor.com/html5-adaptive-images-end-of-round-one/
On Mon, Jun 18, 2012 at 4:49 PM, Brion Vibber brion@pobox.com wrote:
On Mon, Jun 18, 2012 at 4:43 PM, Platonides Platonides@gmail.com wrote:
My concern are images inside articles, where a big screen user will want |500px but a small screen one |120px. Maybe we should move to a size specification dependant on the clientWidth.
That's really a separate issue, which is that a large portion of image uses in content should probably be changed; trade hardcoded sizes for galleries and priority markers, perhaps. And of course replace the crappy old link-to-image-page with a sensible click-to-zoom.
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Jun 19, 2012 at 1:43 AM, Platonides Platonides@gmail.com wrote:
My concern are images inside articles, where a big screen user will want |500px but a small screen one |120px. Maybe we should move to a size specification dependant on the clientWidth.
This is a concern seam carving planned to solve if we read or see again the original paper/video: http://www.faculty.idc.ac.il/ARIK/site/seam-carve.asp
Would it be useful to do seam carving in addition to rescaling or do you think it's not realist to request images contributors to test and when needed configure a seam carving mask on their picture?
Brion Vibber bvibber@wikimedia.org wrote:
- INCLUDE THE SVG IN SOURCE CONTROL!
(...)
We'll develop some best practices about how to switch in high-res versions and whether it's better to use the SVGs or double-sized PNG rasterizations. You don't need to use them now, just make sure the images are there when we're ready to use them.
One of possible solutions (cerainly not sufficient) is to ask browsers to send us image/svg+xml in their HTTP Accept: line.
Relevant Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=240493
got wonfixed in January 2012 after 8 years of discussion (good read!)
//Saper
One of possible solutions (cerainly not sufficient) is to ask browsers to
send us image/svg+xml in their HTTP Accept: line.
Relevant Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=240493 got wonfixed in January 2012 after 8 years of discussion (good read!)
That is actually really unfortunate. I feel like that would have helped a lot of people.
We could do what they suggest in Comment #87, but I feel like that is a hack and one that would require a great deal of maintenance, and would work for some of the more esoteric browsers.
Is there a good way to detect SVG support via Javascript? I'm not fond of this solution, but if we could detect SVG support via Javascript we could change all the images on the page out for SVG versions of them. Having little experience modifying the Mediawiki core though, I'm not sure how feasible this is.
I really think though SVG interface icons are the way to go for the future. Does anyone else have any ideas about how to check for SVG support?
Thank you, Derric Atzrott Computer Specialist Alizee Pathology
Is there a good way to detect SVG support via Javascript? I'm not fond of this solution, but if we could detect SVG support via Javascript we could change all the images on the page out for SVG versions of them. Having little experience modifying the Mediawiki core though, I'm not sure how feasible this is.
document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#BasicStructure", "1.1"),
wikitech-l@lists.wikimedia.org