MathML and CSS

Hello All;

The Cascading Style Sheet (CSS) Working Group of W3C is working 
towards a third, modular, version of CSS.  That presentation of
mathematics has unique needs is recognized and a Math-CSS module 
is to be included.  In trying to contribution to the development
of this module, it became clear that there are several distinct 
approaches to what such a module should cover.

Before investing the work in writing up several full, potentially
useless, specifications, we felt we should solicit the opinions
of the community.  The goal, of course, should be to specify
something that fulfills a need and is not so overly complicated
as to end up ignored.  We would rather see something that
helps enable `math on the web' rather than hinder it.


So, what should a Math-CSS Module be intended for?
 (a) Should it apply only to native MathML implementations,
     providing a means to fine-tune, or override, the styling?
or
 (b) Should it leverage the core CSS, while minimally extending 
     it with those unique constructs needed to present mathematics?

Under case (b) one has the further question of whether at one
extreme
 (b1) to do all that is necessary to support MathML completely
      and specifically?
to the other
 (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?


Please keep in mind the rather distinct histories of both MathML
and CSS, and that CSS, in particular, is not a programming language.


My personal view on the cases, not to bias but spur discussion:

(a) seems to be a rational interpretation, but mostly pointless.
Most general CSS styling already applies to MathML.  A few
extensions could be useful, but one runs the risk of conflicts
with the styling embedded in the MathML markup and inadvertently
changing the implied meaning.

(b) is appealing in that it suggests a route where browsers
could support MathML (or some kind of math) with significantly
less effort that a full implementation of MathML.
  Of course, this would only be true if it _were_ less effort,
and that the implementors did it!

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. Further along the range, we have to
ask whether a `Subset MathML' is something the community could
accept?  Alternatively, is it feasible to expect that the problem
areas in full MathML be fixed-up by either client-side XSLT 
or Javascript?

The Good, The Bad and the Ugly:

CSS's box model, especially with some of the current developments
(inline tables, etc), covers a lot of the needs. Baselines
(in contrast to width and height) needs better support, as do
fonts in general, and especially stretchy fonts.  
In some cases, we would wish to be more assertive than CSS
generally is: we _must_ have a font with these properties
(similarly for  positioning and the size of empty elements).
These sort of issues may not be so far from the current CSS
way of thinking that they can be incorporated.

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

Oh, and of course the operator dictionary, even if it
could be handled by CSS rules, _should_ it be?

That's not a complete list of problem areas, but illustrative.

Thanks; I'm looking forward to your input.
Bruce Miller

-- 
bruce.miller@nist.gov
http://math.nist.gov/~BMiller/

Received on Friday, 14 May 2004 01:09:38 UTC