[whatwg] Mathematics in HTML5

Fri Jun 16 06:27:12 PDT 2006

Oistein E. Andersen wrote:
>>Quotes from "Wikipedia TeX in HTML5" http://xn--istein-9xa.com/HTML5/WikiTeX.pdf
>>2.5 Big operators
>>Remark: Is the following the intended use of under/over and opgrp?

>Yes. In fact I would be more appropriate to use the same markup for both and
>control rendering (under/over vs. sub/sup) via style sheets, but since 
>it is impossible to have reasonable markup that admits both presentations
>(due to limited capabilities of CSS2.1) the only option is to allow both 
>possibilities.

> In that case, what would drive an author to use <opgrp> instead of the more familiar <sub>/<sup> construction? 
> Is the rendering intended to be different?

Yes, sub/sup will behave like HTML sub/sup with offsets being based on font size like it is currently
done in HTML implementations, while llim/ulim and marker/submark will have offsets based on size of their base
(operator, fence, matrix etc.) not font size like in case of HTML sub/sup elements.

> 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. If necessary separate element may be used for the rest of operators like "lim"
that are not resized.

> Finally, the nested <under>/<over> construction does not strike me as particularly elegant. 

Completely agree.

> Would it be possible to use something like <overunder><top><overbrace><base><underbrace><bottom></overunder> 
> to replace both <under> and <over>?

The problem is on CSS side. Try to align baseline of base element in this markup with baseline of parent, 
in general it is impossible in CSS2.1.

>><fence left="solid" right="solid">
> >><matrix><row><cell><var>x</var><cell><var>y</var>
> >><row><cell><var>z</var><cell><var>v</var></matrix></fence>
> 
> >This will draw second fence around matrix (apart of that which already is part of matrix).
> 
> What kind of delimiters are supposed to be used? (Indicated in CSS?)
> 

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.

>>Remark: Should the scope node be optional?
> 
> >Maybe. Do you have some concrete examples in mind?
> 
> Not really, but I believe that such constructs sometimes occur without the second part, 
> and I believe that the mark-up should be as flexible as possible on this point.

Ok. Let's make scope optional.

>><vector><entry><var>a</var><var>b</var><entry><var>c</var></vector>

>Note that vector includes fences. So what you need will probably require
>extra markup.

> I hope you do not mean that a <vector> is always a column matrix delimited by round parentheses. 
> Delimiters like \left[  ... \right] and even \left| ... \right. are sometimes used. 
> A generalised <matrix> could possibly replace the current <matrix>, <det> and <vector> constructs.

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.

> More generally, the advantage is basing HTML5 Maths on ISO-12083 is completely lost if constructs that 
> can be expressed in ISO-12083 cannot be encoded in HTML5 Maths.

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

>The problem with some of them (script, bold script, Fraktur, bold Fraktur, double-struck symbols) 
>is that there is no natural fallback for browsers that does not support
>plane 1.

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

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

> Anyway, the lack of fallback should not necessarily imply that the property must be abandoned.

Agree.

>>>Problem: These delimiters /*ed. mainly arrows*/ do not seem to be supported in
>>>current proposition.

>>The problem is related to fallback CSS rendering.

> Should HTML5 Maths be strictly limited to what is currently possible in pure CSS? 

Basic functionality probably should fit in XML + CSS. 

> 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 we 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.
So I don't know whether to allow everything available in Unicode, everything used in TeX or AAP Math DTD (both have list of 
stretchy delimiters) or everything that can be handled with CSS? I prefer third option, but I am not sure.

Oistein E. Andersen wrote:
>>Quotes from "Wikipedia TeX in HTML5" http://xn--istein-9xa.com/HTML5/WikiTeX.pdf
>>2.5 Big operators
>>Remark: Is the following the intended use of under/over and opgrp?

>Yes. In fact I would be more appropriate to use the same markup for both and
>control rendering (under/over vs. sub/sup) via style sheets, but since 
>it is impossible to have reasonable markup that admits both presentations
>(due to limited capabilities of CSS2.1) the only option is to allow both 
>possibilities.

> In that case, what would drive an author to use <opgrp> instead of the more familiar <sub>/<sup> construction? 
> Is the rendering intended to be different?