Re: SVG Feedback on HTML5 SVG Proposal

On Mar 11, 2009, at 02:31 , Dailey, David P. wrote:
> Then if someone posts that snippet of code on web pages and authors  
> start trying to use it in their cell phones, then cell phone makers  
> are going to have to build full-fledged HTML parsers into their  
> little hand held boxes to accommodate all the wild code, and that  
> defeats the value of SVG-Tiny.

No, it doesn't. The complexity in implementing SVG Tiny is not in  
parsing, even though it has happened that mobile implementers have  
used non-conforming XML parsers because that was simpler for them in  
mobile contexts. The most publicised such instance was Macromedia's  
implementation, but they weren't the only ones.

When SVG Tiny (and SVG in general) were initiated, using an HTML-like  
syntax was highly unattractive because no such thing was properly  
defined, which would have brought about massive costs in reverse- 
engineering, and acute interoperability issues. But that was then — we  
have to reassess those decisions for today's situation.

For one, one very important use case for SVG is inside an HTML  
document. That implies that SVG should look as natural and as local as  
possible, ideally completely, inside HTML. Furthermore, there is a  
shift in the type of people who use SVG. When it was only XML geeks  
and people who understood mobile constraints some things could be  
asked of the SVG constituency that are different from what can be  
asked from Joe PHP Hacker On A Deadline. Joe's smart but in a hurry,  
and anyway being smart he's also lazy. If it doesn't Just Work like  
HTML, then whipping out Flash, while annoying, will be simpler.  
Finally we are getting to a situation in which an implementer can grab  
a specification (or a library) that'll give him interoperable parsing  
in an HTML context. XML is a fine option for syntax-level  
interoperability, but it's not the only one and SVG has no reason to  
be married to it. SVG isn't about XML, or even syntax, it's about  
sassy, sexy, wicked cool graphics that make you go wow.

In other words:
  - when SVG is on its own, it can do whatever it pleases, use XML, or  
if sent as text/html use the HTML rules (but that's a separate thread);
  - when SVG occurs inside HTML content, it should follow as much as  
possible, ideally completely, the HTML rules. For one, it's just the  
polite thing to do. More importantly, anything else will make life  
harder for authors, for implementers, and as a result for SVG itself;
  - anything that makes it harder and less likely for SVG to be  
implemented and/or used on browser platforms is, basically, getting in  
the way of SVG's success and therefore needs to be eliminated promptly  
and discreetly :)


> If so, then I guess that dealing with Cartesian coordinates in the  
> x,y plane (the core concepts of SVG in a sense) is already complex  
> enough that requiring folks to nest parentheses properly is not too  
> much to ask

You have to realise that that's a recursive argument, which if  
followed basically entails that we can require pretty much anything  
from developers; which is obviously not the case.

Just think of the case in which you're trying to teach someone how to  
make web pages. You can say "if you put a <p>, you'll get a paragraph;  
and if you put a <rect>, you'll get a rectangle". That'll fly. But now  
you have to say "okay, so here you can do <p id=foo> but there you  
have to do <rect id='foo'>". How do you justify that? Learning the  
stuff is already mind-boggling enough (took me ages to figure what  
those "table" things were). Trying to teach the latter, from  
experience, the only thing you can tell your student is "yeah, so,  
don't pay too much attention to that sort of detail, the people who  
make those technologies, they're a bit daft sometimes".

No one cares about SVG. People care about putting pretty moving shapes  
in their web pages. That's what has to be easy.

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/

Received on Wednesday, 11 March 2009 14:22:14 UTC