W3C home > Mailing lists > Public > public-html@w3.org > July 2008

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

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 24 Jul 2008 21:02:31 +0000 (UTC)
To: Erik Dahlström <ed@opera.com>
Cc: HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0807242033141.10848@hixie.dreamhostps.com>
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.

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:


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

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

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

> The SVG WG proposal says let it be treated as part of the SVG fragment, 
> which in the above example means that the <p> element by default will be 
> in the svg namespace.

...and not rendered. Yes, I understand; that's one of the problems. :-)

> Now, when an svg fragment is broken, the SVG WG proposal says do your 
> best to recover, but alas it's not possible to repair each and every 
> case of breakage. Not in this proposal, and not in the the previous 
> proposal made by the HTML WG.

Actually, the proposal I put forward _does_ repair each and every case of 
breakage that we found in a multi-billion document study.

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

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. There's nothing to break 
there. You _can_ break existing markup in existing pages that depend on 
today's error handling rules.

Limiting the syntax that can be used in text/html for SVG is far, far less 
of a problem than breaking existing pages.

> > 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. The SVGWG's proposal 
wouldn't make those cases work unless they had the correct xmlns="" 
syntax, which they often don't. 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.

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. I 
haven't, for instance, carefully read Henri's feedback or Andrew's 
feedback -- it may be that they have problem with the SVGWG proposal that 
are blocker issues, or it may be that their experience with the proposal I 
put forward shows that the SVGWG proposal is far better; I don't yet know. 
I hope that other vendors will also review both proposals and provide us 
with their technical feedback.

(Incidentally, what I call "my" proposal above was actually primarily 
based on the suggestions of an Opera employee; I didn't come up with the 
basic idea. Indeed my own proposals were pretty stupid and didn't actually 
end up working at all.)

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 24 July 2008 21:03:07 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:35 UTC