From: <juanrgonzaleza@canonicalscience.com>

Date: Tue, 20 Jun 2006 07:36:57 -0700 (PDT)

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

Date: Tue, 20 Jun 2006 07:36:57 -0700 (PDT)

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

"Robert O'Callahan" wrote: > > I'll speak up as one of the Mozilla layout developers, but speaking only > for myself. > > Since we already have a MathML implementation --- which works fairly > well in my experience --- Do you mean structurally invalid, inacessible, not searchable, and sometimes incorrectly rendered math that one find even at academic sites using MathML? Do you mean the in-house **modification** of MathML Elsevier is using but still serving graphics on the web? Or do you mean that due to specificies of MathML ugly design, Mozilla layout engine is unable to fully implement MathML formatting semantics? You may know this point better than me. I am not sure but apparently the solution to this will be a complete rewritting of the Gecko engine from zero, that is true? Or by ?fairly well? do you mean an average theorem in the HELM library takes up 20 minutes to render on a high-end machine? The own Mozilla?s MathML author has studied this point in detail and traced the problem to the own MathML layout engine in Gecko. Also I think (correct me if wrong) that you are talking from a pure developer view (without many experience in authoring of complicated MathML docs). In theory, MathML would be able to render something so simple as {ds}^2. In practice both Distler (Mussing ultra-technological blog) and Living reviews on relativity online journal (HERMES project) still are unable to do something so simple as visual rendering of {ds}^2 how I have pointed many times (aural rendering and accesibility of code is purely inexistent). A few days ago, Distler received notification about my open criticism about one of his multiple incorrect encodings of mathematics on the web and he changed the code just a few days ago, but now the visual rendering is poor that using old HTML 3 code. The point is that there exist very important holes and mistakes in the MathML specification, and waiting spreading on the web or magical implementations of the spec. in all browsers does not eliminate the holes and mistakes. We are trying to eliminate those problems from the web. In fact anyone using HTML5 will be able to encode and render {ds}^2. Mussings (claimed to be the technologically most advanced blog of the planet) is unable to so simple taks even using: MathML 2.0 + XHTML 1.1 + special DTD + native browsers + special MIME + special fonts + special plugin + special IteX dialect. > I think it makes more sense from our point of > view to fix/improve MathML than to deal with new CSS extensions to get > decent rendering. MathML 2.0 did some presentational features of MathML 1 deprecated. MathML 3.0 probably will do some of current presentational features of MathML 2.0 deprecated. The CSS Math extensions are scheduled by both MathML and CSS IG and would be implemented in browsers in any case. Therefore, the fixing/improving of p-MathML looks (in my opinion) as a waste of time. Moreover, p-MathML violates basic guidelines of web-desing, somewhat as XSL-FO or SVG do. Mozilla has publicy expressed its interest in adding CSS extensions for a **semantic** implementation of most of SVG. Those extensions for vectorial graphics could be reused for rendering math (e.g. roots): somewhat as today we can render mathematics using SVG without need for native p-MathML, including stuff that p-MathML cannot render: geometry, commutative diagrams, chemistry... > MathML's purported incompatibilities with DOM and CSS > are not serious from an implementor's point of view, at least no worse > than lots of other CSS-unfriendly content we have to deal with. I hope > that the fonts issue gets better when comprehensive STIX fonts are > freely available online and we can automatically download them whenever > they're needed. Mozilla philosophy of adding everything (even incompatible layers) in a big elephant monolithic module is not popular in other browsers (e.g. Opera). Therefore... Is it true that future STIX fonts will need of a significant rewriting of the MathML formatting engine of Mozilla? Will be we need new versions of the browser for new font families? > stronger case for inclusion. I would also like to see a complete > description of the CSS extensions required for real high-quality > rendering. Why do not ask to CSS-MathML module people or even to your own Mozilla colleagues for the already implemented -moz-math CSS extensions? >>From my point of view, a <fraction> element that can be implemented >> using > inline-block in the UA style sheet seems like a reasonable thing to > support in HTML5, since it's basically no effort and is a small > increment over existing <sup> etc. What one great notice!!! What do you opine of my suggestion for addition also sub-sup and under-over constructs to the basic spec? Both sub-sup and under-over constructs are _basically_ fractions without the line. Once fractions are implemented in UA, I would wait minimal efforts for the implementation of sub-sup and under-over. We could leave away roots (can be still displayed with some effort from the authors; there are techniques on internet for this) and other refinemenst until better days. Authors could reuse HTML or CSS tables for vectors, determinants, etc. "White Lynx" wrote: > > Robert O'Callahan wrote: > >> From my point of view, a <fraction> element that can be implemented >> using inline-block in the UA style sheet seems like a reasonable thing >> to support in HTML5, since it's basically no effort and is a small >> increment over existing <sup> etc. > > Thus fractions work in MSIE, Opera, Prince. One of Mozilla developers > admits that including fractions in HTML5 makes sense. Seems like no > problems on browsers side. Include them in HTML5 and at least school > level mathematics will get its place on web. > > This is small step but it is still important as torturing people that > need to include simple formulae in web page with complex machinery > involving XHTML, namespaces, MathML that requires extra plugins in most > of browsers, sometimes XSLT or JS, from the very beginning makes web > very distructive for math and not only math folks. So small step in > right direction makes sense. People at medical community would be also very happy with that. [http://www.medicalcomputing.net/action_potentials_code.html] Specially iluminating is the section "My choice of technology in this example is driven by several factors:" This is a point I failed to explain at this list but that a mathematician working with TeX call "ugly rendering" a biologist, a chemist, or a physician can find it nice enough. The rendering of the Nernst equation in above link can be improved (I personally would do) with a bit of fine-tuning in CSS but many scientists (students also) will find it nice enough for *the web*. George available stylesheet would rendering better the equation. Juan R. Center for CANONICAL |SCIENCE)Received on Tuesday, 20 June 2006 07:36:57 UTC

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