Re: SVG in text/html

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