Re: Error handling for SVG and MathML in HTML

On Mar 15, 2008, at 16:52, Ben Boyle wrote:

> How interleaved can SVG/MathML and HTML be? I may be missing a key
> point, but I imagine an <svg> tag starts an SVG context and there's no
> HTML in there until the svg finishes...

There can be nested foreignObjects.

> On Sun, Mar 16, 2008 at 12:02 AM, Henri Sivonen <hsivonen@iki.fi>  
> 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"

Well, you can't use all of the JPEG spec, for instance. You need to  
use the unencumbered profile supported by the Independent JPEG Group  
library.

I don't have concrete examples at hand, but the JPEG FAQ says "Most  
JFIF readers are also capable of handling some not-quite-JFIF-legal  
variant formats." (I have vague memories of some weirdness of how the  
initial format markers are arranged.)

People might expect Photoshop CMYK JPEGs to work. Is that following  
standards or not? Clearly, supporting CMYK is not part of the de facto  
*core* feature set. (I'm not sure if they are technically conforming  
JFIF files or a example of "not-quite-JFIF-legal variant formats".)

Anyway, JFIF in particular isn't all just happy standards. The  
Independent JPEG Group JPEG library is what sets the expectations of  
what "works".

> and that I can't just take a lump of data and serve it as
> image/png and expect that to work.

You can, however, take a JPEG image, serve it as image/png and expect  
it 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. If we parse "loose" SVG we will then be
> accepting images that are wrong "per spec", won't we?

For forward-compatibility, SVG renderers already have to be non- 
Draconian with DOMs that have unexpected stuff in them. So with the  
XML serialization of SVG, errors are treated with different severity  
depending on the kind of errors. It's isn't a boolean "per spec"/"not  
per spec".

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

I am saying we shouldn't vary the DOM level and above. I am suggesting  
that we define an alternative way of getting to the DOM, because  
failing to define it doesn't make XML-based SVG win--it just makes SVG  
as a whole lose by missing a huge opportunity.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Saturday, 15 March 2008 15:28:16 UTC