Re: MathML and CSS

> So, what should a Math-CSS Module be intended for?
I think that goal of Math-CSS module should be to
add minimal number of CSS rules needed for rendering of basic math expressions. CSS2.1 with its inline-blocks, inline-tables, positioning schemes, floats and generated content is in fact quite powerful style language and from formatting point of view it can render complex math expressions. However comparing to LateX I think it drastically lacks text processing power and forces authors
to use verbose markup. One can try to compensate lack of CSS's text processing abilities by involving client side scripting ECMAScript/DOM (or innerHTML) in rendering. However this approach essentially slows down rendering process and makes it non-incremental (content is not rendered until page is fully loaded). So I consider
it to be ineffective http://geocities.com/csssite/ecmath.xml
Based on experience with pure CSS rendering I think that pure CSS approach is more convenient for reasons described at http://geocities.com/csssite/index.xml
See also related discussion on Opera webdesign forum
http://my.opera.com/forums/showthread.php?s=&threadid=36775
However CSS2.1 still is not perfect solution for rendering maths and I think that CSS3 should include Math module that will make it more convenient to display math expressions. In particular taking into account current limitations of CSS style sheets I think that we need at least several new CSS properties. In the same time I think that new properties
should not be 'ad hoc' additions targeted on maths only, instead they should increase overall rendering power of CSS. Here is possible scenario.

1. Many math objects are formatted as inline-tables (fractions, matrices, vectors, some under/over scripts etc.) which is OK, but the problem is that it is difficult to control vertical alignment of such a tables as for instance in case of fractions height of numerator/demonimator may vary that may affects vertical alignment of inline-tables. Unfortunately CSS3 selectors are not enough to distinguish
plain fractions from those that contain multi row objects 
(we don't have parent selectors) so to keep fractions aligned correctly one should either impose some nesting limitations, to add extra attributes that will distinguish between simple and complex fractions or to
make CSS vertical-alignment property more specific. I took a look t CSS3 text module and it seems that it is not enough control alignment
of inline-tables (it allows to align n-th line of inline block
with baseline of parent text but I don't see ability to do the same with
inline-tables, if I am wrong please let me know).
So I think it is useful to extend CSS vertical-align property
to make it possible to align fractions and indexed operators (that
may be formatted as inline-tables) correctly, regardless of 
numerator/denominator's height. One possible solution is to specify
vertical alignment by two values like
vertical-align:middle bottom;
and to apply vertical-alignment property not only to inline tables as 
a whole but also to table rows.
Such an extension will be useful not only for math expressions
but may be used in different ways by webdesigners.
Roughly speaking in case of fractions it will work like
<f>
<r>numerator</r>
<r>denominator</r>
</f>
f
{display:inline-table;}
r
{display:table-row;
text-algn:center;}
r:first-child
{vertical-align:middle bottom}
/* bottom of numerator must be aligned with middle of parent text 
(baseline + 0.5ex) */
This property will solve deep nesting problem.



2. Second suggestion that I think is useful is to add more border
styles. In particular those that will imitate braces.
Using current border styles and generated content one can
imitate large square braces 
(and round braces using border-radius property) but it is hard 
to imitate curly braces in matrices, cases, under/over braces
and similar expressions. So something like 
border-style:curly;
will be definitely useful and definitely can be used not only in mathematics
but in general webdesign too (I know that it is possible to do using
CSS3 image borders but I think using images in this way is not the best solution).

3. Third suggestions is to add new outline property.
outline-style:radical;
to imitate radicals. I think it should be outline because
in border has also border-bottom, border-left etc properties that 
does not make much sense in case of radicals. This is unfortunately
'ad hoc' solution targeted on mathematics.

4. Another thing that I think may be useful is to introduce
several new values for text-transform property.
Like text-transform:math; that will map plain Latin notations for
variables a,b,c ... to mathematical alphanumericals located 
in Unicode plane 1 (and possibly will make some other 
transformations like - to minus sign etc.) May be this is not 
really important for MathML community that prefers to use ugly
mi-mi-mo-mo tag soup instead of proper Unicode notations 
http://www.unicode.org/reports/tr25
but it is important for us and I think that CSS3 Math module
should include such a text-transformation properties.

What is said above applies to XML vocabulary that is more or less adopted to CSS rendering. MathML (both content and presentational) is not such. Here we have additional problems due to inappropriate data order (that however can be changed using XSLT or CSS3 generated content), smart resizing of operators (one may distinguish between different sized characters using extra markup (maybe just classes))
and exotic white-space handling. So in case of MathML one can take two approaches, either XSLT + CSS or even pure CSS. But in case of pure CSS rendering, MathML markup should be slightly enriched with classes (mainly needed to replace smart resizing of brackets and operators) and additional property value for white-space is needed.
Something like white-space:strip; that will strip extra white-spaces from
indented tags and will treat markup like
	<mi>a</mi>
	<mo>+</mo>
	<mi>b</mi>
as <mi>a</mi><mo>+</mo><mi>b</mi>

This is briefly my opinion on issue. If someone has any remarks we can
consider details further.


> Turning to the range of (b1)--(b2), I doubt that (b1) is really
> feasible in that there are significant mismatches (see below)
> between MathML and CSS. 

I completely agree, b2 is realistic approach.

> Alternatively, is it feasible to expect that the problem
> areas in full MathML be fixed-up by either client-side XSLT 
> or Javascript?

In principle involving JS one can render even LateX, but the problem is that both JS and XSLT are much less convenient then pure CSS. Already today we can do a lot of things with JS but is anyone really happy with this approach? 
So let us concretely identify all problems that prevent MathML from being merged into XML + CSS rendering scheme and let's see what we may loose. I think that essential part of presentational MathML (I know that there is also content MathML used by nobody) can be rendered with CSS3 + extensions proposed above, provided that it is slightly enriched with classes (I know that it is already verbose enough, but you guys does not seem to care about verbosity).

> The Bad would have to represent things like mglyph and
> maction, which simply don't fit (maction could perhaps be
> dealt with using Javascript).
> Ugly things are like the separators attribute of mfenced
> and mstyle.  It isn't clear how CSS selectors could cope
> with <mfenced separators=",;,,;,">...
> The mstyle element allows specifying the value of named
> spaces and also allows setting scriptlevel.
> (scriptlevel could otherwise be handled by relative sizing
> and inheritance).

