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

On Tue, 29 Jul 2008 12:18:19 +0200, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 29 Jul 2008, Julian Reschke wrote:
>> Henri Sivonen wrote:
>> >
>> > ... 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). ...
>>
>> You may call it "some of the worst baggage", I would call "some of the
>> biggest advantages".
>>
>> (Just trying to make sure that it's understood that there is no WG
>> consensus about the benefits or problems of these)
>
> It is certainly the case that not everybody agrees that namespaces and
> fail-on-error are bad features.
>
> 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.

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

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

> There's no point reopening that decision without evidence of such a
> radical shift.

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

As a point of contrast, Opera has committed a lot of effort in the last  
year or so to get ARIA changed so that it would work just as well in  
namespace-free HTML5 syntax as it would in namespace-based SVG syntax.

This discussion is and must be about what actually works, not what we  
would like the web to be in some theoretical ideal world. See the design  
principle "Solve Real Problems" (which is really an invitation to a lot of  
philosophical debate if it is not taken as a suggestion that maintaining  
consensus on requirements is crucial - especially in a project as  
long-term as HTML5 is currently stated to be by the editor).

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.

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

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.

Opera believes that incorporating SVG (and also MathML) handling in such a  
way that they are basically maintained as namespace-compliant XML  
vocabularies with common XML parsing, while HTML is treated with the  
handling of sloppy legacy that it requires, is in fact simpler, easier to  
implement and more likely to have a successful outcome than undertaking  
the effort required to completely rebuild the tool chains for those  
languages, from how-to books to authoring tools to browsers.

We have multiple parsers working on the same content already, for mixtures  
of HTML, CSS, Javascript, and XML, and at least three browsers have an  
actual SVG implementation based on the XML version of SVG, with MS having  
something similar (VML) although not based on a standard. Passing things  
 from one parser to another is something we have been doing for more than a  
decade. We don't think it is a big issue to do this. Authoring tools,  
likewise, have been mixing these languages with the various requirements,  
or specialising in one area or another. A substantial amount of work has  
been done on how these things work together, and on teaching people the  
differences between authoring HTML and authoring (any XML language).

We do not deny that there is more work to be done, but we feel that it is  
valuable to proceed in a way that preserves the existing SVG and MathML  
ecosystems while enabling richer content to be incorporated into HTML  
documents. We see it as a backward step to try and make HTML itself a  
super-format that effectively defines everything, and redefines existing  
things like SVG and MathML.

> In cases where there is no consensus, we need to pick a choice and go
> with it, or else we risk wasting years of time just going backwards and
> forwards on the issue, second guessing ourselves. Sometimes one agrees
> with the choice, and sometimes one doesn't, e.g. as I don't in the issue
> of including XML-like syntactic placebos in text/html. That's just the  
> way the chips fall.

Sure. But the first proposal for how to do this was, in Opera's view,  
unacceptably damaging to the SVG ecosystem. Something along the lines of  
the current SVG proposal is, in Opera's view, easier to implement,  
maintains the integrity of the SVG toolchain and ecosystem as well as that  
of existing HTML, and ths provides the right path where innovation doesn't  
break backwards compatibility in any significant area, and allows for  
clean development moving forward.

This is a W3C working group where we aim for consensus. That means  
carefully considering the technical arguments both ways and taking the  
time to arrive at agreement. (Yes, I am aware that Ian says he is  
disinclined to honour the commitment Google made when joining the working  
group and nominating him as a member. On the other hand where there is a  
reasonably clear technical consensus I have noticed that Ian has a long  
history of actually changing the spec as necessary to accommodate it,  
which is the practical goal of the W3C process. I am personally inclined  
to believe in reality over rhetoric).

It seems that the consensus has not yet been reached. But a few months of  
slippage in your multi-year schedule seem justified if we are going to do  
something as serious as this. It also seems like a very useful thing to do  
for the development of the Web. Racing down one path where there is a  
clear alternative and a clear lack of consensus would seem to qualify as  
"second guessing ourselves and wasting time just going backwards and  
forwards". I trust that we will continue to explore the issues and arrive  
at a technically sound consensus which will be reflected in the  
specification. I hope that this includes a sensible way to include SVG and  
MathML in everyday web content - something that has been sought for about  
15 years by many parties (including among many others all browser vendors).

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://www.opera.com

Received on Wednesday, 30 July 2008 00:11:59 UTC