Re: SVG in HTML5 draft proposal

On Jun 27, 2008, at 10:20, David Woolley wrote:

>>> When embedding HTML inside SVG, the HTML markup must be well formed.
>>>
>> I think requiring HTML to be well-formed inside or outside SVG in  
>> text/html is a bad requirement, since it would defeat a part of the  
>> value proposition that motivates SVG in text/html in the first place:
>
> I would say that anyone creating new HTML in SVG in HTML should  
> understand SVG well enough that they should not have difficulty  
> writing the nested HTML without unpaired tags, or for that matter,  
> writing the whole document in XHTML.

Perhaps they should, but:
  1) There's a large non-XML legacy of HTML-based CMSs and Web app  
UIs, and I think these systems need a path to benefiting from SVG  
without having to overhaul their existing HTML output.
  2) Even people who should be 'in the know' and competent  
consistently fail to create systems that guarantee well-formed output  
in all situations.

> As regards the common practice of cut and paste coding everything,  
> inside the outermost SVG element is, almost certainly, going to be  
> copied from someone who did create from new, and it doesn't matter  
> that the matrix HTML is tag soup.

What's "the matrix HTML"? The HTML content surrounding the SVG part?

Note that even though no browser ships with SVG-in-HTML5 yet, there's  
already cargo cult copy-paste cruft out there with partial SVG  
fragments in the middle of HTML for no apparent reason.

> Embedding SVG in HTML, for use by a browser that primarily supports  
> HTML, doesn't fundamentally require that the matrix HTML have  
> balanced tags, or even be valid.

Indeed.

> Where it matters in that context is if you wish to process the SVG  
> part of the file with tools that don't understand HTML. However, the  
> idea of having two different serializations of SVG is also in  
> conflict with such tools.


This has already been discussed on public-html.

Tools that only support standalone SVG documents will cough on either  
an XHTML or HTML wrapper, so compatibility with them is a red herring,  
since you'd need to go through a specific extraction step anyway.

Tools that would support SVG-in-XHTML would fail on any tiny ill- 
formed bit outside the SVG part, so any non-cooperating SVG-in-HTML5  
author could easily foil reuse either accidentally or on purpose. The  
robust way to address such legacy tools is to provide an HTML5 to XML  
converter that serializes the output of an HTML5 parser as XML. I  
intend to provide one with the next release of the Validator.nu HTML  
Parser.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 27 June 2008 13:38:39 UTC