From: David Carlisle <davidc@nag.co.uk>

Date: Tue, 18 May 2004 12:21:05 +0100

Message-Id: <200405181121.MAA02130@penguin.nag.co.uk>

To: whitelynx@operamail.com

Cc: www-math@w3.org

Date: Tue, 18 May 2004 12:21:05 +0100

Message-Id: <200405181121.MAA02130@penguin.nag.co.uk>

To: whitelynx@operamail.com

Cc: www-math@w3.org

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 GMT

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