Re: Error handling for SVG and MathML in HTML

On Sat, 15 Mar 2008 15:52:44 +0100, Ben Boyle <>  
> On Sun, Mar 16, 2008 at 12:02 AM, Henri Sivonen <> wrote:
>>  The *practical* correctness (as in "appears to work") of JPEG and PNG
>>  is defined by the Independent JPEG Group JPEG library and libpng. Do
>>  you know that these libraries never accept images that are wrong per
>>  spec?
> Not specifically, more that "images work because they follow
> standards" and that I can't just take a lump of data and serve it as
> image/png and expect that to work.
> Isn't SVG in the same boat right now? If your SVG is wrong per spec,
> then it's unacceptable. Most SVG renders will actually balk on them,
> in the draconian sense.

You need to separate XML errors from non-XML errors (e.g. errors in SVG  
attributes). SVG Tiny 1.2 handles the latter in a "non-draconian" way, any  
unknown attribute values means that it's treated as if the attribute  
wasn't specified at all. SVG 1.1 says to stop rendering and give a highly  
perceivable notification of error instead.

I think it's not up to the HTML spec to specify what happens if the error  
occurs in the SVG itself, for example what happens if there are unknown  
elements in unexpected locations in the svg, or how invalid attribute  
values should be treated.

What's in scope for the html spec IMHO is to define how to produce the svg  
DOM tree when found inline in an html document. Possibly also to define  
what should be shown in case the SVG DOM tree is broken somehow, and to  
define how svg fragments may interact with each other and with surrounding  
HTML in the cases where that hasn't been defined in SVG.

> If we parse "loose" SVG we will then be
> accepting images that are wrong "per spec", won't we?
> I define "per spec" in this instance as the SVG recommendations from
> W3C. I don't really understand how taking the view we focus on parsing
> text/html into DOM allows us to consider SVG-like syntax to be not
> only acceptable, but desirable.

That's true, but then again it was never defined what should happen with  
svg content found inline in an html document. For XHTML with SVG inline  
the parsing rules are defined by XML, so that's pretty clear. However  
there are aspects of what you can require of such CDI documents that  
haven't been defined yet.

> Are you saying we should define a variant of SVG that is specifically
> part of HTML5 and may not work quite the way that SVG does? (also for
> MathML). I do not support that approach.

Well, that's not exactly what Henri was saying.

> SVG (markup) parsing/rendering has never worked that way before.
> Image/object rendering in browsers has never worked that way before.
> HTML parsing in UAs *has* shown tolerance for poor markup, but that's
> a privilege we should reserve for HTML. If we are bringing elements
> from other languages into html for the purpose of defining text/html
> -> dom parsing, we should *try* to play by the rules and expectations
> of those languages, and aim for consistency with how existing
> applications that parse/render them, including consistent error
> handling.

I agree that nothing should prevent you from using correct SVG fragments  
inline in html.

> I don't want to see "SVG in name only" in HTML. If we can't implement
> SVG (as defined by the SVG specs), I'd prefer we leave it to the realm
> of xhtml. Restrict the text/html serialisation to "HTML only" ... give
> us canvas instead.

Canvas doesn't magically fulfill all the use-cases of SVG though.

> If you want to give me - an author - the ability to use SVG markup in
> my text/html, then give me SVG as defined here:

That doesn't define how to use SVG in text/html.


Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog:

Received on Wednesday, 19 March 2008 09:59:16 UTC