- From: Michel Fortin <michel.fortin@michelf.com>
- Date: Thu, 8 Jun 2006 15:56:03 -0400
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
michel.fortin at michelf.com
http://www.michelf.com/
Received on Thursday, 8 June 2006 12:56:03 UTC