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

[whatwg] Mathematics in HTML5

From: Řistein E. Andersen <html5@xn--istein-9xa.com>
Date: Sat, 17 Jun 2006 13:30:52 +0200
Message-ID: <E1FrZ0u-00044c-00@ws1.ou-data.net>
On 16 Jun 2006, at 2:27PM, White Lynx wrote:

>Oistein E. Andersen wrote:
>>The proposal states that <op> should be used to mark resizable operators, 
>>but this presumably does not mean that the size of such operators is actually >>intended to change.

>It is intended to be larger.

Yes, but the size is not intended to vary as a function of what follow the operator, is it?

>Since delimiters are not supposed to change meaning (matrix is matrix) issue is
>left up to style sheets. But if necessary appropriate attributes may be added to
>indicate delimiters explicitly, as you suggested.

>>[matrix, det, vector => generalised matrix?]

>This returns us to concept of ISO 12083 arrays. It makes sense, I just thought that
>more specific markup would be viable, but if necessary we can return to arrays.

Column vectors and perhaps even binomial coefficients can be regarded as a special kind of matrices; still, it is not necessarily a bad idea to provide specific mark-up for these.

My main concern is that we should not make arbitrary limitations. Sometimes, different vector-like entities are actually distinguished by their delimiters, as are e.g. a matrix, a determinant and a matrix norm.

>Some of ISO-12083 constructs that can not be encoded in MathML either.

Some of which probably should be added to MathML, but that is another issue.

>>font-family:[cursive] seems like a natural fallback mechanism for script. 

>Ok. But are Fraktur and caligraphic fonts actually marked as such?
>How browser will identify them?

As far as I know, no standard mechanism exists to indicate font classification. It is up to the browser to find (or let the user choose) appropriate fonts to use for general font-families like serif and cursive.

>>I tend to believe that a few `unsupported' constructions should be included
>>anyway if this is necessary in order to cover ISO-12083 (or whatever standard [...]
>>might be chosen).

>I would prefer not to include them explicitly. For example ISO-12083 allows any
>character as delimiter but of course not any charcater makes sense and not any
>characters is stretched by ISO 12083 implementations.

That is a good point. Without any restrictions, the only possible complete implementation would probably be one that deforms the characters used as delimiters in order that they fit into a rectangular shape of a pre-defined ratio. And if we limit the choice, the problem is to avoid `unnecessary' limitations.

The current proposal does not seem to include the following elements of ISO-12083:
    - <overline> and <undrline> [sic] (could be useful - feasible in CSS?)
    - <fence> with arbitrary delimiters (possibly not a good idea)
    - <box> (unnecessary?)
    - labelled arrows <subform> (what is this?)
    - spacing (intended to be handled without explicit mark-up)
    - character transformation _elements_ (fonts intended to be handled via Unicode or CSS)

A few other constructs have been omitted or modified, but without loss of expressive power, e.g. <post> is probably better encoded as <fence> with one empty delimiter as this allows the correct size to be found.

Is anything else missing? How well does presentational MathML cover ISO-12083?

-- 
Andersen
Received on Saturday, 17 June 2006 04:30:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:27 UTC