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

On Sep 4, 2008, at 09:54, Manuel Strehl wrote:

> 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

First, I'm *not* arguing that WebKit and Gecko should start displaying  
XML-serialized SVG without an explicit namespace declaration. However,  
the problem of having to check in the case of XML is already there  
when Opera behaves differently from Gecko and WebKit.

In the case of HTML5, the problem of having to check what browsers  
support SVG-in-text/html is inherent to the feature no matter how  
specified and implemented.

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

In the case of the commented out proposal in the HTML5 spec, the SVG  
elements end up in the SVG namespace and don't have prefixes.

Therefore, the DOM can be queried either with the *NS getters or the  
Level 1 getters. Both Level 1 and Level 2 setters would work for  
attributes other than XLink (and xml:*?). XLink would require Level 2  
setter. Creating elements would require the Level 2 *NS factory method.

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

The commented out proposal supports HTML and MathML in <foreignObject>  
based on hardwired contextual rules without namespace declaration  
syntax.

The commented out proposal doesn't support RDF in <metadata> but does  
support HTML <meta> elements as key-value containers there.

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

DOCTYPEs in XML are evil, but not for that reason. :-)

But the commented out proposal indeed has a problem when it comes to  
validation. It makes all the product-specific or metadata markup with  
colons non-conforming. It's not a good use of people's time if a  
validator tells people to take that cruft out. However, making it  
conforming would violate our DOM consistency design principle. Making  
it conforming without violating the DOM consistency principle (i.e.  
doing Namespace processing) would be dumb from the point of view of  
parser performance, parser code footprint and parser developers' use  
of time.

> * for embedding in HTML5, that was just mentioned, using something  
> like an
> <xml> tag (just like MS does) would be my choice.

I think that would be inelegant (regardless of name, <xml> or <ext>)  
compared to the commented out proposal.

> Embed your XML without the DOCTYPE there and be happy.

What about output from Illustrator that uses an entity reference as  
the xmlns value?

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

HTML5 isn't SGML. HTML5 validity isn't DTD-based.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 4 September 2008 09:55:06 UTC