W3C home > Mailing lists > Public > public-html@w3.org > March 2009

Re: SVG in text/html

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Thu, 26 Mar 2009 18:02:35 +0100
To: www-svg@w3.org, public-html@w3.org
Message-Id: <200903261802.35963.Dr.O.Hoffmann@gmx.de>
Henri Sivonen:
>It's not necessary to edit them manually when grabbing stuff from the  
>Web into an existing SVG editor. There's a Web service that does it  
>for you:

I think, this is basically a good example of completely corrupted
HTML - without a form around the textarea there is no action at
all - this provides simply no functionality - looks like a form but is
nonsense. I think, it would be much more effective to have a noticable
error management in 'HTML5' to tell authors to have a form attribute
around such a construction to send such things to a server sided
script to make such 'services' accessible instead of corrupting
SVG too with stupid rules how to interprete something like:

<pAtH D=M0 9Q -300-54 1700,13 z fiLL= uri(myFill) rgb(0,17%,255) PaTHlenGTH
=  +1800>
<set attribUTEname=FIll to=uri(yourFill) CurRentcoLOr begin=  17sdur  =20>
<circlE R=100>

Why to specify, what TITLE might be, whether it belongs to set, pAtH or svG?
Why to encourage authors to write such stupid things for SVG? It is already 
bad enough, that HTML is corrupted with all this nonsense - this should be
a strong indication, that this should not be allowed in other languages.
This is simply no SVG, therefore there is nothing to do with it.

On the other hand the SGML style of short tags is skipped in HTML5
because it was too complex? And wasn't the more strict notation of
XML introdruced to simplify the life of authors and implementors without
having thousands of possibilities anymore to write the same 
element/attribute and to parse the code much faster?

I cannot see the advantage for both the audience and the authors,
that such things are tried to be interpreted - it is simply a waste of
time to guess element names, attribute and attribute values if 
authors can note them correctly. It introduces unnecessary complexity
in specifications, with the results, that less authors will read them,
because they are not understandable or blown up with boring error
management no author wants to read. Obviously no one will be 
able to explain in a tutorial, why SVG in 'HTML5' is different from
that in a simple SVG document - and maybe no author really 
in interested to know, why it is the case and would be happy to
have the same rules for 'HTML5' as well for simplicity.
Received on Thursday, 26 March 2009 17:05:54 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:44 UTC