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