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

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

From: James Graham <jg307@cam.ac.uk>
Date: Sun, 28 Sep 2008 18:21:36 +0100
Message-ID: <48DFBD20.8040109@cam.ac.uk>
To: Charles McCathieNevile <chaals@opera.com>
CC: Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org" <public-html@w3.org>

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". So 
far, of the  people who have seriously  looked at implementing the  
SVGWG  proposal vs the commented-out-in-the-spec proposal in their HTML5 
parsers, both have concluded that the commented-out proposal is simpler 
to implement. I haven't seriously looked at implementing either proposal 
but I would be astonished if handing off a subset of the page to an 
entirely different parser was easier to implement, with fewer edge cases 
to trip up on, than something that integrates directly into the current 
parser design.

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.
> the existing SVG language rather than some version of it that adds a 
> whole new set of parsing requirements, the real-world problem of 
> enabling people to hand-code rubbish isn't a serious issue in the SVG 
> world. Given the relative scarcity of hand-authoring in SVG, tool 
> coders become the most important authors of code, in terms of 
> understanding the "priority of audiences" guideline that is sometimes 
> tossed into this discussion.

It's not only hand authors who benefit from non-draconian syntax. Anyone 
building dynamic functionality into their site benefits since ensuring 
well-formed markup at all times without playing xml-error-whack-a-mole 
all over the site essentially requires the backend to be designed around 
the fact that the output is XML. This precludes the use of common 
text-based templating languages which have a number of advantages over 
designed-for-XML systems such as Genshi (which, I should say, I adore) 
and XSLT, notably their speed and ease of use when not working with XML 
on the output side (see also e.g. [1]).

There is also an opportunity cost associated with the use of draconian 
syntax in that the effort needed to ensure that none of the failure 
conditions (even the trivial, harmless ones) are ever met could 
otherwise be spent on more useful features that would make the end 
product more attractive to users. Therefore, if we are going to argue 
from the point of view of the priority of constituencies, draconian 
syntaxes are bad because they hurt authors (because they have to spend 
effort ensuring that their output meets an arbitrary set of constraints 
or have their users experience a catastrophic failure) and hurt users 
(because they end up with sites that have compromised on some other 
aspect of their experience in order to make sure that the fragile syntax 
won't break, or have to use sites that are prone to frequent breakage). 
By contrast, tool vendors (who, in this case, are really not helped 
either, as I mentioned above) are a much less significant concern.
> A substantial proportion of SVG already seems to be moved from one 
> tool to another. Allowing a new syntax would mean breaking 
> compatibility with the existing toolset - something that doesn't seem 
> to have any justifiable motivation beyond an assertion that people 
> will suddenly start badly hand-coding complex SVG graphics en masse, 
> despite the evidence. 
Having a text/html wrapper around the SVG already breaks compatibility 
with existing tools. I really think the ability to open a file, search 
for the SVG fragment, copy it into a new file and be sure that file will 
open in a legacy SVG editor is being vastly overplayed; it seems 
considerably more useful to have SVG editors implement text/html parsers 
so that users can open any HTML file and edit the SVG fragments without 
needing to get their hands dirty with the markup.
> (Yes, people do hand-code it. I hand code the majority of my own SVG, 
> and I generally get it right. Where I haven't, losing the error 
> correction of relatively strict interpretation is more than enough 
> reason for me to prefer the strict handling to be maintained. I 
> appreciate the portability of code between existing tools and devices 
> far more than I can ustify any desire to be allowed to do sloppier work).
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.

[1] http://www.becontrary.com/debates/xml_or_text_for_python_templates
Received on Sunday, 28 September 2008 17:22:21 UTC

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