W3C home > Mailing lists > Public > public-html@w3.org > September 2008

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

From: Manuel Strehl <svg@manuel-strehl.de>
Date: Thu, 4 Sep 2008 08:54:58 +0200 (CEST)
Message-ID: <67782e092c0bf39675053ef2fd8a3d44.squirrel@ml11.de>
To: "HTML WG" <public-html@w3.org>, "www-svg" <www-svg@w3.org>


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

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?


* 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.

Received on Thursday, 4 September 2008 06:59:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:38 UTC