[whatwg] Mathematics in HTML5

[juanrgonzaleza at canonicalscience.com]

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)