From: Neil Soiffer <Neils@dessci.com>

Date: Sat, 29 Mar 2008 17:03:10 -0700

Message-ID: <d98bce170803291703m10bf7a60w4fef75efe88c099d@mail.gmail.com>

To: "Ian Hickson" <ian@hixie.ch>

Cc: "Robert Miner" <robertm@dessci.com>, public-html@w3.org, www-math@w3.org

Date: Sat, 29 Mar 2008 17:03:10 -0700

Message-ID: <d98bce170803291703m10bf7a60w4fef75efe88c099d@mail.gmail.com>

To: "Ian Hickson" <ian@hixie.ch>

Cc: "Robert Miner" <robertm@dessci.com>, public-html@w3.org, www-math@w3.org

I think that some people feel MathML is not used much on the Web. It is true that its usage pails in comparison to that of HTML, but it is being extensively used. In the *five months* since MathPlayer 2.1 was released, there have been over 100 *million* expressions viewed by users of MathPlayer 2.1 (this doesn't count Firefox users), and of those, almost 700,000 were by assistive technology users. Given the difficulties with putting out XHTML pages today, I find that pretty impressive. Those numbers are sure to go through the roof if MathML is added to HTML5. But if it is done in an incompatible manner, there will be a lot of unhappy people and a lot of unhappy standards groups. MathML is a part of many XML-based standards such as ODF and DocBook, and is also part of two prominent accessibility standards (DAISY and NIMAS); don't make life difficult for them. On Fri, Mar 28, 2008 at 11:31 PM, Ian Hickson <ian@hixie.ch> wrote: > I'm investigating possible options for addressing the problem of "Putting > an equation in a Web page". One of the options is doing something with > MathML. To that end, I have some questions for the MathML community about > what options are available along these lines. > On Thu, 27 Mar 2008, Robert Miner wrote: > > > > - Our main priority is merely having a good solution for using MathML in > > HTML. That is hopefully not controversial, but there have been calls > > for alternatives, so we wanted to emphasize that we believe that any > > specification of mathematics in HTML5 ought to be based on MathML. While > > MathML adoption has taken a while, it is in wide use today and supported > > in main stream tools, so having it available in HTML in some fashion is > > important. > Could you point me to further information on this? I'm interested in > investigating how much support there is for editing MathML content, in > particular, since it's not a very human-friendly format. > See the list at the W3C http://www.w3.org/Math/Software/mathml_software_cat_editors.html. There are 25+ editors listed there (some better than others), and that doesn't include applications like Maple, Mathematica, and Word that can export MathML either as instances or as part of a document. > > - That said, the Math WG doesn't see any problem with coming up with a > > lax-parsing model that produces a well-defined DOM, particularly if it > > enables export of standard MathML as XML. > Cool, that's very encouraging. Any knowledge you have about that would be > great. Is there any documentation on common MathML errors? Is there any > documentation on what elements could be implied? Is there any reason > digits couldn't imply <mn>, for example, and punctuation couldn't imply > <mo>? Any help here would be greatly appreciated. > Speaking personally, although I suspect it is also the sense of the MathML WG, such as change would be bad. It is akin to inferring paragraphs elements by detecting double linebreaks or inferring other elements in HTML5. Why not make HTML5 "do the right thing" when it encounters some wiki-type shorthand for section heads, lists, etc? It would make it easier to enter and edit HTML5 by hand. I only mention that by way of analogy and am not suggesting it in the slightest -- such a change to HTML5 would no longer be HTML5 and making changes to MathML by dropping tags and trying to infer them would also no longer by MathML. Those same people you think would appreciate having a shorthand way to author MathML will also expect it to work in all MathML consuming applications when they cut and paste *from their source*, so you probably won't be doing them or the standard any favors. > MathML is a very big language, with just shy of 190 unique elements in > MathML2 (HTML4, including all the deprecated elements, has but 91). Could > we get away with making that simpler for HTML, e.g. by not including > support for Content markup in the text/html variant? > Again, speaking personally, I agree with David that just supporting the 30 tags or so (including semantics/annotation) for presentation MathML is fine. > One of the use cases is the mixing of graphics and form controls into equations. > Is it possible to extend MathML to allow specific HTML5 > phrasing-level elements (like <em>, <img>, <input>, also maybe the <svg> > element) wherever the <mglyph> element is currently allowed, or something > along those lines? > The MathML WG has considered this problem many times. Because MathML lives in a larger world than HTML5, or XHTML, such inclusions need to be very carefully considered because they can wreck interoperability or be incompatible for standards that have adopted MathML. To date, the committee has yet to find a solution. We were leaning towards using namespaces and allowing namespaced elements at certain points since most consumers of MathML are namespace aware, that would be problematic for HTML5, right? Suggestions ranged from adding some "simple" HTML tags like <em> or <a>, to allowing SVG, XForms, and probably several other formats that I've forgotten. It is very easy to forget that MathML serves a much wider audience than XHTML or HTML5. If one standard says "this works fine for us" and another standard says the same for something else, there goes interoperability. It would be great if CDF would solve this problem, but so far they haven't. Surely it is not in the HTML5 charter to solve this problem. Neil Soiffer Senior Scientist Design Science, Inc. www.dessci.com ~ Makers of Equation Editor, MathType, MathPlayer and MathFlow ~Received on Sunday, 30 March 2008 00:03:44 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:40 UTC
*