Re: SVGWG SVG-in-HTML proposal (Was: ISSUE-41: Decentralized extensibility)

On Jul 28, 2008, at 20:31, Erik Dahlström wrote:

> In Thu, 24 Jul 2008 23:02:31 +0200, Ian Hickson <ian@hixie.ch> wrote:
>> The proposal I put forward (that Henri and Andrew implemented) would
>> render the "Hello world" text, so it's definitely possible.
>
> ...while breaking quite a bit of svg content, sure.

The proposal that is commented out in the HTML5 draft doesn't affect  
image/svg+xml processing. Arguments related to breaking arbitrary  
existing SVG content are, therefore, inapplicable.

The only arguments related to existing content that might be  
applicable are arguments related to text/html content authored for IE 
+plugin. In that case, it would be interesting to find out if IE 
+plugin solutions as XMLish as the SVG WG is proposing. So far, I  
haven't seen a description of how things work with IE+plugin.

>>> Try replacing the <p> in the example above with <a>. Now how would  
>>> you
>>> expect it to be handled (svg:a or html:a)?
>>
>> <svg:a>, because according to my research that mistake doesn't  
>> occur in
>> practice. (I did a detailed study of billions of documents to  
>> determine
>> what kinds of errors were most common, and designed the list of  
>> "bail out"
>> elements in the spec around that.)
>
> It would be interesting to know how many of those billions of pages  
> actually used any svg inline such that they warrant not supporting  
> namespaces for example. For some examples of svg content, maybe try  
> clker.com, or openclipart.org, and see how many of those images  
> could actually be used as is inline in HTML. Trying to inline the  
> W3C SVG testsuite is another rather good test, since it covers most  
> existing practices.

The proposal that is commented out in the HTML5 draft isn't supposed  
to cover the whole range of existing SVG syntactic sugar. It is  
designed to enable *a* way of putting SVG subtrees in text/html. It  
doesn't need to cover the whole range of XML syntactic sugar. It only  
needs to be compatible with existing syntax to the extent of making it  
feasible to leverage popular existing SVG drawing apps in content  
*creation*.

> Also since there are a number of XHTML+SVG pages that work fine in  
> browsers today, why make them invalid HTML+SVG pages?

Because those pages will continue to work as application/xhtml+xml,  
there's no need to migrate them over to text/html. On the other hand,  
not supporting the full range of XML syntax makes the text/html syntax  
simpler. Here we have an opportunity to avoid taking on some of the  
worst baggage of XML (Draconian error handling and namespace  
declarations).

> ...
>>> Furthermore, the number of valid svg:s that will break if XML  
>>> namespaces
>>> are not supported when SVG is inline in HTML should greatly exceed  
>>> the
>>> number of examples that use a broken mix of HTML and SVG.
>>
>> The SVGs that work today will keep working fine. We're not changing  
>> XML
>> processing. We're talking about adding an entirely new syntax in a  
>> totally
>> different MIME type.
>
> What you seem to be talking about is introducing a new syntax that  
> is incompatible with XML (and SVG). This is neither desirable nor  
> necessary.

The text/html wrapper around the SVG subtree will be incompatible with  
XML. On the contrary, I think trying to make the syntax match XML  
exactly is pointless and even contrary to the point of leveraging one  
of the salient advantages that HTML5 has over XML (non-Draconian error  
handling).

>> You can't "break" something that doesn't exist. Nobody successfully
>> includes SVG fragments inline in HTML (in the way the proposals  
>> here have
>> suggested) and has it work in browsers today.
>
> http://jwatt.org/svg/demos/xhtml-with-inline-svg.xhtml (supposed to  
> work in all major browsers (though IE needs the Adobe SVG plugin))

This example relies on an end-of-lifed product. That's not a  
sustainable basis for designing features. I tried the example with IE7  
and the latest Renesis Player on Windows XP SP3, and it didn't work.

I tried to search for SVG-in-text/html demos compatible with Renesis,  
but I couldn't find any.

> ...
>> Limiting the syntax that can be used in text/html for SVG is far,  
>> far less
>> of a problem than breaking existing pages.
>
> So, limiting SVG in HTML to only work when attributes are qouted for  
> example is not a problem?

It is a problem, because it makes the parser more complex than what it  
would need to be under the proposal that is commented out in the HTML5  
draft.

> Or to say that only XML well-formed svg fragments in HTML can be  
> displayed?

It is a problem, because it would miss the whole point of HTML not  
being disadvantaged by Draconian error handling (or namespace  
declarations).

>> If our goal is to make latent SVG and
>> MathML work in text/html, then the proposal currently in the spec  
>> does it
>> better than the SVGWG's proposal.
>
> I think what the SVG WG is trying to say is: the old proposal didn't  
> do a good enough job for SVG.

Actually, except for <font>, which should be fixable, the proposal  
that is commented out in the HTML5 spec does a remarkable good job for  
features that are defined in SVG 1.1 itself. What it doesn't do such a  
good job for is product-specific markup and metadata, but browsers are  
supposed to ignore those anyway.

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

Received on Tuesday, 29 July 2008 06:34:02 UTC