Re: Exploring new vocabularies for HTML

On Mar 30, 2008, at 02:49, Neil Soiffer wrote:
> On Sat, Mar 29, 2008 at 4:17 PM, Henri Sivonen <hsivonen@iki.fi>  
> wrote:
>
>> On Mar 30, 2008, at 01:11, Henri Sivonen wrote:
>>> Since SVG in MathML works fine in the #1 SVG-in-MathML browser
>>> engine implementation (Gecko in Firefox 3), I think requiring the
>>> <semantics><annotation-xml encoding="SVG1.1"> cruft around <svg> is
>>> just silly and it would be better to make <svg> subtrees conforming
>>> directly inside Presentation MathML.
>>>
>> I meant to say that SVG in MathML works fine in Gecko without the
>> <semantics><annotation-xml encoding="SVG1.1"> wrapper (so the wrapper
>> is pointless).
>
> I don't understand this argument.  It seems to be "since Gecko  
> supports SVG directly in MathML,  that proves there is no reason for  
> a semantics element".

It proves that
  1) it is possible to implement a UA that accepts an SVG subtree  
without an annotation-xml wrapper inside a Presentation MathML formula
  2) it has already been implemented
  3) it is implemented in the leading SVG-in-MathML Web client, so  
changing the spec would not break compatibility with the leading  
implementation

> Any implementation could support any random tag and make similar  
> statements, but then no other implementation would know what to do.

So if you take the original from http://hsivonen.iki.fi/test/svg-in-math.xhtml 
  how are implementations that don't support SVG any wiser with the  
valid case than with the less crufty case?

> <semantics> provides a fallback for those implementations that don't  
> understand some possibly richer encoding than is possible in  
> MathML.  This is an important encapsulation for interoperability.

Has this fallback mechanism been interoperably implemented? Like I've  
commented on the www-math before, the encoding attribute values are  
not properly specced.

> I'm not sure if you were being tongue in cheek when you said Gecko  
> is the "#1 SVG-in-MathML browser" -- it is the only such engine that  
> I know of.

In that case, there's no other implementation that could get bruised  
if the conformance definition were cleaned up based on Gecko behavior.

> As David pointed out, it is not legal MathML, although the standard  
> tries to provide an out for Firefox.

I'm suggesting making it legal.

> Pasting SVG in MathML into another application or viewing the page  
> in a different browser would cause an error, so it use is likely to  
> be a very bad idea unless you knew your target audience only wanted  
> to view the content in Firefox and never wanted to reuse it elsewhere.

Considering that Opera and WebKit already support SVG, wouldn't it be  
reasonable to expect Opera and WebKit to support SVG-in-MathML the way  
Gecko does if/when they add MathML? (Until they do add MathML, the  
point is moot anyway.)

Hmm. It turns out that Opera 9.5 supports the less crufty version but  
not the valid original at http://hsivonen.iki.fi/test/svg-in-math.xhtml
!

As for pasting into a non-browser application, I don't see how they  
are helped with an <semantics><annotation-xml> wrapper in such a way  
that <math>...<svg>...</svg>...</math> couldn't be defined to be  
semantically equivalent to <math>...<semantics><annotation-xml  
encoding='SVG1.1'><svg>...</svg></annotation-xml></semantics>...</math>.

> On the other hand, semantics is used by many of the leading MathML  
> authoring tools (MathType, Mathematica, Maple, OpenOffice, ...).   
> You might not like semantics, but based on current practice, many  
> (most?) other applications think it is useful.


Of course there'd be less reason to be concerned about the undesirable  
lock-in-inducing properties of feature if no one used it.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 30 March 2008 08:21:37 UTC