Re: Wikipedia CTO speaks on SVG

On Thu, 17 Jan 2008 16:42:14 +0100, Jeff Schiller <>  

> I do agree that SVGs displayed directly in the article would be a good
> thing eventually.  However, I think I agree with the decision not to
> turn on SVG natively directly inside articles, their server-side
> rasterization saves client-side time/headaches:
> 1) rendering SVG is more expensive than rendering PNG (until vector
> graphic hardware acceleration gets to the desktop)

There are always cases where that isn't true, and it depends on if you  
count time it might take to transfer the files.

> 2) there are still differences between the quality of renderings
> between the three major browsers supporting it (animation only
> supported in one atm)

Do you have any particular examples that shows the quality differences?

> 3) means of displaying SVGs in IE remain sketchy (unsupported plugin
> from Adobe, the silent Renesis folks)

It's entirely possible to have fallback content.

> 4) stripping potentially maliscious code is not as simple as stripping
> script tags
> Plus, you can get to the native SVG just by clicking through a couple
> links (from article to image, from image to SVG link):
> ->
> (raster shown
> despite the confusing URL) ->
> (actual SVG rendered directly in most browsers)
> Also I had a question - does MediaWiki (the software that Wikipedia
> runs on) support displaying SVGs on the client side inside articles?
> I know I should probably ask this question elsewhere, but I was just
> curious.

I was actually trying out some mediawiki svg hacks like that a while back.  
I have to say though, I wouldn't like to have SVG (or arbitrary HTML for  
that matter) enabled without stripping away the scripts if I was running a  
wiki. And I agree with you Jeff, it may not even be that simple if you  
want to be on the safe side.


Erik Dahlstrom, Core Technology Developer, Opera Software

Received on Thursday, 17 January 2008 16:12:19 UTC