[whatwg] Mathematics in HTML5

[Øistein E. Andersen]

On 14 Jun 2006, at 11:8AM, White Lynx wrote:

>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?

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.

Finally, the nested <under>/<over> construction does not strike me as particularly elegant. Would it be possible to use something like <overunder><top><overbrace><base><underbrace><bottom></overunder> to replace both <under> and <over>?

>><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?)

>><cases>
>><var>n</var>/2,<scope>if <var>n</var>is even
>>3<var>n</var> + 1,<scope>if <var>n</var>is odd</cases>

>Should be 
>	<cases>
>	<case><var>n</var>/2,<scope>if <var>n</var>is even
>	<case>3<var>n</var> + 1,<scope>if <var>n</var>is odd
>	</cases>

Yes, of course. Thanks for notifying me.

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

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

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.

>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. Double-struck could possibly be rendered as bold, but this is of course not ideal. Anyway, the lack of fallback should not necessarily imply that the property must be abandoned.

>Others (sans-serif , sans-serif bold , sans-serif slanted, sans-serif bold slanted)
>can be added. Should they be added as a separate properties, or we should redefine current
>properties to behave appropriately when combined with font-family:sans-serif; (both make sense)?

Yes, both probably make sense unless serif and sans-serif symbols are used to carry different meanings.

>>A font-family
>>for Fraktur should probably be added to CSS anyway, as it would be useful not only for
>>mathematics.

>Makes sense. On the other hand unlike generic font-families like serif,  sans-serif and
>monospace Fraktur is used for limited number of Unicode characters.

The font-families serif, sans-serif and monospace apply to Latin, Greek and Cyrillic, but probably not to other parts of Unicode: Chinese ideograms are always monospaces, Arabic serif does not make much sense, etc.

As for cursive and fantasy, only Latin letters get distinct fonts for these in my browsers.

Fraktur probably has no tradition outside the Latin alphabet, but it is not limited to the English letters a-z; German letters like ä, ö, ü, ß, as well as Scandinavian ones like ø and æ would be needed, and these are not available as maths symbols (and even if they were, they should obviously not be used for running text.) An old-style Church-Slavonic font would probably be the `equivalent' for Cyrillic if an appropriate font-family name can be found, but this is rather off-topic.

>Also I am not sure whether Fraktur fonts are marked as such.

?

>>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? 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).

-- 
Andersen