Re: MathML and CSS

White Lynx

I agree with most of your comments on what should (or could) go into a
css3 math module, as summarised by this quote:

    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.

However a few comments on specific points



   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.


I agree some better access to the character content from CSS selectors
would make things easier for MathML. Substituting - signs etc, as you
say.

The reference to TR25 there is rather strange, TR25 (which is of course
later than all but the last version of MathML) is closely aligned with
MathML and MathML tracked TR25 through various revisions in the exact
definition of the variant selector and other things listed in that
report. The one part of TR25 that doesn't relate to MathML is its
somewhat speculative suggestion of a "plain text" unicode mathematics,
such a system would of course be completely unstylable with CSS, as what
you call "ugly tag soup" is what some of us would rather call markup,
and it's that markup that would be needed for any CSS3 math module to
hook into via css selectors isn't it?


    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

Yes that is the main aim of this initial round of discussion, to try to
find some balance between subsetting mathml (if necessary) and
extending CSS (if desirable).

   I think that essential part of presentational MathML

Presentation MathML is an obvious first step, however Content MathML is
also important. Mozilla can get by without it in its native renderer as
its client side XSLT offers a rendering mechanism, but as has been
mentioned, such a transformational approach does complicate more dynamic
interaction with the formula. However one may assume that some of the
platforms for which one might want to target a CSS based approach don't
have the benefits of an XSLT engine. As Stan has said it is possible to
render Content MathML in a legible way without doing too much tree
reorganisation if one accepts a prefix notation for many operators,
this may be sufficient (I think it is sufficient for a "CSS-only"
rendering). 


   (I know that there is also content MathML used by nobody)

Strange you say that. Have you ever saved MathML from Maple for example?


   ... mfenced ...

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


<mfenced separators=",;,,;,"> is clearly not essential (although at
least the form with a single character in the separators attribute
would be useful, but mfenced is a special case. It is specified in the
MathML rec as being equivalent to a specific construction of an mrow
with certain mo operators to denote the fences and separators. However
it is (I think) unique in MathML: no presentation construct other
than mfenced is explicitly a shorthand for some longer construct.


   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,

Please see chapter 5 of the mathml spec to see what is meant here.



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

Yes exactly. The point of my experiments there (which do already use a
bit of css3 namespace support, as I recall)  was not to show that MathML
(or any other Math markup) could be rendered by fully by CSS2 but rather
to see how far one could get. Actually I was pleasantly surprised by how
far one could get, which means that I think that it is possible to have
a relatively small focussed Math extension module in CSS that would
allow  mathematical layout. It seems to me that the main things
required to get mathematical layout (from any markup) would be the
following, all of which are mentioned in your list as well:

stretchy characters (horizontal and vertical)
radicals
baseline control

If just those three things were added, it would already be useful I
think.

If you look at being able to do MathML specifically then it would be
good to have in addition selectors that have access to element content,
I don't know how feasible that is in a CSS context. For example one
can't really implement an "operator" dictionary in CSS2 (I think) where
the default spacing around an <mo> depends on its character content.
I don't know if any of the currently planned CSS3 extensions would
support such a thing?

Then there are some specific layout forms (such as mmultiscripts) 
which although they could use an inline table model for layout have the
data specified in a different order. I don't have a good enough feel for
the kinds of display types envisioned in CSS3 to know whether something
could be done here or whether you would need to profile mathml and say
prescripts were not supported (or specify some non-conventional but
legible rendering of the mmultiscripts construct that _could_ be
supported by css). Your message seemed to indicate that you thought
that the CSS3 facilities _would_ be strong enough to do this kind of
localised data re-arrangement. That would be very useful for math
layout, Is there an existing CSS3 module that I should re-read?


David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Received on Tuesday, 18 May 2004 07:22:03 UTC