But are these things really essential? Can't one just drop them and focus on basics?

>> (b2) to do just enough that mathematics can be presented, but that 
>> some/most MathML would have to be simplified before CSS stylesheets 
>> could describe it's presentation?
> And at the same time, accepting this would at least mean we abandon the 
> content-side of MathML. Where would we find, then, such great things as 
> synchronized content and presentation subtrees ? (this should all be 
> XHTML, SVG, or other CSS-supporting-platfom).
Content is content and is carried by markup language, 
while formatting is formatting and it is more convenient to handled it by style sheets. 'Synchronized content and presentation subtrees' sounds to naive for me, compare
<munderover>
<mo>&sum;</mo>
<mrow><mi>i</mi><mo>=</mo><mn>0</mn></mrow>
<mi>n</mi>
</munderover>
and
<msubsup>
<mo>&sum;</mo>
<mrow><mi>i</mi><mo>=</mo><mn>0</mn></mrow>
<mi>n</mi>
</msubsup>
They both carry the same semantics but have different formatting.
Is it your synchronisation? 

> Moreover, the "mathematical" nature of the math subtrees would be lost. 
> This would mean that copy and paste would be even more random and may 
> be an issue for accessibility... unless content (semantic) data would 
> be made available.
Don't see any problem here.
Semantics will be still carried by markup language.

> What can hosts of CSS (SVG, XHTML) offer for such embedding of semantic 
> content ?
MathML (not SVG or XHTML) will carry semantics.

>  (b) Should it leverage the core CSS, while minimally extending 
>      it with those unique constructs needed to present mathematics?
> It is worth noting that there are several existing data point that
> give an idea of what is currently possible.
> One is the JavaScript/CSS rendering produced by David Carlisle's XSL
> stylesheet, available from
>  http://www.w3.org/Math/XSL
XSL and JS based approaches are less convenient then pure CSS. And I think that we need math module in any case because event in case of JS/XSLT approach one has to format output with CSS.

> A couple of others:
> http://www.dcarlisle.demon.co.uk/mathmlcss
> implements as much presentation and Content MathML as I could manage in
> "pure" CSS2 with no javascript or xslt etc.
But there is significant difference between CSS2 and CSS3. 
You can't effectively render MathML with CSS2 because data order is too awkward (consider for instance prescripts, msubsup, munderover etc.) but CSS3 generated content allows you to rearrange data and apply style sheets
more effectively. So what is impossible in CSS2 will be possible within CSS3. However there still will be problems. The question is what are these problems and whether they can be addressed by extending CSS in realistic way.




-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

Received on Sunday, 16 May 2004 08:30:30 UTC