- From: <juanrgonzaleza@canonicalscience.com>
- Date: Tue, 20 Jun 2006 05:26:23 -0700 (PDT)

Anne van Kesteren wrote: > > Quoting Stefan G?ssner <stefan at goessner.net>: >> I wish, that WHATWG would have a similar motivation to offer >> lightweight math capabilities parallel to MathML, as they were >> motivated to support vector graphics via the <canvas> element parallel >> to SVG. > > OMG. Have you even read what <canvas> is about? :-) Just noise? Or this comment really help to draft presented? Michel Fortin wrote: > > Le 19 juin 2006 ? 10:25, <juanrgonzaleza at canonicalscience.com> > <juanrgonzaleza at canonicalscience.com> a ?crit : > >>>> In other words math proposal is rejected, mathematics in HTML is >>>> blocked one more time. >>> >>> I have suggested a process by which you could prove your proposal >>> would >>> work. That is hardly a rejection. >> >> Some people can read between lines. > > The way I read into Ian's lines, he simply says he is not at all > convinced that whatever we can come with will be preferred by authors > than MathML currently is. And I think it only makes sense that as long > as he is not convinced of that he will not agree about adding it to > HTML (hence "reject" it). That doesn't mean he isn't open to the idea. And what is the problem with adding mathematical section to current draft of the HTML5 spec and wait for feedback from the community once presented? That is still more cheap that implementation of HTML-Math in browsers with CSS 2.1 support ;-) My point is that you cannot claim that the work will be rejected if you do not present it to the community. If the draft of the spec is rejected in its mathematical section then that section would be not maintained for the final spec. Nobody loses. All of us gain. It is transparent that HTML3-Math, MathML1, MathML 1.01 failed in the taks of providing mathematical markup for the Internet; with MathML 2 gaining a bit of attention (but infinitesimal for the publicity received). I see HTML5 as a new opportunity for correcting this long fiasco in our hands, only that nobody would worry with me about this. > I think Ian is right in some way: adding full mathematics correctly, > even with CSS, isn't going to be a piece of cake. Bugs will need to be > fixed with many CSS engines, and even then the current markup proposal But developers need to fix those bugs in any case because are part of CSS 2.1 spec. Therefore, we are joining efforts rather than introducing a new serie of headaches. However, by proposing implementation of MathML + Ian?s proposal the number of bugs to be fixed will be exponentially superior (own of new implementation + previous of CSS). And that even ignoring that MathML is contrary to both web design and WHATWG philosophy. > isn't something I'd call pretty even for simpler structures > (<fenced><fence>1</fence></fenced> or <radical><radix></ > radix><radicand>2</radicand></radical> for example). This makes the > markup a little counter intuitive and will probably prevent a consensus. I heard of proposal <sqrt>2</sqrt> = <radical><radix/><radicand>2</radicand></radical> Just compare markup for prescripts (e.g.) with prescripts markup in MathML, what is more intuitive? > The idea of a microformat isn't a so bad idea either. A microformat > does for HTML mostly what a namespace does in XML. The one really big > issue I expect is that it's going to make the syntax a lot more > verbose less pretty that it is currently (<span class="radical"><span > class="radix"></span><span class="radicand">2</span></span> anyone?). > I can understand why someone wouldn't want to take that route. See also additional points against microformats in two links that I cited in past message. > I think there is still a lot to be done and discussed and maybe the > WhatWG mailing list isn't the best place for that at this point. Isn't > this discussion delaying other important things in the spec? Nobody is obligated to participate in discussion, and people can focus in rest of spec in parallel threads I believe. > > Personally, I'm beginning to look at the problem from an other angle. > Instead of trying to support everything in mathematics, maybe we could > just improve what HTML currently offers by offering just a little > more. It's pretty easy to find elementary algebra formulas like this > one on the web: > > x<sup>2</sup> + y<sup>2</sup> = 1 and single fractions formated via tables also. > > But while you can express most of elementary algebra easily in HTML, > you can't do fractions. Something that's definitely missing for > elementary algebra is a construct capable of representing a fraction. > > So I propose that HTML 5 adds fractions, and only fractions. I think > there is a good consensus on how to markup a fraction. I believe > fractions can also be somewhat useful outside the realm of > mathematical formulas. And a fraction construct would encourage > implementors to fix their inline-block and vertical alignment CSS > bugs, opening the door to more CSS-based mathematical markup in the > future. If I remember correctly, the plea for the inclusion of *at least* fractions in HTML5 was already addressed by George in this list. Moreover, note once you have markup for fractions you can easily adapt it to others structures. This was my point. Reuse <table> <sup> and other stuff from HTML (such as people is really doing in practice) and introduce some basic constructs 1) fractions 2) sub-sup (basically are a ?modified fraction?) 3) under-over (basically are a ?modified fraction?) 4) roots (optional? Because some people prefer add the root entity to a radicand with overline) This implementation would be a kind of _tiny math_ and, I believe, nobody would be against this (no mathematicians) because obiously is cheap way to go beyond GIFs and can be shown that work aceptably well (specially when compared with MathML authoring using LaTeX or ITeX inputs). What does the rest of list think about this? Would not above four points be temporarilty implemented in the draft of the spec waiting for Internet community feedback? > I understand I'm ditching all of the more complicated stuff. I'm > retaining only the part that can work with the least effort, the part > with a simple undisputed markup, the part which I expect every author > and user will understand for what it means and which has the biggest > relevance inside and outside of the field of mathematics. Maybe more > can be added to HTML in the future, but if only one thing about math > is to be added to HTML 5, it obviously has to be the fraction. I agree. > I guess one argument against this is that it will constitue an > incomplete mathematical markup. But HTML is also incomplete for text, for graphics, for calendars, only let simple linsk... MathML is also incomplete. CML is also incomplete in its suport of chemistry, etc. > I'd point out that HTML is already > used as a simple (incomplete) mathematical markup with <sup> for > exponents. And it seems that even MathML fails at being a complete > mathematical markup. Yes, this is even recognized by MathML authors as Neil Soiffer. And do not forget Robert Miner (w3c MathML 2.0 editor) words also "MathML is not the way it is exclusively because of language design considerations -- it is the way it is because it was the politically feasible compromise between the many conflicting interests of the consortium members that had a stake is standardizing a markup for math notation." Henri Sivonen wrote: > > On Jun 19, 2006, at 19:12, Stefan G?ssner wrote: > >> Assuming the microformat solution will work -- and that it will work >> is already proven by George's implementation -- > > Did you actually look at George's implementation? It doesn't work. > Sorry for appearing rude, but someone has to say it: The baby is ugly. > > There are only stretchy brackets. No stretchy parentheses or braces in > sight. Also, the stretchy square root hack is just ugly. Fractions are > only used in display math, etc. I partially agree on square root. However, it look better that via native MathML support browsers (without downloading and installing special fonts). Whereas George approach will work for any font you desire you (or your users) will be forced to download and install new version of the browsers specifically compiled for new fonts in a future. Morever, improvements to roots rendering were listed here: SVG, SVG+CSS, CSS-Math extension. Sorry, but I do not know from where you obtained the rest of your comments. >> why should there be a reason then in one, two, three years to >> substitute the well working microformats with a new set of math >> related elements? > > I'd like to draw attention to Hixie referring to the Microformats > *process*. The Microformats process begins with defining the problem > and, in so doing, verifying that there is a problem, seeing if there > is a simpler problem and looking for prior art. Hum. 1) We know the problem (would I remember that first draft for math was presented in HTML3). 2) The prior art is already available, just needs to be developed 3) Microformats are not a panacea (see previous messages). > (As stated before, math typesetting special-cased for MathML is a > simpler problem than adding general-purpose features to CSS that can > be used to implement math typesetting. As for prior art, there is > MathML.) Developers prefer another couple of CSS rules rather than begin from zero with a unfriendly spec (MathML). Addition of general purpose features is defined in CSS 2.1 and may be addressed by brosers *in any case*. Last MSIE browser has incremented its native support for CSS 2.1 whereas continues ignoring MathML. The inline-block CSS bug in Firefox is scheduled and will be fixed in a future version. The CSS extensions for math are also scheduled by the w3c and will be needed in any way since MathML violates basic guidelines of web desing. Already MathML 1.0 did several presentational features deprecated in favour of CSS. Therefore, p-MatHML is a dead way, specially in next Tim Bray semantic web, presentational markup have no brilliant future. Since XSL-FO is not popular some day you will be forced to return to a CSS approach. Juan R. Center for CANONICAL |SCIENCE)

Received on Tuesday, 20 June 2006 05:26:23 UTC