

Re: SVG and MathML in text/html

From: David Dailey <david.dailey@sru.edu>
Date: Tue, 11 Mar 2008 12:48:03 -0400
Message-ID: <SSFDNS01niSnRMWuLn500008edc@ssfdns01.srunet.sruad.edu>

Hi Doug,

I'm certain I don't understand all of the issues discussed at 
http://esw.w3.org/topic/HTML/SVGInTextHTML, but as someone who 
teaches SVG in the classroom, I very much agree with the notion that 
the ability to put SVG inline into HTML is very important from the 
learner's perspective. How its DOM would relate to that of the HTML 
I'm not quite clear, but here are some of my thoughts on the issue.

VML, bless its heart, had the advantage that once you did your little 
namespace hoopla-dance (uttering incantations that would have made 
the Honeywell GCOS manual writers downright gleeful) there you were 
in HTML with your vector graphics. They could dance on the <table>s 
and sniff the bitmaps: all in one common getElementById-happy-world 
holding hands with JavaScript and CSS.

SVG on the other hand had to live in a separate document, and had its 
own DOM (pronounced damn).

Now while big corporations with 18.3 kilostaff like to separate their 
webgoo into 8 different documents and let the people in marketing 
handle the CSS, while the programmers in the basement do the script 
(why do they always get the basement?) and the payroll folks handle 
the MySQL, and the folks across the street in the airy loft of that 
almost condemned building handle all the pictures, and the data 
mining division (inside an unnamed mountain) handles webforms, and 
the AJAX can be outsourced, faculty tend to put things all in one 
place, so that our users can see it all at the same time. It may be 
possible, but I have never seen an <object>, <embed> or <iframe> 
successfully filled with SVG content through script, unless an actual 
file referenced by that tag already exists.

At the current time, the recommended way of placing SVG content into 
HTML (namely <object>) does not work with script in IE/ASV. 
Cross-browser idiosyncracies about the parsing of the SVG DOM from 
within HTML exist, and interdocument communication between SVG and 
HTML is strained through reliance upon ambiguities in what is meant 
by "top" and getSVGDocument and contentWindow and contentDocument. [1]

If the same browser understands <html> with all its slang, 
imprecision and street-savvy, <xhtml> with all its regimentation and 
board-room formality, and <svg> with its dynamic bitmaps and filters, 
(oh and aren't there vectors in there too ? [2] ), then it seems as 
though getting it to flip into <svg> mode from whatever mode it was 
in earlier, should not require more than an extra conditional or two 
in the browser's parsing algorithm. (I know I'm exaggerating, btw, 
but I really don't see why it should be greatly complex). Contained 
in the SVG WG's draft above, is even mentioned the possibility of 
wrapping it in a <script> tag to hide it from naive eyes. Most 
browsers don't seem to fuss much anymore about having to disappear 
into JavaScript occasionally. So that would seem to be an easy 
workaround if nothing else works, though the number of possibilities 
articulated is high.

I concur with your analysis of why SVG was slow to catch on and with 
the assessment that it has now caught on (the number of Google hits 
on the search "svg" has expanded from 3.8 million to 18.9 million 
since February of 2005 as well as the 300 million cell phones 
estimated to be SVG-capable). Let's hope the HTML WG can do its very 
best to make it as easy as possible. The very concept of 
"web-applications" rather depends upon SVG being handy, at least from 
my point of view. If the HTML WG can't figure out a way to inline it, 
then can we at least require the user agents to handle embedding it 
and communicating with it consistently.


At 05:16 AM 3/11/2008, Doug Schepers wrote:

>Hi, Folks-
>I'm very glad to see this subject receiving serious attention in 
>this WG.  I'll have more to say in subsequent emails, but I just 
>wanted to note here that the SVG WG has also discussed this quite a 
>lot, and we prepared a list of use cases and possible solutions that 
>we intended as a conversation starter. I put them in the HTML Wiki, 
>for reference. [1][2]
>[1] http://lists.w3.org/Archives/Public/public-html/2007Dec/0013.html
>-Doug Schepers
>W3C Team Contact, SVG, CDF, and WebAPI

[1] Take a look at 
in different browsers and as served from either local drive space or 
a web server.

[2] http://wiki.whatwg.org/wiki/SVG_and_canvas  This would have us 
believe that there are vectors in SVG as well as all the other stuff. 
Received on Tuesday, 11 March 2008 16:54:29 GMT
