RE: SVG Semantics Re: SVG and MathML in text/html

 
Chaals wrote:
 
>Allowing a new syntax would mean breaking compatibility with the 
>existing toolset - something that doesn't seem to have any justifiable 
>motivation beyond an assertion that people will suddenly start badly 
>hand-coding complex SVG graphics en masse, despite the evidence. (Yes, 
>people do hand-code it. I hand code the majority of my own SVG, and I 
>generally get it right. Where I haven't, losing the error correction of 
>relatively strict interpretation is more than enough reason for me to 
>prefer the strict handling to be maintained. I appreciate the portability 
>of code between existing tools and devices far more than I can ustify any 
>desire to be allowed to do sloppier work).

I agree. I also hand code my SVG  (because of inertia rather than idealogy). When I first started doing it,  IE/ASV was the only game in town. I was quite annoyed when I found later that the sloppier code that worked in IE/ASVdidn't work in Opera or FF. 
                Namespaces?!*? name-space-aware methods?#@!! setAttributeNS(null, x,y) !*#*! IBM360JCL ?!*!
Once I acquiesced to the terms of the actual spec (it took therapy), I did so with some confidence that as other browsers (Safari, Chrome, dotdotdot) started to support SVG, my content would indeed be portable. Given the current incompleteness of the SVG support in the lesser three (FF, Safari, Chrome -- though Webkit is moving very fast!) I'd be quite nervous about saddling the implementers with new requirements that they should handle sloppy code. Let's let FF, Safari and Chrome establish a solid footing (whence IE will follow -- I'll bet 2¢ they do) before kicking the footstool. Seems like we had a design principle that said something like "if it ain't broke..." (I forget how the principle goes, since it seems to fuzzy right in with all those others).
 
David
http://www.google.com/search?as_q=svg&as_sitesearch=.edu

Received on Sunday, 28 September 2008 13:27:51 UTC