Re: SVG and MathML in text/html

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

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

Received on Wednesday, 12 March 2008 15:46:47 UTC