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

On Wed, 30 Jul 2008, Charles McCathieNevile wrote:
> > 
> > However, the assumptions that namespace prefixes are bad and that 
> > handling errors in a fatal manner is bad are both assumptions that we 
> > have taken as fundamental in the HTML5 work since 2003, based on 
> > careful studies of those issues at the time.
> 
> Indeed, Opera has consistently supported this approach to the 
> development of HTML since the paper you quoted, and continues to believe 
> that for HTML content this is generally the correct approach.

Glad to hear it. :-)


> > Only a radical shift in the way the Web works in the intervening five 
> > years would affect this conclusion.
> 
> Or a radical shift in what we do with HTML - such as trying to include 
> an existing body of work that doesn't have the same kind of legacy.

Actually, embedding MathML and SVG into text/html have been on the table 
as things we should consider since before the above paper was penned. 
Certainly it was considered when I helped co-write that paper at Opera.


> SVG is just such an inclusion, and in our opinion including it in HTML 
> justifies reconsidering the overall approach, at least for the specific 
> cases.

Why does embedding SVG affect the usability of prefixes? I'm confused.


> (I note in passing that at this stage we are not convinced about the 
> need for a general extensibility mechanism for HTML in the same way that 
> XHTML already has - it seems more sensible where there is a serious gain 
> in the offing to look at the specific case, as has been happening with 
> MathML and SVG).

Agreed. Indeed, that's one of the big features of XML; adding this to HTML 
as well would undermine one of the main reason for XML to exist.


> Let me spend a couple of paragraphs on examples. When we first 
> implemented SVG in the browser, we included strict namespace 
> requirements. Due to a small handful of customer requirements (important 
> to us as they were our customers) to support broken content, we actually 
> changed that pretty quickly and introduced some gentler error-correction 
> in a point update.

I recall; I was one of the strongest opponents of this approach at Opera 
at the time.


> Long ago in the beta process for Opera 9.5 (which has been commonly used 
> for SVG since its support is significantly advanced compared to Opera 9) 
> we went back to the stricter behaviour, which we have maintained in the 
> 9.5 and subsequent releases, with no outcry about the Web not working. 
> It is pretty clear to us that in practice SVG does work with the 
> relatively strict requirements of XML, and in particular with the XML 
> namespaces spec, and we see no good reason to break that.

Indeed, I don't believe anyone is proposing to change how XML-based SVG 
works. I myself have been a strong proponent of keeping SVG user agents 
compliant when it comes to XML and namespaces processing, despite the 
occasional opposition (e.g. the aforementioned namespace hack in an 
earlier version of Opera).


> This is a radical difference from the HTML world, and Opera believes 
> that this justifies working out how to continue to work with the 
> existing SVG world rather than breaking it for the sake of things that 
> have proven relevant to HTML but not to SVG.

I think I disgree with the premise of this opinion. SVG has so far enjoyed 
a very limited usage by an elite authoring base; there's no evidence, 
IMHO, that in the much wider world of HTML authors that it will continue 
to be written in the same reasonable manner.

However, to be honest, that's neither here not there. The primary issue 
that I originally brought up was to do with the handling of SVG in cases 
where authors are copying and pasting content from pages written to 
browsers that implement the new feature into pages written to browsers 
that do not. We already see examples of such content today, even before 
implementations exist; one can only imagine that this will get worse as 
browsers supporting SVG in HTML ship.

We have to make the syntax resilient to these authoring practices. For 
example, copying the <svg:svg xmlns:svg="..."> line from one document to 
another should not suddenly make a whole chunk of content disappear in 
newer browsers while leaving it in older browsers, something that (as 
illustrated in an earlier e-mail) does happen with the SVGWG's proposal. 
This is a fundamental problem that must be resolved.


> Whatever one thinks of "Draconian Error Handling" (and however you 
> choose to define it) or namespaces, it seems clear today that they 
> basically do not work in generic HTML content (in which generalisation I 
> actually include what people think of as XHTML 1.X content, including 
> things like XHTML-MP), and that they basically do work in pretty much 
> any other XML language. So if we try to bring these things together, we 
> are effectively walking into the radical shift that Ian asks for.

It's not at all true that namespace prefixes "work" in XML content. Indeed 
the quote I used in an earlier e-mail in this thread to support this very 
point was talking about XForms. People are fundamentally confused by 
prefixes whenever they are used (just look at the variety of sources that 
Henri used in his recent e-mail). Introducing prefixes is a bad idea.


> > If evidence to turn these assumptions around were indeed to come up, 
> > then this would have a massive effect on the HTML5 spec, and would 
> > probably put us back at least 6 months so that we could reengineer the 
> > spec to be designed with the new principles in mind.
> 
> It is true that this requires re-engineering, but any such large change 
> to the spec was always going to require re-engineering. Indeed, it would 
> be a little irresponsible not to spend some time thinking about how to 
> make such a change before wading in. Accordingly, we have spent a fair 
> bit of time both of standards people and engineers who write the code 
> thinking about this issue, in order to draw conclusions that we consider 
> justified.

If we think prefixes are a good idea, then the reengineering is much more 
than just adding SVG. We'd have to go through the whole spec making sure 
we used prefixes wherever we though them appropriate.


> The earlier HTML proposal would require a massive amount of 
> re-engineering from the SVG community, since it would produce a huge 
> inconstistency with more or less all existing tools.

This is a misunderstanding of that proposal; the proposal currently 
commented out in the HTML5 spec in fact supports raw XML as is, without 
modifications. Prefixes must be removed but that is a trivial 
substitution, and is not necessary in most cases anyway since most SVG UAs 
do not output prefixes. Importing SVG content straight from text/html 
requires new code in any case since no SVG UA supports text/html SVG 
import at all.


Anyway, as I've said before, I have yet to seriously and critically 
examine the SVGWG's proposal. I am hoping that the issues that Henri, 
Andrew, and myself have raised can be addressed before I do so.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 30 July 2008 00:57:21 UTC