From: <juanrgonzaleza@canonicalscience.com>

Date: Thu, 8 Jun 2006 11:18:21 -0700 (PDT)

Message-ID: <3026.217.124.88.212.1149790701.squirrel@webmail.canonicalscience.com>

Date: Thu, 8 Jun 2006 11:18:21 -0700 (PDT)

Message-ID: <3026.217.124.88.212.1149790701.squirrel@webmail.canonicalscience.com>

Ian Hickson wrote: > I would say MathML is not widely used because MathML doesn't work in > HTML, personally. I do not know from where this idea get up. SVG is relatively popular and implemented in many browsers, but the same browsers implementing SVG are rejecting MathML. They are rejecting because difficulties for implementation, not because HTML lack of. The original mathematical work from the w3c was mathematical markup FOR HTML. It was drafted so early as in HTML 3 epoque and strongly rejected by community. Unfortunately subsequent first draft of MathML, MathML 1.x and recent MathML 2.0 all habe been rejected by technicla motives rather than HTML-relationship. In fact, I do not know a single criticism to MathML emphasizing the point you state. All public criticism are to design options and technical details independent of host language. > If we made MathML work in HTML, possibly with rules > that make the syntax easier (by implying tags as I suggested earlier), Curiously, I suggested similar approach in my previous CanonMath language [http://canonicalscience.blogspot.com/2006/02/choosing-notationsyntax-for-canonmath.html] one could write something like <CanonMath> a+b<fraction/>2 </CanonMath> [http://lists.w3.org/Archives/Public/www-math/2006Mar/0027.html] next was converted to full presentation MathML 2.0, but it was strongly rejected by MathML authors, see Carlisle reply for instance [http://lists.w3.org/Archives/Public/www-math/2006Mar/0028.html] Moreover, your proposal would be rejected by most authors and developers (today rejecting MathML) because obtain all difficulties and limitations of current MathML (between them incompatibllity with DOM, CSS, XSL-FO.) More the rejection from w3c MathML guys that do not want to see a mixture of textual strings with MathML own elements. > then that might well change, especially given that one UA already has > extensive and high-quality support for MathML. I imagine that you mean Firefox browser with native MathML. Well I would not call that ?extensive and high-quality support for MathML.? I would say, ?partial incompletete support of less than one half the official specification?. Content MathML is not supported, only presentation MathML; of presentation MathML not all tags are supported; of all tags supported not all are working. You can begin from the most simple teste of the MathML official test suite and can see that MathML suport is weak in browser (I use Firefox 1.0) and even most simplest test are either not correctly rendered or not at all (compare with sample GIFS). http://www.w3.org/Math/testsuite/testsuite/General/Math/math3.xml http://www.w3.org/Math/testsuite/testsuite/General/Math/mathAdisplay1.xml http://www.w3.org/Math/testsuite/testsuite/General/GenAttribs/style1.xml http://www.w3.org/Math/testsuite/testsuite/General/GenAttribs/style2.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miAtoken5.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miScolorscope7.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miSfonts8.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miSfontsize9.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miSmathsize17.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miStoken10.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mn/mn3.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mn/mnAcolorname5.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mn/mnAtoken6.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mo/moAlargeop12.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mo/moAminmax14.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mo/moAmovable15.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/GeneralLayout/mrow/mrowBinferred2.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/GeneralLayout/mfrac/mfracAbevelled16.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/GeneralLayout/mfenced/mfencedAdelims6.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/GeneralLayout/mfenced/mfencedBfences7.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/ScriptsAndLimits/msubsup/msubsup1.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/ScriptsAndLimits/munder/munder1.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/ScriptsAndLimits/munder/munder2.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/ScriptsAndLimits/mmultiscripts/mmultiscripts2.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TablesAndMatrices/mtable/mtable1.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TablesAndMatrices/mtable/mtableAwidth1.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TablesAndMatrices/mtable/mtableBsize1.xml And many other test are not passed by the browser. However, most of those test could be easily passed via a CSS approach such as that designed by George. And in fact I believe that allmost (if not all) of above official test could be passed *today* by Opera browser simply using CSS 2.1 and XML MAIDEN markup. Moreover some of MathML renderings (e.g. roots) in firefox only can be achieved via downloading and installing special fonts. Fonts (CM) are *not* designed for web. Moreover, due to special implementation of Mozilla render module and TeX fonts. If tomorrow I can use special scientific fonts (STIX ones for instance) I can use the fonts in George approach and they will render in Opera browser, but not in Firefox, because for each new set of fonts to be implemented in MathML engine, the whole core needs to be recompiled! Therefore I you want use some future font in mathematics wait until developers recompile source and launch a new Firefox browser then donwload it and install in your computer. Cheap not? Of course, all this is based in that MathML IG simply developed a markup language incompatible with available technologies and difficult (or imposible) to be fully implemented in browsers. MathML is a fiasco. Explanation I have heard from some w3c people has been that browser developers are 666 and that CSS guys want nto support MathML and that authors are ?stupid? and only like LaTeX... Ups! and do not forget that due to specificies of Gecko engine, some large MathML documents can need of 10 minutes before being displayed in the browser (without incremental rendering of any class), which is completely unacceptable for users. H?kon Wium Lie wrote: > It takes years and years to produce new presentational features, write > test suites and make them work interoperably. At this stage, any > effort that relies on new CSS properties is a decade away from full > deployment. By contrast, changing markup on the author side is very > easy. So, I'd rather make the markup language CSS-friendly (and > author-friendly) than the other way around. Yes! I had a similar debate with MathML WG this year and similar thoughts. See my reply to Miller [http://lists.w3.org/Archives/Public/www-math/2006Apr/0030] > Historically, it's a common mistake to develop markup systems without > giving much thought to presentation. For example, only when SGML was > done did one start efforts to create a style sheet language for it > (FOSI/DSSSL). Likewise with HTML. Given that CSS existed when MathML was > created, I think the developers made a mistake by not creating a markup > language that could be presented using existing CSS properties. > See also the ?excuse? on why they ignored CSS and decided reinvent the wheel. It is curious as they believe that CSS support would be marginal but that is being marginally supported in precisely MathML (even after 10 years!!). But the MathML IG ignored also other previous approaches. For example instead reusing previous ISO-12083 they reinvented a new ugly language nobody is really using. George beginning from ISO12083 and doing minimal changes (for CSS compatibility) is able to render mathematics in a browser without sepcific mathematical code (only supporting standard CSS 2.1). Content Markup also ignored previous lesson and there is lot of errors in the markup. For example problems with binding and compositional design begin to be solved in last versions of content MathML and OpenMath when same problems had been solved in programing languages as LIPS decades ago. The MathML IG has a tendency to ignore previous works and reinvent the wheel (and like someone pointed in the Internet ?doing it squared?). Ian Hickson wrote: > Why not just re-use MathML? MathML already has defined semantics, a > defined interpretation based on DOMs, defined DOM interfaces, and an > implementation in at least one browser. It is difficult resume tons of criticism, but basically we would not use MathML because does not work well, and is incompatible with DOM, CSS, XSL-FO, and even with the own XML. Since it is incompatible with available technology it cannot be fully implemented in browsers, or in print engines, since language is tecnhically defficient most of tools generate invalid scary code is not searchable not accesible, since there is not future (not present) search engines ignore the specification. MathML specification also obligates you to learn additional redundant methods, elements and attributes. For example, you are obligated to learn a way to change font size or bold typeface in text but may learn other way in MathML code. Moreover MathML violates the most basic web guidelines: splitting content from presentation. One writes a semantic or structural code in XML or HTML next is styled via CSS. MathML offers mathematical versions of the deprecated <font> and family tags. Juan R. Center for CANONICAL |SCIENCE)Received on Thursday, 8 June 2006 11:18:21 UTC

*
This archive was generated by hypermail 2.3.1
: Monday, 13 April 2015 23:08:27 UTC
*