- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 04 Mar 2009 14:19:20 -0500
- To: www-archive@w3.org
- CC: www-svg <www-svg@w3.org>
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:32 UTC