W3C home > Mailing lists > Public > public-html@w3.org > September 2008

Re: SVG Semantics Re: SVG and MathML in text/html

From: Charles McCathieNevile <chaals@opera.com>
Date: Sun, 28 Sep 2008 15:28:45 +1000
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.uh6et7gdwxe0ny@widsith.local>

On Mon, 17 Mar 2008 10:35:32 +1100, Maciej Stachowiak <mjs@apple.com>  

> On Mar 16, 2008, at 1:40 PM, Charles McCathieNevile wrote:

>> On Sat, 15 Mar 2008 22:12:34 -0700, Maciej Stachowiak <mjs@apple.com>  
>> wrote:
>> ...
>>> 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.
>> Perhaps. The cans of worms are different though. HTML elements are  
>> basically content - in principle, the text tree is reasonably useful  
>> (unless you have images). SVG is about images - having parts of an  
>> image not render can drastically alter the semantics ofthe image.
>> SVG has a mechanism for handling broken subtrees, which involves  
>> showing that it is broken.
> SVG has different rules for handling different kind of syntax errors:
> - Surface-level syntax errors (missing quotes on an attribute, text  
> encoding error, missing close tag): total failure to render the  
> document. This is not so much an SVG rule but an XML rule inherited by  
> SVG as part of the serialization.
> - Semantic syntax errors (bad attribute value, unknown attribute,  
> unknown element, dangling reference to another part of the document):  
> ignore only the erroneous construct and render the remainder of the  
> document with best effort. SVG used to be draconian about some errors of  
> this form of error as well, not only at parse time but even if such a  
> state were entered into via DOM manipulation, all rendering fails, but  
> that was abandoned.
> So <circle fill=red /> would result in the whole document not rendering  
> (YSoD), while <circle fill="redd" /> would result in the circle not  
> being filled (but if it has a correctly specified stroke, that would  
> render, and indeed the rest of the document would render).
> It's true that an unknown element name outside foreignObject results in  
> a subtree of the document that does not render, but this is not the most  
> common form of error handling in SVG.
> In conclusion, I think considerations of image semantics do not make the  
> case that only draconian syntax makes sense for SVG. I think both  
> choices, draconian and tolerant, should be available to authors and  
> tools.

This conclusion seems a little simplistic given the real world cases you  
outline. SVG has different kinds of error-handling for different kinds of  
error, and there is not some binary difference between tolerance and  
following draco - they are used to identify tendencies on a continuum.

>> Somewhere there might be a sweet spot that we can find with the SVG  
>> group. But it's not ust a case of "they should do as we do". (And I  
>> agree that the luxury of having the choice of a strict syntax is nice,  
>> and would hate to see that baby tossed out with any bathwater we may  
>> find in the requirement to be intolerant).
> The choice of strict syntax for SVG is already available, in the XML  
> serialization. What I'm proposing is that we add the choice of a  
> tolerant syntax as well, and use that in the text/html serialization.  
> Perhaps you are arguing that we should offer the option of intermixing  
> the tolerant serialization of HTML and the draconian serialization of  
> SVG.

Yes, very roughly speaking, that is what I am suggesting (modulo the idea  
that there are many levels of tolerance).

> Maybe that is a useful option, but it seems somewhat redundant if  
> all-tolerant and all-draconian forms of HTML+SVG are available. In  
> theory the following four combinations are possible:
> 1) HTML: Draconian   SVG: Draconian
> 2) HTML: Tolerant   SVG: Tolerant
> 3) HTML: Tolerant   SVG: Draconian
> 4) HTML: Draconian   SVG: Tolerant
> The first one is already available as XHTML+SVG. To add a tolerant  
> syntax option for SVG, I propose that we specify a form of #2. At that  
> point, I think #3 and #4 are too obscure to be worth adding.

Except that in the real world, there is no apparent demand for a lot of  
tolerance in SVG markup, and there is an ecosystem built on the idea that  
the extreme tolerance available for HTML is neither necessary or  
desirable. Indeed, the major failure errors in Wikipedia examples, as  
identified by Henri, are less common than the cataclysmic failure of the  
image to appear at all.

We believe that as well as being easier to implement (in browsers and  
authoring tools) the existing SVG language rather than some version of it  
that adds a whole new set of parsing requirements, the real-world problem  
of enabling people to hand-code rubbish isn't a serious issue in the SVG  
world. Given the relative scarcity of hand-authoring in SVG, tool coders  
become the most important authors of code, in terms of understanding the  
"priority of audiences" guideline that is sometimes tossed into this  

A substantial proportion of SVG already seems to be moved from one tool to  
another. Allowing a new syntax would mean breaking compatibility with the  
existing toolset - something that doesn't seem to have any justifiable  
motivation beyond an assertion that people will suddenly start badly  
hand-coding complex SVG graphics en masse, despite the evidence. (Yes,  
people do hand-code it. I hand code the majority of my own SVG, and I  
generally get it right. Where I haven't, losing the error correction of  
relatively strict interpretation is more than enough reason for me to  
prefer the strict handling to be maintained. I appreciate the portability  
of code between existing tools and devices far more than I can ustify any  
desire to be allowed to do sloppier work).



Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://www.opera.com
Received on Sunday, 28 September 2008 05:29:26 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:38 UTC