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

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.

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). The only authoring tool I know that  
has actually handled mixed content in HTML is Amaya, so I will ask them.

> Note that these considerations also apply to authoring tool vendors  
> since anyone who wants to support input/output form text/html will have  
> to implement a full HTML5 parser. So the fact that XML parsers are  
> already common is not really an argument for making things embedded in  
> text/html behave like XML.

That argument doesn't apply to all tools, only to those that generate  
mixed content. The idea of making SVG incompatible with existing SVG would  
merely mean that you force all tools to implement an HTML5 parser, even if  
they are SVG only. While it would be nice to see this change, I don't  
think it is in scope for the HTML working group to try to socially  
engineer it through a specification.

[...]

> I suspect that, in the specific case of SVG, the prevalence of tools for  
> creating  static documents means that the big win for tolerance of  
> syntactic errors is in the dynamic generation of documents. The fact  
> that SVG is not presently implemented in IE and cannot currently be  
> integrated with error-tolerant HTML is probably limiting the number of  
> people who complain about the failings  of SVG in this context.

You may suspect this, but it seems your speculation runs counter to the  
existing evidence from a decade of adoption, where increasingly strict  
basic coding requirements, combined with some more author-friendly  
error-handling relating to certain SVG-specific aspects, has apparently  
not led to complaints from either tool producers or hand-authors. It  
appears that the potential opportunity cost resulting from "Getting It  
Right™" is below the pain threshold of authors, although one might further  
speculate that the value of clean code that can be easily developed is  
something that increases the long-term acceptance of a basic requirement  
for it.

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 Monday, 29 September 2008 23:28:20 UTC