Re: Error handling for SVG and MathML in HTML

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

I understand this as "the HTML parsing approach is proven, has merit,
and SVG can benefit from it". Which is very possibly true (and applies
to any markup language), but I'd rather the W3C (at a higher level
than this group) or the SVG group endorsed such a direction, rather
than we make that decision.

I am assuming if there were broader buy-in, then other SVG tools would
over time also embrace the HTML style parsing e.g. I could open
text/html style SVG markup in Inkscape and reasonably expect it to
work. And that *could* work, if the parsing rules are defined.

I'm not interested in XML-based SVG winning so much as
consistency/compatibility across tools. The risk I see is the HTML WG
making decisions that relate to broader web architecture, without
support from other groups. I see potential pain for authors if
text/html UAs create expectations of things working, that don't hold
up elsewhere. Just don't need that extra confusion in my day thanks.

Get that broader buy-in on text/html parsing for SVG (not just in
html, but in any SVG document) and that I could support. But as others
have pointed out, there's a whole lotta legacy SVG out there that does
not work this way ...

(ps: I was safer not knowing that jpeg stuff! ;)

Received on Saturday, 15 March 2008 15:57:31 UTC