W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2006

[whatwg] Mathematics in HTML5

From: White Lynx <whitelynx@operamail.com>
Date: Sat, 17 Jun 2006 17:16:40 +0400
Message-ID: <20060617131640.6E4CD244F7@ws5-3.us4.outblaze.com>
Michel Fortin wrote:
> Yes, sup/sub will work like in HTML. This behavior is not perfect  
> > in case
> > of resizable operators, fences, matrices and vectors however in  
> > this cases operator limits (llim/ulim) and fence markers (marker/ 
> > submark) provide necessary functionality.
> That's what I thought. I'm not sure I like the idea of expressing  
> exponents using either <sup> or <ulim> depending on what's preceding  
> it. 

Nor do I. I would prefer ISO 12083 model, but it does not work with CSS.

> I think all of this can be solved with one tiny change of paradigm.  
> Instead of having <fence> decide itself of its size (which doesn't  
> work with all kind of delimiters anyway), we could let the author  
> decide of the delemiter's size around <fence>. If we had a size  
> attribute, or something like that, with a list of predefined sizes  
> for for <fence>, authors could choose the appropriate size according  
> to the content.

It makes sense. One can add extra attribute to proposal.

>And, to return to my first point, elements following <fence> (like  
> <sup>) could be aligned according to the fence's size:
>      <fence size="medium">...</fence><sup>2</sup>
>      fence[size="medium"] + sup {
>          vertical-align: 5em;
>      }
> Fence markers could be implemented in a similar way, and then you  
> would no longer need a <fenced> element.

Adjacent sibling selector will match other things too.
Compare <fence size="medium">Base</fence><sup>2</sup>
and <fence size="medium">Content</fence>Base<sup>2</sup>.
Therefore you still need extra container like 'fenced'.

> It doesn't solve the thing for matrix though.


Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com

Powered by Outblaze
Received on Saturday, 17 June 2006 06:16:40 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:47 UTC