- From: Bruce Miller <bruce.miller@nist.gov>
- Date: Fri, 14 May 2004 01:04:20 -0400
- To: www-math@w3.org
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