W3C home > Mailing lists > Public > www-archive@w3.org > March 2008

Re: SVG and MathML in text/html

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 16 Mar 2008 11:14:25 -0700
Cc: www-archive@w3.org
Message-Id: <648C1BDB-2B1D-4BD6-8FD6-BD2180C634CC@apple.com>
To: Doug Schepers <schepers@w3.org>

On Mar 16, 2008, at 8:18 AM, Doug Schepers wrote:

> 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])

I disagree with moving this discussion to www-archive, since it is  
directly related to the discussion of allowing SVG in text/html that  
is happening on public-html.

> 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?

I don't see a proposal, a characterization, or indeed any reference to  
specific syntax issues in my remarks above. The rest of your  
discussion is all about unquoted attributes, which is something I  
didn't mention at all, and certainly not the same thing as tolerant  
error handling. But if you would like me to expand on my remarks, I'd  
be glad to do so on public-html.

  - Maciej

> 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 18:15:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:43:18 UTC