- From: Doug Schepers <schepers@w3.org>
- Date: Sat, 15 Mar 2008 09:58:38 -0400
- To: HTMLWG Tracking WG <public-html@w3.org>
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