Re: Error handling for SVG and MathML in HTML

On Sat, Mar 15, 2008 at 11:24 PM, James Graham <jg307@cam.ac.uk> wrote:
>  I don't think this meets the legacy content mangement system
>  requirement. Specifically consider a text/html blog that chooses to put
>  its content (potentially including user-entered content) inside a svg
>  foreignObject (to use filters or transforms on the content, for example)
>  so the embedding is html -> svg -> html. Your scheme would effectively
>  cause draconian error handling of the whole page in this case.

I meant that should never happen. Browsers already do a lot of work
recovering from HTML errors. I'd like them to focus on this... so the
instant an SVG/MathML error is found, the browser goes "nope, that's
stuffed, I'm not parsing it" and it immediately goes back to
recovering the HTML (from where it left off before the SVG/MathML
began).

Is this much different to parsing invalid markup that began with <object ... ?

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


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

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.

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

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:
http://www.w3.org/TR/SVG/
Unless there a loads of hobby authors asking for SVG/MathML in their
markup, we should recognise this request comes from developers who are
asking for real SVG.

This probably takes us back to the whole text/html is not xml and will
not play by xml rules. And my original point that if text/html is to
allow xml, I'd like to see it treated as xml (within that scope),
which requires draconian error handling (within that scope) but I
fully support the UA trying to parse the rest of the document -- the
HTML markup -- to produce something of value for the user. This puts
the responsibility squarely with authors to get their embedded xml
right, the same way they must get their jpeg/png files right. Stick to
HTML if you are risk averse.

My 2 cents on how I'd like xml and html to play together (if at all).

Received on Saturday, 15 March 2008 14:53:20 UTC