- From: Robin Berjon <robin@berjon.com>
- Date: Fri, 27 Mar 2009 14:47:53 +0100
- To: Doug Schepers <schepers@w3.org>
- Cc: public-html@w3.org, Sam Ruby <rubys@intertwingly.net>, www-svg <www-svg@w3.org>
On Mar 26, 2009, at 02:09 , Doug Schepers wrote: > If people think SVG can be confusing now, what will they make of > that? How is that useful in the least? How does that make SVG more > "usable"? So you can contrive a confusing example — what does that prove? Here's an example in XML syntax: <xedcr:html xmlns:qazws='http://www.w3.org/2000/svg' xmlns:xedcr='http://www.w3.org/1999/xhtml' > <qazws:svg xmlns:fvtgb='http://www.w3.org/2000/svg' xmlns:yhnuj='http://www.w3.org/1999/xhtml' > <fvtgb:g xmlns:mikol='http://www.w3.org/2000/svg' xmlns:olpéà='http://www.w3.org/1999/xhtm l'> <ç1234:circle xmlns:ç1234='http://www.w3.org/2000/svg' xmlns:åœîøü='http://www.w3.org/1999/xhtml'> <πøΩ:animateTransform xmlns:πøΩ='http://www.w3.org/2000/svg' xmlns:ÒÔÓÏÎ='http://www.w3.org/1999/xhtml'> <mikol:rect xmlns:èéÇØ5='http://www.w3.org/2000/svg' xmlns:OOOOK='http://www.w3.org/1999/xhtml'> <robin:title xmlns:chump='http://www.w3.org/2000/svg' xmlns:robin='http://www.w3.org/1999/xhtml'></robin:title> </mikol:rect> </πøΩ:animateTransform> </ç1234:circle> </fvtgb:g> </qazws:svg> </xedcr:html> This is correct. It parses. If you toss in a few attributes, it even renders. There's an error in it, but it's sort of hard to dig it up. And the worst part is: this is not even a completely absurd example. In a lot of cases, if you use a DOM library to create your XML, you'll get something only slightly worse than the above (oftentimes your namespaces will be declared on every element). Have I conclusively proven to you that SVG's XML syntax is toxic and unreadable? No? Really? Why? Maybe because Proof by Example is a quantificational fallacy and you won't fall for it? And damn right you are. But then again, don't expect people to be convinced by your own use of such an ancient trick. > This severely decreases the learnability and usability of SVG in the > wild. My only hope is that the people who think SVG will be > commonly hand-coded are wrong, and that the vast majority of content > (both SVG and HTML) is done with script libraries or graphical > authoring tools, so that there is a minimum of misnested HTML+SVG > content propagated. If you don't think they'll be hand-authored, why care about the syntax? > I'm not trying to be negative. I genuinely hope that this helps > spread SVG. But I fear that it will have exactly the opposite > effect. Languages which are more tightly structured and tightly > controlled (such as Adobe Air and MS Silverlight), but which have > supporting infrastructures of authoring tools, commercial promotion, > and aggressive distribution networks will have the advantage that > they are dependable and intuitively predictable, while this makes > SVG less intuitively predictable, and failing that infrastructure, > makes it less attractive. Please excuse me while I go through the thesaurus looking for enough synonyms for rabid laughter to even think about my current state. Did you just call Silverlight "dependable" and "intuitively predictable"? Have you actually used the stuff? It is the most bizarre and baroque accumulation — I daren't say integration here — of technology that I've seen in a long while, and that includes LASeR and other crackpot get-rich-quick schemes from MPEG. The only thing that Silverlight has going for it at this stage is Microsoft's monetary reserves; if it weren't for that it wouldn't be anywhere on the map. Seriously, I started writing up a comparison of Flex and Silverlight not long ago, and I ended up only looking at Flex because I couldn't find enough to say about Silverlight that wasn't a joke. And that's from someone who's actually happy when Microsoft does something right. Where it comes to SVG's predictability and dependability, those could sure be improved but I really don't see how one syntax is better than another. Outside of contrived examples, the issues it has (which are globally no worse than other options) will just remain. > I think that the people who are arguing for this *particular* aspect > of error correction (closing elements, not the unquoted attribute > values, for example, which is relatively trivial) are familiar with > HTML structure and coding, but don't have enough experience coding > SVG content to realize how, for all but the most trivial uses of > SVG, this will not be useful behavior. I think I am relatively familiar with SVG coding. And I'm sick and tired that even in browsers that support SVG, I'm still seeing problems because the JS libraries that I want to use don't handle namespaces (and won't special case SVG), because the PHP code doesn't handle write out elements in XML, because I have to jump through XHTML hoops to get a pretty circle. Seriously, I've been working on coming up with a library of nice, useful, reusable examples of SVG+HTML — and there's a bunch of things that can be done that I'm sure end-users will love — but the amount of tinkering one has to do is still too big. We need to do better. > This gives casual authors just enough rope to hang themselves. Which is exactly how things should be. Attempts to prevent users from getting enough rope are generally misguided and their output broken. Just look at Java. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Received on Friday, 27 March 2009 13:48:36 UTC