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

Re: SVG and MathML in text/html

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 12 Mar 2008 17:46:31 +0200
Message-Id: <C0C1D766-AB27-4961-8A55-305016F28E26@iki.fi>
To: HTMLWG Tracking WG <public-html@w3.org>

On Mar 11, 2008, at 22:24, Ian Hickson wrote:

> For example, the first could be solved by a careful introduction of a
> subset of MathML into the text/html parser spec, with defined  
> handling of
> implied elements so that, e.g., <mrow> elements can be omitted in  
> the same
> way that <tbody> elements can be omitted, and end tags could all be  
> made
> optional without loss of precision.

Consider the example from
http://en.wikipedia.org/wiki/MathML#Example

I think the writability optimizations you mention cannot salvage  
MathML and make in an author-writable language. Even with your syntax  
optimizations it would still be more convenient to write e.g. iTeX  
formulae and convert them to MathML. Therefore, I suggest keeping the  
parser changes simple and not even trying to make MathML hand- 
authorable without a converter in between.

> Maybe we can even solve it
> without using SVG at all, but by supporting the output of some common
> graphics program directly, after specifying it.

Except such a solution would have very different implementability  
properties compared to changes that are confined to the parser.

> My point is not to support any of the above suggestions. My point is  
> that
> there are use cases other than Henri's.
[...]
> As a general rule I recommend avoiding referring to specific  
> technologies
> in such use cases.

Requirements can flow from considerations other than use cases-- 
particularly the expected implementation delta between status quo and  
the post-implementation state. Specific technologies are relevant when  
considering what the status quo is.

Realistically, it would be bad to fail to reuse the above-DOM client  
code that already exists for SVG. Likewise, it would be bad to fail to  
reuse the existing above-DOM client code for MathML (even though it  
exists less broadly than the code for SVG).

This considered, I don't think challenging SVG and MathML as the above- 
DOM solutions is a good idea.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 12 March 2008 15:46:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:53 UTC