Re: SVG and MathML in text/html

Hi, Maciej-

I'm taking this discussion to www-archive, since it affects a lot of 
groups and a lot of interests.  I'm BCCing related groups (HTML, SVG, 
MathML, CDF, XHTML2), but discussions should take place on www-archive. 
  (This is part of a couple of long threads that started on blogs and 
IRC, and were continued on public-html; I'd suggest that those 
interested in this review those threads. [1][2])

To broaden the dialog to other audiences, so I'm going to try to 
summarize the issue along the way.  Please correct me if I fall astray, 
or expand on points.  I'm going to talk about SVG, but many of the same 
issues may apply to MathML.

Maciej Stachowiak wrote (on 3/16/08 1:12 AM):
> 
> HTML has the feature of two serializations: a classic serialization that 
> is error-tolerant, and an XML-based serialization that has draconian 
> error handling. These have different costs and benefits, ultimately it 
> is a benefit to HTML authors that they have a choice. I think SVG 
> deserves to have this feature as well, there's no reason it should fall 
> short of HTML in this regard. Supporting SVG inline in text/html seems 
> like a good opportunity to add this feature to SVG.

There are 2 scenarios here: SVG inline (Compound Documents by 
Inclusion), and external SVG (Compound Documents by Reference).  Your 
proposal is that, in order to facilitate inline inclusion of SVG into 
text/html, changes should be made to other uses of SVG, including those 
intended for SVG-only UAs.  I'll ask you to detail what changes would be 
required, but the topic of hottest debate so far is the ability to use 
unquoted attribute values in SVG, when there are no spaces or other 
ambiguous characters.  This would look something like this:

   <circle id=circle_1 class="category1 medium" cx=75 cy=25 r=20 
fill=orange stroke=red stroke-dasharray="3 5" />

You characterize this as non-draconian error handling; for the purpose 
of authoring conformance, would this fragment indeed be in error (and 
therefor in need of error recovery behavior), or would this be legal 
syntax?


A counter-proposal is that SVG retain its existing serialization 
(meaning, among other things, that it would require quoted attributes), 
for inline (in both XHTML and text/html) and for external SVG documents 
(standalone or externally referenced).  I'm going to argue for this 
proposal, as a Devil's Advocate, but I'm actually open to any proposals 
that can be demonstrated as workable.


Given past author practice of copy-paste authoring, SVG that is written 
inline in HTML is unlikely to stay there exclusively;  it stands a very 
good chance of being extracted and reused, be it referenced as an 
external image, or as standalone content in a mobile SVG-only viewer, or 
pasted into a graphical SVG authoring tool.  Content that breaks from 
one UA to another is too brittle, and would fracture the SVG market. 
So, I agree with you here, that we shouldn't burden users, authors, and 
vendors with multiple non-interoperable serializations.


As you mention, there are indeed known costs to any change in the 
written form of SVG (the serialization), notably incompatibility with 
all existing SVG viewers, authoring tools, automatic generators, and XML 
processors up and down the entire toolchain in general.  There is an 
enormous infrastructure investment involved in an enterprise like this, 
which affects not just SVG and MathML, but XML in general, and which 
would require substantial costs in money, developer hours, and time to 
market.

On mobile devices in specific, this would require implementors to write 
a new parser (which has yet to be shown as practical on the Web in 
general, or with SVG in specific); this may not be a burden for Apple 
(or certain other desktop browser vendors), which has already invested 
resources in an HTML UA, but it would certainly be for multiple other 
mobile vendors (those not on the iPhone), who have a very large (in the 
upper hundreds of millions) existing SVG UA deployment, and this could 
have a substantial cost for them.

For desktop browsers, your proposed content would not work in the most 
widely deployed SVG UA plugin for Internet Explorer (the Adobe viewer, 
which though no longer maintained, is still the best and fastest overall 
SVG UA for browsers); again, I can see this being a benefit for Apple, 
but not necessarily for SVG.  If Microsoft were to pledge and deliver 
resources for adding high-quality native SVG support (at least as good 
as Firefox, Opera, and WebKit), this would certainly alleviate my 
concerns about desktop browsers.

With the XML serialization of SVG (the way it is now), authors are 
already able to do inline SVG in the XML serialization of HTML (XHTML); 
this works even in Internet Explorer using the Adobe viewer, by use of 
"XML data islands"... and in fact works equally well in text/html and 
XHTML (though it has to be served as text/html, a known problem in IE in 
general).


Since it's not clear what changes would have to be made to SVG, your 
proposal may or may not affect existing SVG content that is intended for 
insertion into text/html; that is, presumably content can be made that 
works in all SVG UAs, following the existing rules for SVG.  So, this is 
a neutral point... neither proposal would break existing content from 
existing SVG authoring tools and generators.  Still, it would be best to 
get feedback from known tool vendors that produce SVG, such as Inkscape, 
Illustrator, CorelDraw, GraphViz, Visio, and others (I'm probably 
forgetting someone major, sorry).


As far as I know, there has been no implementation of the HTML5 parser 
by a major browser vendor (though there have been test implementations 
by others).  The algorithm is relatively untested on the vast body of 
existing HTML content on the Web, and completely untested for SVG 
content.  I'm concerned that this is taking an unnecessary risk with 
SVG's future, in spite of its already growing appeal and popularity 
across a variety of platforms, since it is competing with similar 
proprietary technologies.  I argue that this is a bad time to be taking 
risks for what I see as a largely theoretical benefit to authors.

As I've stated before, in 8 years of active participation in the SVG 
community, I've heard no serious request for unquoted attributes; by 
contrast, I have heard many people extolling the benefits of the cleaner 
XML model in contrast to the more complex HTML legacy.  As it happens, 
SVG makes liberal use of spaces in attributes, much more so than HTML, 
so the analogies between the two are not quite accurate; the majority of 
SVG content uses not the basic shapes like circles, lines, rectangles 
and ellipses, but the more complex shapes represented by paths, 
polygons, and polylines, and those elements use attribute values most 
clearly represented by space-separated coordinate pairs.  It's not clear 
that there would be a substantive gain by authors in real-world content 
by excluding attribute value quotes.  Since SVG doesn't have the legacy 
content of HTML content's unquoted attributes, there is little need to 
extend the same rules to SVG as are necessary for HTML.

You state that "SVG deserves to have this feature as well" and that 
"there's no reason it should fall short of HTML in this regard" as if 
unquoted attributes are innately a clear benefit, rather than a burden 
that implementors of HTML vendors and authors have to put up with, 
because vendors have to deal with legacy content, and authors have to 
maintain content they didn't create; SVG authors have never had to deal 
with this before, and it's really not clear they want to.  You represent 
this as an authoring benefit, but I have not seen the evidence that this 
is something authors are requesting.  I may be wrong, but I'd like to be 
proven wrong, rather than take it on faith.

In summary, as I see it, my proposal works today in a larger number and 
wider variety of user agents, and imposes less burden on vendors, and 
arguably on authors.


Could you summarize all the changes that you would require for SVG UAs 
and authors to implement your proposal, and give the benefits and 
rationales for each?


[1] http://lists.w3.org/Archives/Public/public-html/2008Mar/0039.html
[2] http://lists.w3.org/Archives/Public/public-html/2008Mar/0124.html

Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Received on Sunday, 16 March 2008 15:19:01 UTC