Re: What namespace features popular SVG tools really emit (ISSUE-37)

Hi,

before I kick off: Thank you, Henri, for supplying the list with your
results!

So now my 2c: Yes, it is anoying, if you have a completely nice SVG that
just misses some small attribute in the root and therefore ceases to be
displayed. I stumbled on that several times when looking at SVG produced
by scientific programs like older gnuplots.

_But_: The problems (from a view of a web developer) if rendering SVG is
allowed _without_ being in the correct namespace will get as worse as the
infamous browser sniffing DHTML thingies:

* You have to check, if the browser displays it

* What about the DOM? Do you then have to use getElementsByTagNameNS or
getElementsByTagName ("svg:svg") or what?

* XML extensions: <foreignObject> and <metadata> only are useful, if you
can use other XML stuff in them. How do you do that w/o namespaces?

So:

* DOCTYPEs are evil, because you can use the default ones only on a small
subset of SVG content and really have to mess around with DTD's  features,
if you want to get 90% of SVG out there valid.

* for embedding in HTML5, that was just mentioned, using something like an
<xml> tag (just like MS does) would be my choice. Embed your XML without
the DOCTYPE there and be happy. If you want to get it to be valid
HTML/SGML, you have two choices: Either the content of the <xml> will be
defined in the DTD (which you can do, since XML is a subset SGML), or,
also nice, declare <xml> as CDATA element and let the content be rendered
by something completely else.

Best,
Manuel

Received on Thursday, 4 September 2008 06:56:24 UTC