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 syntax:

*  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
   operators.

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

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

   <bounded>
     <fence>sin <var>x</var></fence>
     <bounds><sub>0</sub><sup>1</sup></bounds>
   </bounded>

   <bounded>
     <fence>x + 1</fence>
     <bounds><sub>0</sub><sup>1</sup></bounds>
   </bounded>

   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 present.

* 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>
      ∑
      <ulim>n
      <llim>k=0
    </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:

    <sum>
      <bounds>
        <sub>k=0</sub>
        <sup>n</sup>
      </bounds>
      1+k
    </sum>

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
[EMAIL PROTECTED]
http://www.michelf.com/


Reply via email to