[whatwg] Mathematics in HTML5

[White Lynx]

Oistein E. Andersen wrote:
> As a first step, I have tried to transform the TeX code used on 
> Wikipedia (http://en.wikipedia.org/wiki/Help:Formula) into HTML5.
> This raises some issues, see http://xn--istein-9xa.com/HTML5/WikiTeX.pdf for 
> all the details. I have tried to follow the current proposal, but I have probably 
> misinterpreted a few things. Do correct me!

Nice summary. Sorry for late reply, I was travelling.

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

> Remark: The current proposal requires at least two rows and at least two columns. This
> makesitimpossibletodefineacolumnmatrixasamatrix(thevectorconstructisprobably
> meant to handle these), and completely impossible to define a row matrix

This requirement can be safely removed, there are no XML or CSS motivated restrictions 
in this area.

> Remark: Presumably, the det element is intended to replace matrix here, but the ra-
> tionale seems unclear. Two kinds of brackets are not su?cient anyway, so the distinction
> would be purely semantical.

Yes, destinction is purely semantical. 

> <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).
If it is necessary to hardcode matrix fence styles in DTD then it would be more appropriate 
to add couple of attributes to matrix element, like you already proposed:

> Remark: Matrices tend to be surrounded by brackets of some sort. If technically feasible,
> it would therefore be convenient to indicate the left and right attributes directly on the
> matrix element.

	<matrix left="solid" right="solid"><row><cell><var>x</var><cell><var>y</var>
	<row><cell><var>z</var><cell><var>v</var></matrix>

matrix fences will be considered as intrinsic part of matrix and will not requre
extra fence element.


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

> Remark: Should the scope node be optional?

Maybe. Do you have some concrete examples in mind?


> 3.4 Other constructs
> ...
> <vector><entry><var>a</var><var>b</var><entry><var>c</var></vector>
> Remark: Do we really want to mark up this as a vector?

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

> ...
> Remark: Should we rather suggest an HTML table here?

Either HTML table (in this case table should be allowed inside inline elements)
or maybe separate element with inline-table functionality (table is probably better as
some things like colspan, rowspan attributes can not be reproduced via XML+CSS). 
In fact it would be nice to more semantic markup here, but since it is hard to make 
such a markup comprehensive then maybe it is better to allow tables. 

> The current proposal suggests the introduction of text-transform rules to facilitate the
> input of MAS characters and make HTML5 usable whilst plane 1 is still not fully imple-
> mented in browsers. This approach would seem to require 13 rules, and not only 3.

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

> 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. Also I am not
sure whether Fraktur fonts are marked as such.

> Remark: The current attributes on the fence element do not permit constructions like 
> ]0, 1/2]

Such a constructions can be added to proposal if necessary.

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

The problem is related to fallback CSS rendering.

> Remark: Explicit indication of delimiter size not supported

One can add values like medium, large, x-large, xx-large to current proposal.
Personally I like ISO 12083 sizeid attribute that sets size of fence equal to
size of subexpression with id specified by sizeid attribute. It does not work 
however in XML+CSS approach, therefore your suggestion to indicate size explicitly
makes more sense.





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

Powered by Outblaze