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

Re: Error handling for SVG and MathML in HTML

From: Henri Sivonen <hsivonen@iki.fi>
Date: Sat, 15 Mar 2008 16:02:39 +0200
Cc: "HTML WG" <public-html@w3.org>
Message-Id: <171DB71F-4B8E-43B4-AEB2-D44576D494B0@iki.fi>
To: Ben Boyle <benjamins.boyle@gmail.com>

On Mar 15, 2008, at 05:48, Ben Boyle wrote:

> I'm curious about the tension between the 'draconian error handling'
> of XML vs 'error recovery' in HTML. Many have already stated, the
> draconian approach is excellent for authors mastering conformance,

Mastering XML-level conformance is *very* rare, though. In the larger  
blog and IRC discussion around this topic, Philip Taylor has managed  
to elicit the YSoD with every user input-accepting XML-outputting  
system administered by the discussion participants.

> I expect the HTML document to be recovered, and that's my top
> priority. I expect the SVG/MathML to be rendered as an error, like a
> broken image/broken object.

This would be more complex than letting the rendering layer do  
whatever it would do with the same-shaped DOM parsed from XML or  
created by a script.

> If I referenced an image (jpeg, gif, etc.) that was broken, the  
> browser wouldn't attempt to render it.

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?

> Unless the SVG/MathML groups endorse more flexibility in the
> syntax, I don't believe we should second guess them.

I think turning a byte stream labeled text/html into a DOM is for this  
WG to specify. Please note that parsing a byte stream labeled  
application/xhtml+xml into a DOM is in the realm of the XML,  
Namespaces in XML and DOM Core specs--that doesn't belong in the SVG  
or MathML specs, either.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Saturday, 15 March 2008 14:03:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:53 UTC