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

On Thu, 24 Jul 2008 23:02:31 +0200, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 24 Jul 2008, Erik Dahlström wrote:
>> >
>> > Well for instance if a page looks like the following (I'm doing this
>> > from memory but this is quite similar to some of the pages I saw in
>> > some of my research):
>> >
>> >    <html>
>> >     <head>...<head>
>> >     <svg xmlns="http://www.w3.org/2000/svg">
>> >     <p>Hello world
>> >    </html>
>> >
>> > ...then in today's browsers, the page would just say "Hello world".
>> > Now if we instead use the proposal that the SVGWG has put forward, for
>> > instance, the page would no longer say "Hello world", it would instead
>> > either show a blank page or say something like "tml>" or "html>",
>> > depending on exactly how we define where the XML parser fails.
>>
>> This is an example where the author clearly wanted to use svg, even if
>> it is authored in a broken way (or in this case to specifically be
>> broken I suppose). I don't think it's possible to avoid breaking at
>> least some broken examples :)
>
> 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.

> Note that the above example, while hypothetical, isn't atypical, and
> certainly doesn't suggest that the author had any idea what he was doing.
> I hope you looked at the examples I cited, such as:
>
>    http://www.laroseweb.com/calcs/fans.php
>
> I think there is no evidence whatsoever that the author of that page
> _intended_ to use MathML, despite the two <math> elements at the top of
> that page.

The SVG WG proposal mostly tries to deal with SVG content, not MathML, though it would be nice if they were similarly handled.

> As I understand it, the SVG WG proposal would change the
> rendering of that page by inserting '">' at the top of the page (assuming
> that the intent is for the XML parser to abort at the semicolon of the
> unknown entity -- the proposal wasn't clear on exactly where the
> well-formedness error would be detected). 

That's true, and of course that should be more clearly defined.

> Note also that this example only
> renders slightly badly with the SVGWG proposal (a couple of extraneous
> characters) because the entity isn't declared -- if it _was_ declared,
> then the proposal would swallow everything in the <head> of the document,
> including the <title>, the stylesheet, and the script, which would pretty
> much destroy the page. With the proposal I had put forward, the page would
> render as it does today.

Yes, as per the proposal the head section child elements would be in the mathml namespace by default if the second math element didn't have the entity there.

>> 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. Also since there are a number of XHTML+SVG pages that work fine in browsers today, why make them invalid HTML+SVG pages?

>> Or if it was preceeded by an element <metadata
>> xmlns="http://myown.com/data">?
>
> I propose not to support proprietary markup formats at all, which would
> cause that xmlns="" to be ignored and the <p> to still be an HTML <p>.

That was quite clear from the old proposal that the SVG WG did not agree with.

...
>> 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.

> 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))

...
> 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?
Or to say that only XML well-formed svg fragments in HTML can be displayed?

>> > That's an example of this proposal "breaking" a page -- the page would
>> > look significantly different in a browser that implemented the
>> > proposal than in a browser that did not, despite the page being
>> > written before the proposal existed.
>>
>> Right, but so would pages that would suddenly become correct with either
>> proposal. Would you consider that to be "breaking" a page too?
>
> In the case of MathML, there are a huge number of pages that today would
> begin to look better if the proposal that it currently in the spec (which
> doesn't look at namespaces) were to be introduced. 

Yes, the SVG WG proposal focuses mostly on SVG, not MathML.

> The SVGWG's proposal
> wouldn't make those cases work unless they had the correct xmlns=""
> syntax, which they often don't. 

It's rather uncommon in svg to not specify the correct xmlns.

> 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.

> Now having said all this, I haven't actually gotten around to seriously
> considering the SVGWG's proposal, or reading the feedback it's gotten.

Fair enough.

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Monday, 28 July 2008 17:29:36 UTC