Re: SVG and MathML in text/html

Hi, Jeff-

Jeff Schiller wrote (on 3/11/08 10:51 AM):
> 
> Maybe you (or others on the WG) know the history behind integrating
> Xlink with SVG?  

Not well.  It was before my time.  My impression is that it was thought 
that the XLink spec would define the fundamental linking aspect of the 
Web to a whole host of XML languages, and that it would provide a 
semantic and incrementally richer linking model with each revision, 
without the dependent specs needing to change anything.  But then 
browser development took a hiatus for a few years, and the whole plan 
didn't live up to expectations.  It could still be fruitful, but the 
XLink spec would have to fulfill some specific need.  (It actually does 
have some cool stuff, like extended links, role, and arcrole.  Just not 
compelling enough for implementors, though, I guess.)


> It's weird that SMIL entities don't require special
> namespace declarations yet xlink: is required.  I guess that's because
> SMIL was designed to "be adopted" into a host language?  Or was it
> because SMIL came before XML namespaces?

Yes, that is odd, and unfortunate.  I think the answer is that it's a 
mixture of both design for a host-language scenario, and that it was 
done before NiX.

An unfortunate case is that @fill in SMIL means something completely 
different, with a different value set, than @fill in SVG, but is still 
in the null NS in SVG, just like other SVG attributes.


> Maybe some future SVG spec can "adopt" the xlink attributes directly
> and we'd be left with only the SVG namespace for pure SVG content?  It
> still leaves the issue of RDF or MathML or HTML content inside SVG, of
> course.

It's certainly possible.  It does carry with it the same problems of 
existing implementation deployment.


> FWIW, I wouldn't mind giving up the xmlns declarations on SVG.  Since
> I've been using it so long I have the namespaces memorized.  It's
> really not that hard to remember: XHTML, XLink are 1999, SVG is 2000.
> I end up looking up spec details on properties and attributes more
> often than looking those up.  I do recognize that not everyone will be
> able to do that.  What would be required to make the years optional in
> the namespace? :)

Interesting question.  The years, of course, are not strictly necessary, 
it's just a matter of datespace convention at W3C.  I couldn't find any 
restriction in NiX that limits a specification to a single namespace 
name, so a new edition of XLink could, in theory, define an additional 
"human-friendly" namespace name, like "http://w3.org/xlink". (It 
couldn't be "w3.org/xlink", because a namespace name must be a URI, and 
RFC 3986 requires the scheme part; amusingly, it could be 
"mailto:w3.org/xlink"... for Richard Stallman, perhaps [1]).  SVG could 
do the same, if it chose: "http://w3.org/svg".

In practice, that would require all the implementations that currently 
do the due diligence of string matching the namespace name to update 
their code, and I don't see enough of a win there, since most people 
probably use boilerplate.  Iff we were going to go that far, we might 
well consider allowing the user to forgo namespace declarations entirely 
for "known" namespaces (which perhaps the host language could define).


> On the other hand, I don't want to give up case-sensitive
> elements/attributes nor quoted attributes since those are much harder
> to correct when importing SVG snippets into a standalone document for
> editing purposes...
> 
> That's just my opinion, of course.

Not just your opinion.  There are many good reasons for not deviating 
from the syntax used in "canonical SVG".  Pragmatic compatibility 
concerns would be enough for me, but another is that I honestly think 
that unquoted attribute values would be ultimately more confusing to 
authors.

Consider:

<circle stroke-dasharray="3 5" ... />
<circle stroke-dasharray=3 ... />
<circle stroke-dasharray=3 5 ... />

The first two would be permitted with an HTML5 parser, the second would 
not.  What happens when I have an unquoted attribute value with no 
spaces, then change the value using script to have a space (as in the 
above)?  Since it's not at the parser level, it should be fine... but 
what happens when I serialize?  Are all unquoted attribute values 
quoted, or just those that have illegal values?  What happens if I'm 
using one of these legendary content generation tools that can't handle 
quoted values (as has been asserted), and I want to have the above 
value?  Am I out of luck?  Does it discourage the maintainer of that 
content generator to go to the trouble of adding quoted attribute values 
to that tool?

And what about a scenario like <a xlink:href=http://example.net/><circle 
... /></a>?  How is that handled?  Is the circle linked, or not?  I'm 
sure it's described in the HTML5 spec, but it wasn't clear.

What happens if I do accidentally create a parse error by forgetting to 
quote an attribute value that has a space?  As far as I can tell, parse 
errors give unpredictable results: "user agents must either act as 
described below when encountering such problems, or must abort 
processing at the first error that they encounter for which they do not 
wish to apply the rules described below."

So, it's not mandated that a UA follow the parsing rules... but if it 
doesn't, it has to halt and catch fire.  How is that less draconian?

Rather than the consistent and easy step of always quoting attribute 
values, the user now has to think about something that would normally be 
automatic.  Maybe it's just me, but that seems harder, especially to debug.


My first suggestion is that a UA simply hands the SVG snippet off to an 
XML parser.  If that's unpalatable, my alternate suggestion is that if 
an SVG element uses unquoted attribute values, the parser ignores that 
attribute and any subsequent attributes (quoted or not) and proceeds on 
to the end of the element, then continues parsing the next element 
normally.  So, with the following snippet:

<svg xmlns="http://www.w3.org/2000/svg">
  <circle cx="100" cy="50" r="25" fill=red stroke="blue" />
  <circle cx="100" cy="50" r="15" fill="yellow" stroke="blue" />
</svg>

You would see a yellow circle with a blue stroke on top of a black 
circle with no stroke.  That's well defined, and not particularly 
draconian.  And it's easy to understand.

Again, I'm not speaking for the SVG WG here, these are just my personal 
thoughts.


[1] http://lwn.net/Articles/262570/  (or perhaps 
mailto:lwn.net/Articles/262570/)
[2] http://www.w3.org/html/wg/html5/#parse0

Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Received on Saturday, 15 March 2008 13:59:12 UTC