Re: Some notes on SVG parsing in HTML 5

Hi Simon.

Simon Pieters:
> I thought I'd point out things that don't match my understanding of
> HTML5:

Thanks.

Cameron McCormack:
> > I’ve taken a brief look at the commented out SVG parsing language
> > in HTML 5. Below are some pertinent notes for ACTION-2395. Something
> > being a “parse error” means that the document is non-conforming.
>
> It also means that a UA has the choise to continue parsing (using the
> rules given in the spec) or to abort parsing.

Right.  (I think during discussions last week the SVG WG members were
aware of this.)

> > Parsing this document:
> >
> >   <svg xmlns='http://www.w3.org/2000/svg'>
> >     <circle r='100'/>
> >   </svg>
> >
> > as text/html would be non-conforming, since it doesn't begin with an
> > <html> tag,
>
> No, <html> is optional, but lack of a doctype is a parse error.

Ah, OK.  So that means the following document would be conforming:

  <!DOCTYPE html>
  <title></title>
  <svg xmlns='http://www.w3.org/2000/svg'>
    <circle r='100'/>
  </svg>

?

> (Lack of <title> is not a parse error but a content model error.)

OK.

> > Parsing this document:
> >
> >   <!DOCTYPE html>
> >   <html>
> >     <head>
> >       <title></title>
> >     </head>
> >     <body>
> >       <svg>
> >         <circle r='100'/>
> >       </svg>
> >     </body>
> >   </html>
> >
> > would be non-conforming, since the <svg> tag is missing an
> > xmlns='http://www.w3.org/2000/svg' attribute.
>
> No, xmlns is optional. If it is preset, it must have the right value,
> though.

Andi Sidwell just pointed that out to me, too.  I think I just misread
the relevant sentence in the spec.

> > SVG Tiny 1.2 elements aren't considered, and so <textArea> will
> > parse as an HTML <textarea> element and break out of foreign content
> > mode.
>
> <textArea> *could* be supported, though.

Yes, but currently not.

> > There's a comment <!--XXXSVG need to define processing for </script>
> > to match HTML5's </script> processing --> but I'm not sure what
> > processing this means.
>
> See: http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-incdata
>
> Basically, it says how to run the script in a way that is compatible
> with how browsers have to do it for HTML (in the face of, say, an
> external script that document.writes another external script that
> document.writes something).

OK, makes sense.

> > The following start tags cause a parse error inside foreign content:
> > b, big, blockquote, body, br, center, code, dd, div, dl, dt, em, embed,
> > h1, h2, h3, h4, h5, h6, head, hr, i, img, li, listing, menu, meta, nobr,
> > ol, p, pre, ruby, s, small, span, string, strike, sub, sup, tbale, tt,
> > u, ul and var.  <!-- this list was determined empirically by studying
> > over 6,000,000,000 pages that were specifically not XML pages -->
>
> They are not parse errors in <foreignContent>, <title> or <desc>,
> though. Anywhere else (in SVG) would cause the tag to escape back to
> HTML context.
>
> Example:
>
>   <svg> <title> <b>foo</b> </title> </svg>
>
> is parsed as expected (svg and title are SVG elements, b is an HTML element), but
>
>   <svg> <g> <b>foo</b> </g> </svg>
>
> is a parse error and is parsed as if it were
>
>   <svg> <g> </g></svg><b>foo</b>

Understood, that’s a useful distinction to draw.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 26 February 2009 02:04:29 UTC