From: <juanrgonzaleza@canonicalscience.com>

Date: Mon, 19 Jun 2006 05:06:14 -0700 (PDT)

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

Date: Mon, 19 Jun 2006 05:06:14 -0700 (PDT)

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

Ian Hickson wrote: > > On Mon, 12 Jun 2006 juanrgonzaleza at canonicalscience.com wrote: >> > >> > WHATWG doesn't have a position on this -- different contributors >> have different opinions, and no clear consensus is being reached as >> far as I can tell. >> >> It has been taken one! The draft of the specification recommends the >> usage of MathML for mathematics. > > Hm, good point. This wasn't particularly intentional. Fixed. Ok, people would freely choose languages in function of strengs and weakness. XML-MAIDEN, MathML, OpenMath, and others would compete in an equal footing (my experience is many people think that MathML is the _only_ approach to mathematical markup). > >> MathML violates the official possition because is not based in reusing >> backward compatibility with HTML + CSS + DOM. > > MathML works fine with DOM, and it would be just as possible to convert > MathML to SVG as it would to convert anything else to SVG (as you > suggest below). Others do not agree on "works fine". I personally see MathML-DOM like a DOM correction to the errors done in MathML markup (somewhat as MathML1-style was a correction to the mistake of ignoring available CSS language; error has been partially solved in MathML 2.0). Take the case of somewhat as <frac><num>a</num><den>b</den></frac> and <subform>H</subform><sup>T</sup> (and variants). Both encodings are DOM compliant and can be accessed and manipulated via the standard DOM methods browsers already incorporate. Take now MathML versions: <mfrac><mi>a</mi><mi>b</mi></mfrac> and <msup><mi>H</mi><mi>T</mi></msup>. Those encodings are not DOM friendly, obligating to introduce special MathML-DOM for accessing, for instance, to the base (H) of the script structure. However, I can access to H using the *same* standard DOM methods I am using for accessing any other HTML or XHTML markup ?e.g. the experimental pop-up navigation menu on the still experimental canonicalscience site- when I use the alternative encoding is being discussed here. I am not a specialist on DOM implementations, but I know that MathML-DOM model introduces special problems to browsers developers due to the extension mechanism chosen (by inheritance). Problems are *avoided* using a markup as that proposed by George and others which needs of no special DOM. As claimed many times in several places in the internet: w3c MathML WG reinvented the wheel and did it square. Moreover, still 2/3 of above summation hold. Posibility for conversion to SVG does p-MathML completely unnecesary (but not for c-MathML or HTML5-Math). In that case, I doubt that p-MathML was supported anymore in future. It appears to me a closed road. > >> iii) I am reading many people interested in native support for >> mathematics in HTML5. > > Certainly. The question is how. There have been several proposals. My > recommendation to those who think it is possible to re-use CSS to get an > acceptable level of Math support would be to go through the > Microformats process to prove the case. See my comments on why not microformats and the two links revieving microformats. > It doesn't make sense to bless a dozen new tags (or more) to be in the > HTML namespace (and thus with us for all time!) without first proving > that yes, that approach is good enough for mathematicians and > scientists. And what better way do you know that providing a mathematical markup on the final WHATWG draft? Mathematicians and scientists and rest of people using math (enginneers, students, physicians...) could read the draft and accept or reject it. You would only waste a bit of time writing and adding one or two new sections to the current draft of the spec. Some people here has done a public plea for mathematical markup using (at least the most part of) George original proposal. They did not a plea for development of a microformat. > >> However, i do not remember of some example that was correctly encoded >> in p-MathML with current tools and correctly rendered via browsers >> cannot be encoded via George CSS approach. > > Stretchy glyphs are one example. You can do basic maths with CSS, sure. > It's the high-end typography that's the problem. Sorry, but I cannot agree. In real practice, I do not know of a single example of MathML you can find at NAG, at Distler blog on string theory, at journals of math or on Living reviews on relativity (between others) containing mathematics cannot be rendered via CSS. And I would not call "basic math" to that on Living reviews on relativity or Distler MUSINGS. It is more, I am updating a serie of snapshots obtained with my Firefox browser when rendering MathML and the browsers fails in several cases with strectchy glyphs. Yes, some examples are passed when dowloading and installing special fonts, but that is not a sane practice. However, I know many examples of formulae (in physical and mathematical sites) are encoded via MathML 2.0 and both structure and the visual renderings are poor than using CSS (even if special CM and math fonts are installed in the machine): differentials, integrals, basic chemical formulae, tensors, and others. I have revised some in my blog but I will offer more examples in a new round covering mathematical journal, and educative site, NAG, Elsevier usage of MathML (do you know are not using the standard but an in-house modification?), and others. About "Stretchy glyphs" take the case of matrices of different size. Luca Padovani writes "By the MathML stretchying rules of operators [...] A quick analysis of the MathML markup reveals that there is no way to preserve the structure of the formula and still have a ?correct? rendering at the same time." However, I see no limitation for a fine-tuning of the correct rendering of a matricial equation on a CSS based approach ?I could adjust the heigth of the pathological matrix via standard CSS rules e.g. adjusting height of the borders-. But even if CSS was a 80% technology for math that does not indicate it was not useful. XSLT is also a 80% technology indeed for the rest of 20% transformations general languages and specific APIs are better. HTML-text never was designed for "high-end typography" just for electronic transmision of information. Most people finding nice MSWord mathematical rendering (even if mathematicians find it boring when comparing with TeX quality) would find nice HTML-Math-CSS. > >> vi) There is an increasing interest in graphical improvements of CSS. >> Mozilla Corporation and L. David Baron want substitute SVG >> capabilities via CSS (March 2006) without duplicating code. >> >> [http://dbaron.org/css/css-vg/] > > I'm familiar with that, I think I was the first person David showed this > to. I'm in the CSS working group as well, by the way. :-) The I suspect you would agree with me that rendering of mathematics via CSS (specially when including full graphical support for things as diagrams, roots, geometry, etc.) has more future that waiting a magical implementation in browsers of an ugly *presentational* XML markup (MathML) would be obsolete in a few years. If Mozilla Corporation and L. David Baron are interested in adding things as lines, gradients, and paths in CSS they will automatically be interested (but in an indirect way of course) in the drawing of roots, of poligons, Venn diagrams, maps, functions, etc. Currently browsers rely on a special presentational MathML markup needing of special non-web fonts for drawing the roots but cannot draw nothing of the rest, and the rest is also math. > >> I also would recommend a reading of >> >> [http://people.opera.com/howcome/1999/foch.html] >> >> since several comments also hold to the w3c idea of serving >> presentational MathML on the web. > > I am intimately familiar with this document too, howcome and I have > chatted about this many times over lunch... On that case p-MathML is most harmfull than FO objects still when served in online documents. Not forget that accesibility of p-MathML is poor that when you use the old GIF-ALT model. > Note that the proposal to have Math in HTML in a way that can be > rendered using CSS is also a kind of presentational Math and not a > pure-semantic Math, so arguing that we shouldn't use p-MathML because > it isn't semantic would not be consistent with arguing we should be > purely CSS-compatible. That was not my point. I carefully recommended to this list avoiding introduction of content markup and any semantic discussion since the issue is more complex than we can discuss here. My view is that HTML5-Math would focus just on structure. Next that structure would be rendered via CSS. This is usual practice in HTML and again we recover backward compatibility. Yet p-MathML is presentational, violates basic guidelines of web desing, would be avoided from the web and do not fit into general structure of structural HTML. P-MathML is a verbose version of the old <center>, <font>, <tt>, <i>, <b> and the rest of presentational HTML has been deprecated during last years. I see no rationale for that the same criteria followed with presentational HTML and XSL-FO may be not applied to p-MathML also. For instance, <mfrac><mi>b</mi><mn>2</mn></mfrac> is purely presentational (like XSL-FO is). Even the tokens <mi> and <mn> are purely presentational even if *some* tools can extract semantics from it. The fact they are designed to be purely presentational can be seen in the fact that content MathML version of above code is <apply><divide><ci>b</ci><cn>2</cn></apply>; that is, reusing ***nothing*** of p-MathML. But <frac><num>b</num><den>2</den></frac> is not presentational it is structural. There is a ?section? <frac> with two substructures num and den. Next frac, num, and den are rendered via CSS. For example num contains a bottom line can be styled via CSS standard rules (p-MathML, of course, reinvents the wheel adding his own collection of styles and attributes). Already in this list a CSS gur? claimed that was a big mistake (in fact, the absence of support in browsers is mainly due to mistakes of MathML designers). > >> However, official positions from several parties here implied would be >> welcomed before. Specially interesting for this WG would be position >> from browser developers. > > Howcome has stated his opinion, I believe; the idea of porting MathML to > HTML5 was originally put forward by the Mozilla team. I do not recall > any opinions from Safari or Microsoft developers on the topic. Other stated contrary views to MathML support. Morever, I am not sure if by "Mozilla team" you mean all the team (including CSS-SVG people) or just the guy that implemented p-MathML in Gecko in that "strange" (but heroic in no doubt) way (reusing HTML layout code for <mtable>, introducing CM font metrics in the rendering engine, very-low performance). It would be interesting to know users and developers think about idea of providing new mathematical markup for the web, solving difficulties of MathML. Some suggestion for publiciting this debate waiting *all* voices interested in mathematics (beyond mathematicians and scientists) can be heard? Juan R. Center for CANONICAL |SCIENCE)Received on Monday, 19 June 2006 05:06:14 UTC

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