Re: HTML5 and SVG

Hi Erik.

Some comments of mine on these goals are included below.

Erik Dahlström:
> Extracting the goals from the SVG WG proposal[2]:
> 
> = SVG should remain XML when inline in HTML =
> 
> Possibly we should rephrase this based on the discussion at TPAC.
> How about: Non-wellformed SVG markup may be error-corrected according
> to standard HTML parsing rules,

That would need to be “Non-wellformed SVG markup must be error-
corrected …”, I imagine.

> but shouldn't validate (or in other words any fixups should be marked
> as parse errors).

So this would make any sequence of characters that is identified as an
SVG fragment and which isn’t a well-formed XML document to be invalid
HTML?  Certainly there are kinds of XML non-well-formedness that I agree
should result in HTML invalidity, e.g.:

  <div>
    <svg …>
      <g>
    </svg>
  </div>

It is likely that missing end tags here are a mistake.

Some others I’m not so sure about.  What about references to the built-
in character references that HTML defines, e.g.:

  <div>
    <svg …>
      <title>An illustration &mdash; a good one at that!</title>
    </svg>
  </div>

That seems to be useful.

Or attributes that don’t take either of the quoted forms:

  <div>
    <svg …>
      <circle cx=100 />
    </svg>
  </div>

Writing attributes in this form is common in HTML.

Is the argument that “we should require well-formed XML of the SVG
fragment in HTML because then we can rely on copying-and-pasting the
characters out into a well-formed SVG document” still a reasonable one,
if we make non-well-formed SVG content invalid HTML but still require
certain correction behaviour?

What is the underlying reason that we want SVG to remain XML when in
HTML?

> = Should be able to take a conforming SVG document and paste its
> contents into an HTML document and have it be the same DOM. =
>
>   There was consensus on this goal at TPAC[1].

I agree with this goal, to a point.  For example with:

  <div>
    <?xml version="1.0"?>
    <!DOCTYPE svg [
      <!ENTITY blahblah "x">
    ]>
    <svg xmlns="http://www.w3.org/2000/svg">
      <title>&blahblah;</title>
    </svg>
  </div>

I wouldn’t expect there to be a DocumentType node object as a child of
the Element node for the <div>, and neither would I expect the
&blahblah; entity to work.

Also, I wouldn’t expect the following to work:

  <!DOCTYPE html>
  <html>
    <head>
      <meta charset=ISO-8859-1>
      <title></title>
    </head>
    <body>
      <svg xmlns="http://www.w3.org/2000/svg">
        <title>中</title>
      </svg>
    </body>
  </html>

where “中” would be encoded with the bytes e4 b8 ad.

And I think we agreed that we needn’t handle prefixed elements or XLink
attributes with funny prefixes.

> = Should be able to take a conforming HTML document and copy the SVG
> fragment from it and paste it into a new file and that would be a
> conforming SVG document. =
>
>   Hixie disagrees with this goal[3].

Is this copying the bytes, or copying the characters?  (Characters
sounds more useful to me.)

I guess the underlying goal here is that we want it to be easy for
people to get standalone SVG documents from SVG in HTML, either just to
have it itself or to use it some tool (like an editor).

I do think it would be good if SVG fragments from HTML documents could
be copied out into a separate document and be conforming SVG documents,
but this is not always going to be the case (e.g. with encoding you
would still need to insert an XML declaration into the extracted SVG
document).  I think I would be happy if SVG tools supported extracting
SVG from HTML, or if there were any easy way to export the SVG fragment
(right-click → Save as SVG document…) or if other easy to use tools
could extract it, since that would satisfy the underlying goal.

> = Should be able to provide some sort of fallback mechanism for the
> SVG-in-HTML so that UAs that don’t know how to handle these SVG
> fragments will display the fallback. =

I agree with this goal.

>   I agree with Hixie that if there's an alternative way of providing
> fallback content then new syntax wouldn't be necessary. It is an
> important goal nontheless, and we should have it on the list.

Alternative to what?

> = Should allow for unrestricted growth of the SVG language by the
> SVG specifications (though those specifications should also take
> into account the idea that SVG will, going forward, be used more
> commonly in concert with HTML). This means that there would be no
> "white list" of allowed SVG elements in HTML. It also means that the
> SVG spec should be more careful about element and attribute names
> going forward. =
>
>   This is a fundamental goal that should definitely be high on the
> list. Hixie thinks it's not in conflict with the other goals.

I agree with this goal.  It is important not to have to update HTML if
we add an element.  But yes we would need to ensure that we don’t
introduce names that cause problems for SVG in HTML.

> = Should allow for SVG Fonts to be included in HTML, and ideally to be
> usable in HTML text. =
>
>   Not discussed yet AFAIK, but should be on the goals list.

I agree with requiring SVG <font> elements to work.  Having SVG fonts
usable by HTML text seems like a requirement for a different spec (like
CSS Fonts Level 3).

> = Should attempt to avoid breaking existing text/html pages. However,
> this must be balanced with the need for a clean, sustainable
> architecture. =
>
>   There's disagreement on the balance. Do we still want to push this
> goal? I think that having a clean sustainable architecture is good,
> but it's also a rather fuzzy goal.

It is a fuzzy goal, but obviously certain choices for SVG in HTML are
off the table since they would break many pages.  I don’t know that the
goal can be made any less fuzzy.  Perhaps with a given SVG in HTML
proposal we can ask if implementors if resulting changes to page
behaviour are acceptable.  Can Opera’s MAMA help us here?

> = Should specify a tolerant error handling model for the SVG content =
>
>   It may sound as if this goal is superseeded by the first goal above,
> so we might rephrase it: "Should require a tolerant error handling
> model for the rendering of the SVG content".

“Tolerant” also sounds fuzzy, so I’d like to know exactly what is meant
by it.  Examples could be:

  * Allowing a mismatching end tag to do the appropriate open element
    stack popping that is done with HTML elements
  * Allowing viewbox="…" to specify a view box
  * Allowing font-weight="BOLD" to specify boldface
  * Allowing <a href="…"> to give an SVG link destination

Also, why “for the rendering of the SVG content” and not general
behaviour?

> Please read and comment, we'll have this topic on the agenda for
> Monday next week.

I guess this’ll be Thursday now. :)

Thanks,

Cameron

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

Received on Tuesday, 9 December 2008 01:02:28 UTC