From: Henri Sivonen <hsivonen@iki.fi>

Date: Sun, 30 Mar 2008 11:20:33 +0300

Cc: HTML WG <public-html@w3.org>, David Carlisle <davidc@nag.co.uk>, Ian Hickson <ian@hixie.ch>, Public MathML mailing list <www-math@w3.org>

Message-Id: <C2478014-9227-4BBD-AAB7-60C8245C2063@iki.fi>

To: Neil Soiffer <Neils@dessci.com>

Date: Sun, 30 Mar 2008 11:20:33 +0300

Cc: HTML WG <public-html@w3.org>, David Carlisle <davidc@nag.co.uk>, Ian Hickson <ian@hixie.ch>, Public MathML mailing list <www-math@w3.org>

Message-Id: <C2478014-9227-4BBD-AAB7-60C8245C2063@iki.fi>

To: Neil Soiffer <Neils@dessci.com>

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 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Wednesday, 9 May 2012 00:16:13 GMT
*