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

Re: SVG Semantics Re: SVG and MathML in text/html

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 29 Sep 2008 17:12:36 -0700
To: Charles McCathieNevile <chaals@opera.com>
Cc: James Graham <jg307@cam.ac.uk>, "public-html@w3.org" <public-html@w3.org>
Message-id: <64B63B36-F79F-42A1-9327-C43B5B263D60@apple.com>

On Sep 29, 2008, at 4:27 PM, Charles McCathieNevile wrote:

> On Mon, 29 Sep 2008 03:21:36 +1000, James Graham <jg307@cam.ac.uk>  
> wrote:
>> Charles McCathieNevile wrote:
>>>> Maybe that is a useful option, but it seems somewhat redundant if  
>>>> all-tolerant and all-draconian forms of HTML+SVG are available.  
>>>> In theory the following four combinations are possible:
>>>> 1) HTML: Draconian   SVG: Draconian
>>>> 2) HTML: Tolerant   SVG: Tolerant
>>>> 3) HTML: Tolerant   SVG: Draconian
>>>> 4) HTML: Draconian   SVG: Tolerant
>>>> The first one is already available as XHTML+SVG. To add a  
>>>> tolerant syntax option for SVG, I propose that we specify a form  
>>>> of #2. At that point, I think #3 and #4 are too obscure to be  
>>>> worth adding.
>>> Except that in the real world, there is no apparent demand for a  
>>> lot of tolerance in SVG markup, and there is an ecosystem built on  
>>> the idea that the extreme tolerance available for HTML is neither  
>>> necessary or desirable. Indeed, the major failure errors in  
>>> Wikipedia examples, as identified by Henri, are less common than  
>>> the cataclysmic failure of the image to appear at all.
>>> We believe that as well as being easier to implement (in browsers  
>>> and authoring tools)
>> Is there any evidence for the assertion of "easier to implement".
> Our conclusion is that something more like the SVG-WG proposal and  
> less like the original proposal incorporated in the spec (we're not  
> convinced that it is perfect yet, but they are also waiting on Ian's  
> feedback in particular) will be substantially easier to implement  
> effectively in the actual browser.

When you say "our" do you refer to SVG WG or to Opera, and is it  
Opera's official position that the SVG WG proposal would be easier to  

> It would, prima facie, seem relatively simple to implement in an  
> authoring tool that already handles SVG, since there is no need to  
> implement HTML parsing there, just slurp out the SVG bit and not  
> touch the HTML (which is relatively simple text processing).

Using simple text processing to extract content from HTML, instead of  
an HTML parser, is acceptable only if you don't care about correctness.

Received on Tuesday, 30 September 2008 00:13:21 UTC

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