- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sat, 15 Mar 2008 17:27:31 +0200
- To: "Ben Boyle" <benjamins.boyle@gmail.com>
- Cc: "HTML WG" <public-html@w3.org>
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