Re: Error handling for SVG and MathML in HTML

Thanks great Erik,

Essentially all I am asking for -- I'm not sure it's coming across as
clearly as I'd like -- is that when I write SVG markup it gets handled
consistently whether I paste it into text/html, xhtml or link to a
separate file. Whether it be xml errors or svg errors... I'd like to
avoid the situation where my objects are blue in one situation and
green in another; due only to different interpretation of the same
markup (by which I mean the same ASCII text; I do know it is not
strictly the same when delivered with different mime types for
instance).

What that consistent behaviour is, I'm happy to leave to others to decide.
And whether the situation actually is feasible, I defer to the wisdom of others.

cheers
Ben


On Wed, Mar 19, 2008 at 7:08 PM, Erik Dahlström <ed@opera.com> wrote:
> On Sat, 15 Mar 2008 15:52:44 +0100, Ben Boyle <benjamins.boyle@gmail.com>
>  wrote:
>
> > 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.
>
>  You need to separate XML errors from non-XML errors (e.g. errors in SVG
>  attributes). SVG Tiny 1.2 handles the latter in a "non-draconian" way, any
>  unknown attribute values means that it's treated as if the attribute
>  wasn't specified at all. SVG 1.1 says to stop rendering and give a highly
>  perceivable notification of error instead.
>
>  I think it's not up to the HTML spec to specify what happens if the error
>  occurs in the SVG itself, for example what happens if there are unknown
>  elements in unexpected locations in the svg, or how invalid attribute
>  values should be treated.
>
>  What's in scope for the html spec IMHO is to define how to produce the svg
>  DOM tree when found inline in an html document. Possibly also to define
>  what should be shown in case the SVG DOM tree is broken somehow, and to
>  define how svg fragments may interact with each other and with surrounding
>  HTML in the cases where that hasn't been defined in SVG.
>
>
>  > 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.
>
>  That's true, but then again it was never defined what should happen with
>  svg content found inline in an html document. For XHTML with SVG inline
>  the parsing rules are defined by XML, so that's pretty clear. However
>  there are aspects of what you can require of such CDI documents that
>  haven't been defined yet.
>
>
>  > 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.
>
>  Well, that's not exactly what Henri was saying.
>
>
>  > 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 agree that nothing should prevent you from using correct SVG fragments
>  inline in html.
>
>
>  > 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.
>
>  Canvas doesn't magically fulfill all the use-cases of SVG though.
>
>
>  > 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/
>
>  That doesn't define how to use SVG in text/html.
>
>  Cheers
>  /Erik
>
>  --
>  Erik Dahlstrom, Core Technology Developer, Opera Software
>  Co-Chair, W3C SVG Working Group
>  Personal blog: http://my.opera.com/macdev_ed
>

Received on Wednesday, 19 March 2008 10:40:26 UTC