[whatwg] Mathematics in HTML5

Michel Fortin michel.fortin at michelf.com
Thu Jun 8 12:56:03 PDT 2006

Le 8 juin 2006 ˆ 4:24, White Lynx a Žcrit :

> Michel Fortin wrote:
>> Use <integral> and <bounds> for integrals.
>>      <integral>
>>        <bounds>
>>          <sub>0</sub>
>>          <sup>100<sup>
>>        </bounds>
>>        3<var>x</var> d<var>x</var>
>>      </integral>
> There are at least 30 different operators that would require  
> similar markup,
> following this line one will have to introduce separate elements  
> for all of them.

Well, not necessarily. We could just use a more generic name with a  
type="integral", type="sum", or type="product" attribute. In fact I  
think it'd be better with an attribute because it allows the  
construct to be easily extended in the future.

What would be useful is a list of these 30 or more operators, and  
usage cases, to figure out a markup that fits with all of them.

>> Summary
>> 16 new math-specific elements:
>> *  <frac>, <num>, and <den>
>> *  <radical>, <radix>, and <radicand>
>> *  <matrix>, <mr>, and <md>
>> *  <fence>
>> *  <bounds>
>> *  <integral>, <sum>, <product>
>> *  <limit>
>> *  <formula>
> What is the point is restricting scope of markup in this manner. Do  
> you think that some of the features in current proposal that are  
> omitted here are not realistic? If so why?

I didn't mean to restrict the scope. This wasn't a final proposal; I  
was simply expressing an idea which is still up to be enhanced and  
extended. But keeping an eye on how many elements we add to HTML is  
something important I think.

There is already some improvements and issues I can think of for this  

*  A way to disambiguate integrals over regions, since the region ought
    to be shown below the integral and not beside like with intervals.

*  <func> as a way to have functions in italic without calling them
    variables or using <i>. Could be used in a programming context too.

*  Maybe <limit> should be replaced by <lim>, as "lim" is the text  
that gets
    displayed. Or <operatior type="lim"> in a compatible way with other

*  I'm not fond of my syntax for bounded fences. Maybe something like  
    would be better (and more decent to style):

    (I omitted some <var> elements for more clarity)

      <fence>sin <var>x</var></fence>

      <fence>x + 1</fence>

    It looks a little like your syntax White, with <fenced> replaced by
    <bounded> and used only when bounds are defined.

*  I'd like less verbose radicals. But I'm not sure how well that  
could be
    styled (it's up to experiment):

    <radix>2n + 1</radix><radical>x</radical>

    ... the idea is that it should work even when <radix> is not  

*  It occurs to me that having an exponent denoted by <sup> just  
after a big
    fence may not be easy to style at the right height either unless  
we have
    an enclosing box.

>> 5 ruby annotation elements:
>> *  <ruby>
>> *  <rbc>, <rtc>
>> *  <rb>, <rt>, <rp>
> Ruby in its current form is not the best solution for mathematics.

You're right about the nesting argument. I didn't thought of that.

>> 3 reused HTML elements:
>> *  <var>
>> *  <sup>, <sub>
>> I think all of these new elements can be styled decently with CSS.
> Excluding Ruby (and partly markup for sums, products and similar  
> stuff).

Well, now that I think of it, there will be some problems with any  
pure CSS implementation (for current browsers at least, but maybe  
with CSS3 too). Aligning fraction separators correctly with the base  
line when <num> and <den> do not have the same height for instance: I  
don't see a way to fine-tune that without JavaScript.

About styling ruby: for the needs of mathematics, I think in the  
absence of proper ruby CSS support, styling them as inline-table  
would be suffisent. But, just like fractions, it would need  
JavaScript to do the baseline adjustment.

About sums and products: you're right on that. Without JavaScript to  
correct the horizontal alignment, bounds are not going to be pretty  
(I just tried). It's true for integrals, and bounded <fence> too.

But I would argue that my sum syntax, while requiring some JavaScript  
for proper display, use a more natural way of expressing things than  
yours. Look at this summation for example:

     </opgrp> 1+k

The upper limits comes before the lower one, obviously to be able to  
put it at the right place with CSS. But usually, while speaking, or  
even just thinking, we put the lower limit first: from k equals zero  
to n, or something like that. This makes this syntax easier and more  
natural to write and read:


Moreover, as things are in proper order, it makes it a lot easier to  
give a proper aural or linear representation of the formula.

Michel Fortin
michel.fortin at michelf.com

More information about the whatwg mailing list