W3C home > Mailing lists > Public > www-math@w3.org > April 2006

RE: Technical reasons for some options taken on design of MathML

From: White Lynx <whitelynx@operamail.com>
Date: Sat, 15 Apr 2006 19:02:08 +0400
To: "Robert Miner" <robertm@dessci.com>
Cc: www-math@w3.org
Message-Id: <20060415150208.4F8937B5E3@ws5-10.us4.outblaze.com>

> Over the last couple of years, this Math IG, and Bruce Miller in
> particular, spent a lot of time and effort talking to the CSS working
> group about possible enhancements to CSS to help with math rendering.
> That was done with MathML in mind, but the bulk of the discussion
> focused on abstract rendering properties.  Moreover, Bert Bos, who has
> long been involved with CSS work at W3C is now the staff contact for the
> Math activity.  In the end, the CSS group concluded it didn't want to
> add anything special to CSS 3 for math support.  To really do math
> typography "right" would require too much work, and none of the more
> feasible half-measures seemed worth it.  That is an over-simplification,
> and CSS is still open to hearing proposals.  But basically, we should
> think in terms of doing math with what is there now, and possibly with
> the generic enhancments proposed for CSS 3.  However, unlike the native
> browser situation, I think there really is still room for progress with
> this approach.
At the moment the main problems is CSS support in browsers and not limitations
of CSS. The fact that CSS does not have math oriented proprties makes it slightly awkward for formatting maths, however the basic functionality needed to format formulae is available, at least when it comes to complex inline layouts CSS works (both theoretically and practically in UAs that support CSS properly), the problems arise on glyph level (stretching of characters, kerning, spacing, applying accents) which is considered to be outside the scope of CSS (applying accents is in the scope of Unicode standard that defines set of combining diacritical marks for this purpose, kerning is left up to font designers and is not adjustable via CSS, spacing is left up to authors or authoring tools, stretching is a problem but in some cases it is sufficient to resize operators, in some cases like large brackets one can use CSS generated content to assemble glyph from multiple Unicode fragments, one may employ SVG in CSS generated content etc, so it is solvable).
Thus at the moment the problem is not in CSS specs but in implementations.
Developers of Prince formatter quite quickly managed to tackle all CSS bugs that affected rendering of complex inline CSS layouts needed to format mathematical formulae, in Opera it took about three years.
Safari is good candidate to become next, but how long it will take to fix existing bugs and implement missing properties in Mozilla and MSIE is a difficult question. Generally speaking they are expected to deliver full CSS2.1 support (one of the ideas behind CSS2.1 was to simplify and clarify CSS2 in order to reach concensus among browser developers and to get specification which is interoperably implemented). On practice it may take several years to gain really interoperable CSS2.1 implementations.




> Given that background, my questions to you are:
> 1)  If you focus solely on doing the best cross-platform CSS+JavaScript
> rendering of math possible, what should the markup for the math in the
> page look like? Divs and spans and tables?  Some other collection of
> math tags?
I assume that you transform MathML into "something" on server side and
are asking what this "something" should be to make all browsers happy.

Taking into account that MSIE and Mozilla do not support CSS inline-tables model and you ask for cross browser solution then unfortunately you will end up with quite dirty HTML+CSS output with some tables, spans etc. JavaScript may be avoided if you'll drop maction element.

This approach is very ineffective if you want to achieve good quality, 
in particular printing quality. So I would not recommend HTML + CSS approach 
unless formulae are relatively simple (simple indices, some fractions which are not deeply nested and do not carry complex content, simple under/overscripts, matrices).

In this respect it is better not to invest much time in this approach as at
some point when we get'll decent rendering engines most of hacks and workaround 
for current bugs will become unnecessary.



> 2)  If you focus solely on changes to MathML that would improve
> CSS+JavaScript rendering of it, what would those changes be?  
First of all I would distinguish CSS+Javascript rendering and pure CSS rendering.
Second it depends on what you want to achive, just rendering or rendering plus
retaining original documnet tree. In case of CSS+Javascript approach, assuming that document tree modification are OK, you don't need to worry as markup processing capabilities of JavaScript are more then sufficient to eliminate difference between "CSS unfriendly" MathML and any "CSS friendly" markup.
In case of pure CSS rendering (which is fast, incremental and does nor affect document tree) there is are a lot of things to be changed in MathML.

> Redoing the table model and ellimiating mfenced?  
Replacing mtable with content MathML stuff like matrix, determinant, piecewise
helps a lot or at least changing CSS unfriendly markup like 
[<mtable>...</mtable>] or <mfenced open="[" close="]"><mtable>...</mtable></mfenced> 
with something like <mtable open="[" close="]">...</mtable>.
Eliminating separators attribute of mfenced would also help. 
> Replacing mmultiscripts with something else?
Yes mmultiscripts is too awkward for pure CSS rendering. You may try something like
<mpsup><mi>prescript</mi><mi>Base</mi></mpsup>
<mpsub><mi>prescript</mi><mi>Base</mi></mpsub>
<mpsupsub><mprescripts><mi>prescript</mi><mi>prescript</mi></mprescripts><mi>Base</mi></mpsupsub>
for prescripts.
> In other words, what is the short list of things that
> were most problematic about MathML for CSS rendering?

Indices produced via msubsup may be replaced with 
<msupsub><mi>Base</mi><mindices><mi>sup</mi><mi>sub</mi></mindices></msupsub>
<!-- 
Who complained abou verbosity? Was it me? In this case try 
	Base<mindices><mi>sup</mi><mi>sub</mi></mindices> 
-->
Replacing 
<mover>
<mi>Base</mi>
<mi>overscript</mi>
</mover>
with 
<m_over>
<mi>overscript</mi>
<mi>Base</mi>
</m_over>
and removing munderover (can be achived by nested munder and mover) would help.
This is brief summary, if MathML community will tolerate such a changes then one can discuss technical details, write style sheets, DTDs and demo pages.

  

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

Powered by Outblaze
Received on Saturday, 15 April 2006 15:00:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:12:58 GMT