From: <juanrgonzaleza@canonicalscience.com>

Date: Mon, 12 Jun 2006 05:48:49 -0700 (PDT)

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

Date: Mon, 12 Jun 2006 05:48:49 -0700 (PDT)

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

Ian Hickson wrote: > On Sat, 10 Jun 2006, White Lynx wrote: >> >> Agree. Once conceptual issues will be resolved and WHATWG will clarify >> its position regarding math markup, we can return to naming >> conventions and if majority prefer brief element names, ISO 12083 >> element names will be replaced with shorter ones. > > 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. This in my opinion is a big mistake because: i) There exist technical difficulties in w3c mathematical specifications doing implementation in browsers inexistent or very slow. One only needs see the variation on different markups proposed for seeing as errors have been removed. If compatibility with rest of browsers technology is a issue for next MathML 3.0 then we will see further changes in the language again. The slow implementation of MathML in the Internet is not due to a small target. At the one hand Microsoft is supporting equation editor in MSWord and providing MathML support in Office whereas rejecting native support of MathML in MSIE. Also others browsers are not supporting MathML even if interested in math. Reason is that MathML is not easily implemented in browsers. ii) The WHATWG follows an official position stated in the Mozilla and Opera manifesto. MathML violates the official possition because is not based in reusing backward compatibility with HTML + CSS + DOM. iii) I am reading many people interested in native support for mathematics in HTML5. I also read interest from one of big CSS guys. If I remember correctly only you have rejected the proposal but providing a novel one is not backward compatible with nothing. > Personally I think the best way of demonstrating that no browser-native > support is required would be for someone to develop a specification for > mathematics markup using the microformats.org principles. If this > demonstrates that it really is possible to create viable math markup in > HTML and have it completely styled in CSS then that would be a good step > forward. You talk of "no clear consensus" (I do not agree, for example nobody is against the fraction markup proposed by George only about tag names). Moreover, this thread is still very young. After 10 years the MathML IG has not achieved consensus still in input sintaxes or so. Would then MathML to be supported as "microformat" ;-) Do not forget also that just a weeks ago we discussed how \dot{q} would be encoded in MathML 2.0 (specification says nothing on this also). There was three main proposals: usage of <mover> always, mixed usage of <mover> and Unicode combining diacritics, usage of Unicode always. Moreover, I added exmaples of outputs for \dot{q} from MathML tools. Each one offered different mathematical markup, and some of markups generated failed in interchange with Mathematica 5.2 and one of them (from IteX) was incorrectly rendered. Therefore after 10 years, we got problems on encoding of \dot{q}!!! iv) CSS ampliations for MathML will needed in any case. And, in a future, all presentational redundant features of MathML would be removed from the web by consistency. v) You have done some heavy criticism on limitations of CSS, and apparently you believe that rendering of math in CSS is kind of impossible approach "Things that are impossible just take longer." 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. 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. Then some discussion here over rendering of roots via SVG fragments would be addressed to rendering of roots via CSS (just approach George is taking now ;-). If in a future best ways to render roots in CSS are available he just will update the CSS ,but markup will remain the same and legacy docs will continue working (with increased quality rendering). [http://dbaron.org/css/css-vg/] This class of approach and similar others will do p-MathML completely unneeded in a near future (with native p-MathML browsers with absolutely no future). 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. Once you can map p-MathML to SVG and you can render mathematics on the web [http://www.w3.org/Math/testsuite/testsuite/TortureTests/Complexity/complex1.xml] [http://www.grigoriev.ru/svgmath/samples/complex1.svg] [http://www.grigoriev.ru/svgmath/samples/complex1.pdf] [http://www.w3.org/Math/testsuite/testsuite/TortureTests/Complexity/complex2.xml] [http://www.grigoriev.ru/svgmath/samples/complex2.svg] [http://www.grigoriev.ru/svgmath/samples/complex2.pdf] do you NOT need specific presentation MathML support anymore because you can map your own favourite collection of tags. Ah! and most of the SVG math looks better in my Firefox 1.0 with Adobe SVG 6.0 plugin (pre-alpha version) that via MathML native rendering. I could provide to you snapshoots for comparison also in this case. Moreover, the generic SVG rendering can be coupled to other languages, once I know SVG code for rendering a fraction I do not need use <mfrac><mi>b</mi><mn>2</mn></mfrac>. I can use any code I want: including structural and semantic code. I could even write <fraction>b<den>2</fraction> in my documents. And if SVG is rewriten like extended CSS then that would be great, very great!! However, the structural (with some semantic) markup of kind is being here discussed will be ***still needed***. Somewhat as <h1> is needed independently if you render headings via XSL-FO, CSS, or SVG. Therefore, since this HTML5 work is for a better (backward compatible) work can be easily implemented in browsers and inexpensively used by street people, I carefully recommend further discussion of mathematical capabilities into HTML5. However, official positions from several parties here implied would be welcomed before. Specially interesting for this WG would be position from browser developers. Juan R. Center for CANONICAL |SCIENCE)Received on Monday, 12 June 2006 05:48:49 UTC

*
This archive was generated by hypermail 2.4.0
: Wednesday, 22 January 2020 16:58:47 UTC
*