Re: Wikipedia CTO speaks on SVG

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)
2) there are still differences between the quality of renderings
between the three major browsers supporting it (animation only
supported in one atm)
3) means of displaying SVGs in IE remain sketchy (unsupported plugin
from Adobe, the silent Renesis folks)
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):
  http://en.wikipedia.org/wiki/Svg ->
    http://en.wikipedia.org/wiki/Image:Bitmap_VS_SVG.svg (raster shown
despite the confusing URL) ->
      http://upload.wikimedia.org/wikipedia/commons/6/6b/Bitmap_VS_SVG.svg
(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.

Regards,
Jeff

On 1/17/08, David Woolley <forums@david-woolley.me.uk> wrote:
>
> ~:'' ありがとうございました。 wrote:
>
> > Perhaps someone with greater diplomatic skills than me could read and
> > comment on the enhancement bug:
> > http://bugzilla.wikimedia.org/show_bug.cgi?id=3593
>
> I think you are diluting your case there by campaigning for complex
> interactive SVGs as well as simple static ones.
>
> The only real issue I have with simple ones is that it is not just SVG
> that has title information in the image, even if very few  people use
> it, and that title information is not the same as alternative text
> (SVG's approach to that is to require text to XML text nodes, so that it
> survives stripping of tags, although that assumes a multi-namespace
> document, not an object/embed relationship, and that linear reading
> order is respected), and embedded title information doesn't help if the
> image is never fetched.
>
> (I would have liked static SVG to have become the standard way of doing
> line drawings in HTML a long time ago, but IE has blocked this, probably
> to keep vector diagrams limited to Office.)
>
> For complex images, I think there are many real issues relevant to
> Wikipedia.  Security and size are definitely issues, but also:
>
> - Wikipedia needs to work in multiple media, particularly print.
> - Original research is not allowed and very large dynamic SVGs are
>    likely to be original research, if they are not copyright violations.
>    E.g. a detailed map of the UK pretty much has to be produced by
>    collecting GPS readings (original research) or from OS maps (pretty
>    much certainly a violation of database copyrights (not US) and maybe
>    other copyrights.  Original research belongs in Wiki sources, not in
>    Wikipedia.  Machine readable source material should be linked, rather
>    than embedded.
> - All information must be traceable to sources, but there are no
>    standards for associating facts in complex animations with the list of
>    references, nor for identifying what constitutes a fact in the
>    presentation, so as to allow the equivalent of {{fact}} (a macro that
>    inserts [citation needed] and also flags the page for review) in text
>    documents (failure to adequately source is a big problem in
>    Wikipedia).  I don't think labelling the sources in the SVG source
>    code is enough; they should be obvious to normal users of the page, in
>    the same was as sources in text articles should be.
> - Material needs to be easy for any contributor to change, and for
>    complex SVG that needs to be below the level of simply deleting the
>    whole if you disagree with it.  This requires programming skills that
>    are not universal amongst Wikipedia editors.
> - Changes need to be visualized in a way that is easy to perceive; even
>    providing an SVG oriented file difference might not be enough, because
>    of the programming skills needed to see the results.  Without that, it
>    becomes difficult to locate subtle vandalism, point of view changes,
>    and well intentioned but wrong information.
>
> I did have some concern that you were trying to take control of user
> agent behaviour, but on closer reading, that didn't seem to be the case.
>   In this respect, complex interactive animations would require user
> interface standards developing, or a Wikipedia API to abstract them.  If
> someone did want to provide a complete SVG API, or even one that was
> standard except for client side rendering SVGs, the licencing of the
> source material means that they are free to construct their own web
> site. It should, even, be possible to fetch the revisable form material
> dynamically, although I expect that would be discouraged, as it requires
> CGI processing, whereas most normal page accesses are cachable.
>
> Up to now, most Wikipedia authors have maintained relative semantic
> purity to a surprising extent, so one shouldn't need to do too much
> interpretation of embedded HTML in order to retarget for something
> radically different from HTML, although you may have to re-write a lot
> of higher level macros.
>
>
> --
> David Woolley
> Emails are not formal business letters, whatever businesses may want.
> RFC1855 says there should be an address here, but, in a world of spam,
> that is no longer good advice, as archive address hiding may not work.
>
>
>

Received on Thursday, 17 January 2008 15:42:23 UTC