Re: Making it possible to use an <svg> root in text/html

Hi, Folks-

Sam Ruby wrote (on 3/4/09 10:04 AM):
> Anne van Kesteren wrote:
>> On Wed, 04 Mar 2009 23:31:24 +0900, Sam Ruby <rubys@intertwingly.net>
>> wrote:
>>> I may be wrong, but I don't think that's Henri's point. I think we
>>> can all agree that svg served as text/html should never be considered
>>> conformant.
>>
>> I, for one, would love to author a simplified version of SVG that I
>> can just put with text/html on my server, for what it's worth. (E.g.
>> not having to deal with namespaces, XML syntax nonsense, etc.)
>> However, I should note that if the root element does not actually
>> become <svg> my use case vanishes. (I mainly use SVG for images.
>> Though I guess you could change all the requirements for SVG as image
>> too, I do not think that would be a good idea.)
>
> If we wish to pursue that use case, I'd suggest <!DOCTYPE svg>. But I
> question that use case. I mean, what idiot would create svg using vi?
> Oh, wait. Let me rephrase that. :-)
>
> Is the set of people who are willing and able to create svg in
> notepad/emacs/vi/whatever *and* are sufficiently bothered by the need to
> add an additional 34 characters (including the space) as a talisman that
> it is worth paving this particular cowpath?
>
> As someone who does routinely author svg using vi and is very much
> concerned with optimizing the sizes of such files, I must say that *I'm*
> skeptical.

Based on my involvement in the SVG community these past 8-9 years, I've 
seen 3 common authoring cases:
a) hand-coded static content (for relatively simple SVGs)
b) script-generated dynamic interactive content (usually UIs of some 
sort, such as maps, charts, graphs, windowing systems), either custom 
script or reusing client- or server-side libraries or toolkits (Batik, 
Perl modules)
c) GUI-authored static content (art/diagrams done in Inkscape, 
Illustrator, CorelDraw, etc.)

There is often some mixture between those cases: (b) will have a basic 
static template done by hand (a), which is dynamically updated or 
supplemented (for example, a bar chart with static axes and background, 
or a map with static controls); (c) will have some hand-tweaking (a), 
such as adding links or other interactivity or cleaning up the code; (c) 
will be turned into something dynamic with (b).

Of these, (a) is probably the most common for developers learning SVG 
experimentally (getting the hang of the basics of the language), and the 
least common for production content; (a) is very uncommon for designers. 
  Very often, (b) will be an all-but-empty SVG file completely generated 
by client- or server-side script (with maybe a title and script element).

This is rather different than the distribution of authoring cases for 
HTML+CSS, which typically involve rather a lot of hand-coding of the 
markup itself (either from scratch, or touching tool-generated files). 
I suspect that this is because of a few factors, including: SVG has 
rather abstract (or rather, presentation-centered) semantics, and so 
abounds with TIMTOWDI; and more importantly, because SVG is more suited 
to represent real-world (or abstracted real-world) objects than HTML, 
and so tends to be more involved.  HTML initially set out to represent 
printed documents, and later the abstracted and blocky windowing systems 
of desktop applications, with lots of discrete bits and pieces; SVG is 
meant to allow curvier, less linear and text-oriented shapes and 
objects, where each bit is part of a more integrated whole.  Roughly 
speaking, of course.

So, it's natural that people accustomed to the HTML model and uses cases 
would seek to adapt SVG to the same set of constraints, but based on 
real-world use patterns, I don't think this is as pragmatic an approach 
as it is for HTML.  Aside from appealing to a relatively small number of 
erm... *dedicated* markup die-hards, I don't think it's worth investing 
energy in a fringe use case before we have the serious issues sorted out 
and implemented.  Maybe we could come back to this after 
SVG-in-text/html has been deployed and used to solve real-world 
problems, so we can get developer and designer feedback about how 
something like Henri's proposal would affect them.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Wednesday, 4 March 2009 19:19:30 UTC