Re: HTML5 and SVG

We discussed SVG in HTML a little at the 11/12/2008 telcon.  Here is a
summary of the points made distilled from the minutes, with my comments
in brackets:

  * Doug says that the goal “SVG should remain XML when inline in HTML”
    should be a consequence of the later, more high level goals listed
    in Erik’s mail.

  * Erik says that neither his nor my earlier mail captures exactly what
    we want from this goal, since there are certain kinds of XML
    non-well-formednesses that would be reasonable to allow in HTML.

  * Chris says that we shouldn’t be concerned about validity, just
    well-formedness.  (Although in HTML, the term “validity” covers both
    validity and well-formedness in the XML sense.)

  * Erik says that we want parsing fixups to be marked as parse errors.
    (I would like to know exactly what things would be classed as parse
    errors here and what would be allowable syntax.)

  * I say that we wouldn’t want to have any implied end tags, as that
    would restrict our ability to extend the language.

  * Chris says that for the “copying the XML SVG and pasting it into an
    HTML document” use case, there was agreement at TPAC that the author
    wouldn’t be copying the DOCTYPE.  (I assume that goes for the XML
    declaration if it exists, too.)

  * Doug says that until there are tools that understand SVG in HTML,
    authors will not understand how it exactly works (parses, etc.), and
    that we will need to educate authors on what different syntax is
    allowed in XHTML and HTML.

  * Chris says that entities are a “kind of transitional phase”, and
    that Unicode should just be used these days.  (I might disagree with
    that; I think many authors will continue to use entities because
    they are easier to type with a regular keyboard layout, and easier
    to remember than numeric character references.)

  * Anthony says that omitted attribute quotes are a bad idea because
    with SVG’s complex attribute syntaxes, it wouldn’t always be clear
    where the attribute value ends.  (I would say that this shouldn’t
    matter, and would require just the same amount of thought from
    authors as in HTML; i.e., if your attribute value has a space in it,
    then you’ll need to use quotes around it.)

  * Doug says that lots of attributes can take space-less strings, and
    that omitting the quotes here would be fine, and would be error
    corrected.  I wondered whether it was worth classing these as parse
    errors, since they are not parse errors for HTML elements.  Doug
    says that it should be a parse error to help people who are trying
    to do standalone SVG.

  * Doug raises a concern that people will have SVG-like files (i.e.,
    using the SVG in HTML syntax), which is served as text/html, and
    which will be confused with regular SVG files, and will be found not
    to work when loaded into an authoring tool.  Anthony says that an
    artist would understand “right click → save as, then open the file”,
    which could ameliorate the problem.

  * Chris says that if browsers do silent parsing correction that this
    will cause SVG files to exist that are not well formed and thus
    cannot be edited in standard authoring tools.  (Perhaps it’s just
    quibbling, but this would cause HTML files to exist whose SVG
    contents aren’t well formed XML.  I would expect content served
    as image/svg+xml to still be parsed with an XML parser.)

  * Doug says that the above point is why accepting non-XML syntax
    should be seen as a parse error rather than valid syntax, and that
    there needn’t be a visible indication of error in the content, but a
    log or a validator can point this out as a warning.  (Currently
    browsers don’t seem to log HTML parse errors in their error
    consoles.  I believe HTML parse errors are classified as errors and
    not warnings in the two validators that I’ve used (the W3C one and
    Henri’s one): do you still want to have these as a warning as
    opposed to an error?  I am not convinced that making non-XML syntax
    as a parse error will prevent the issue of proliferating non-XML
    SVG content.)

  * Doug says that he wouldn’t be surprised to see this kind of parse
    error correction in XML within the next five years.

  * Doug says that SVG requires quotes, and that he’s OK with no quotes
    being parsed as long as it’s acknowledged as error correction.

Please correct any of the above if I have misinterpreted the minutes.


Since that telcon, there was also the news that the HTML WG’s proposal
has been updated to allow SVG <font> elements, which is good news.

I think it might help the discussion if someone were to summarise the
characteristics of the HTML WG’s current proposal and send it to the
list.  We could then look at the concrete differences between our
current thoughts (which I believe aren’t written up, since the TPAC
discussions) and that proposal, so that we can find points where we
might converge.

I would still appreciate replies to my earlier mail
(http://www.w3.org/mid/20081209010141.GB25522@arc.mcc.id.au), as well as
this one.  IMO we should try to hash out the arguments over mail, rather
than during the limited telcon time, if possible.

Thanks,

Cameron
ACTION-2383

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

Received on Monday, 12 January 2009 00:17:52 UTC