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

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.

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

Regards,
Maciej



Regards,
Maciej

Received on Sunday, 16 March 2008 23:36:11 UTC