- From: Robert Miner <robertm@dessci.com>
- Date: Tue, 6 Nov 2007 12:47:57 -0800
- To: "Bert Bos" <bert@w3.org>
- Cc: <www-style@w3.org>

Hi. Thanks for taking time to meet with us yesterday. The prioritized list of requests we agreed to send follows. --Robert (for the Math WG) =================================================================== Executive Summary of Prioritized Requests for CSS3 from the Math WG =================================================================== 1. Keep the table-baseline property. This is used extensively in our current drafts in under and over scripts, and elements with both sub and superscript. 2. Some solution for stretching delimiters. Stretching of delimiters, e.g. parenthesis around a tall fraction, is fundamental to math layout, and apart from a few cases that can be faked with border properties, we have no good solution via CSS now. 3. Keep some version of the ::outside pseudo-element. Without this, we must require a large number of extra 'wrapper' rows in our markup. 4. Keep the white-space-collapse property. MathML markup typically is generated with whitespace between elements that is not intended for literal rendering, since it tends to be verbose. It would be painful to require that authors be responsible for removing that whitespace. 5. Introduce content sensitive selectors. Spacing around operators (and a number of other properties) is intended to be set by looking up the operator in a table in the MathML rendering model. Without content sensitive selectors, this means many attributes typically left unspecified in normal MathML markup must be explicitly set for use with CSS. =================== Detailed Discussion =================== ------------------------- 'table-baseline' property ------------------------- 1. 'table-baseline' property. Property was discussed on Mountain View F2F last year: http://lists.w3.org/Archives/Member/w3c-css-wg/2006OctDec/0023.html CSS WG decided to include property in tables module. We just want to remind that MathML for CSS profile essentially relies on this property and we use it to specify baseline of munderover, mover, msup, msubsup and mmultiscripts layout schemata, all these schemata can be formatted as multirow inline-table and having property that defines which row is baseline of inline-table is crucial. Formally property can be defined as follows: Name: table-baseline Value: <integer> | inherit Initial: 1 Applies to: inline-tables Inherited: no Percentages: N/A Media: visual Computed value: specified value (except for initial and inherit) The 'table-baseline' property determines which row of a inline-table should be used as baseline of inline-table. <integer> Baseline of nth row (as determined by the integer value) is baseline of inline-table. Value 1 corresponds to first row and is initial value. Negative values are allowed, -1 corresponds to last row of inline-table, -n stands for nth line from the bottom. If absolute value of property is larger then number of rows in inline-table then initial value should be used instead. If value is 0 then bottom margin edge of inline-table should be treated as baseline. There is experimental implementation of property in Opera 9.5 (-o-table-baseline). Usecase for table-baseline property: Formatting of munderover, mover, msup, msubsup and mmultiscripts elements. Consider formula that involves under and overscripts <math xmlns="http://www.w3.org/1998/Math/MathML"> <mi>baseline</mi> <munderover> <mi>Base</mi> <mi>underscript</mi> <mi>overscript</mi> </munderover> <mi>baseline</mi> </math> under and over scripts can be handled using CSS munderover {display:inline-table; text-align:center; table-baseline:2;} munderover > * {display:table-row} munderover > * + * {font-size:0.7em} munderover > * + * + * {display:table-header-group} Without table-baseline property, it would be very difficult (in some cases impossible) to achieve proper vertical alignment of complex math formulae. For example workaround for the case of munderover schemata would look like <math xmlns="http://www.w3.org/1998/Math/MathML"> <mi>baseline</mi> <munderover> <maction> <mi>Base</mi> <mi>overscript</mi> </maction> <maction> <mi>underscript</mi> <mi>Base</mi> </maction> <maction> <mi>overscript</mi> <mi>underscript</mi> </maction> </munderover> <mi>baseline</mi> </math> with CSS munderover > maction:first-child + maction {display:inline-table; text-align:center;} munderover > maction:first-child + maction > * + * {display:table-row;} munderover > maction:first-child + maction > *:first-child {display:table-footer-group; font-size:0.7em;} munderover {display:inline-block; text-align:center;} munderover > maction:first-child {display:block; font-size:0.7em;} munderover > maction:first-child > *:first-child, munderover > maction:first-child + maction + maction {display:none;} Such workaround is clearly unacceptable as markup is horrible. The same argument applies to mover, msup, msubsup and mmultiscripts. So we badly need the way to control baseline alignment of inline-tables and hope that table-baseline property will be adopted soon. ------------------------- Stretching of delimiters ------------------------- 2. Stretching of delimiters. MathML formatters need some way to define stretching of delimiters such as brackets, this could be either some glyph stretching or some equivalent functionality that would alow to draw delimiters around containing block, either as predefined list of outline styles or some SVG like way to draw simple paths around container. Usecase for delimiter stretching. Consider stretchy braces: <math xmlns="http://www.w3.org/1998/Math/MathML"> <mfenced left="<" right=">"> <mfrac> <mi>a</mi> <mi>b</mi> </mfrac> </fence> </math> They can be formatted using hypothetical CSS: mfenced {display:inline-block;} mfenced:before, mfenced:after {content:attr(open); glyph-stretch:100%}/*refers to height of line box */ mfenced:after {content:attr(close);} In case one does not want to mess with font-formats, alternative could be to define some kind of delimiter drawing mechanism. For example: mfenced {display:inline-block; position:relative; padding:0 1ex;} mfenced:before, mfenced:after {content:"\A0"; width:1ex; height:100%; path-width:thin; top:0;} mfenced:before {left:0; draw:path('M100%,0 L0, 50% L100%, 100%');} mfenced:after {right:0; draw:path('M0,0 L100%, 50% L0, 100%');}/* one can use simple subset of SVG paths or define alternative syntax */ I know there is opportunity to use image-borders but one of the problems with images is that they don't inherit colors from document. ------------------------ ::outside pseudo-element ------------------------ 3. ::outside pseudo-element CSS3 generated and replaced content module contains ::outside pseudo-element. It is important for us, as MathML allows implied mrow containers to be omitted in many cases. Omitting those containers is reasonable from structural point of view, but creates problems when formatting markup with CSS, partly because missing containers make parts of formulae effectively unstylable (often affected schemata involve some table elements and omissions can not be compensated by anonymous table objects). Currently MathML for CSS profile requires mrow containers to be used explicitly in all such cases, but this requirement is confusing for average user, breaks compatibility with MathML 2.0 markup and might negatively affect adoption of the profile. Therefore we would like CSS WG to keep ::outside in CSS. Usecase for ::outside pseudo-element. Nesting of mmultiscripts Consider formula with prescripts: <math xmlns="http://www.w3.org/1998/Math/MathML"> <mmultiscripts> <mi>A</mi> <mprescripts/> <mi>B</mi> <mi>C</mi> </mmultiscripts> </math> Prescripts case can be handled with the following CSS: mmultiscripts {display:inline-table; line-height:0.7em; table-baseline:2;} mmultiscripts > * {display:none;} mprescripts + *, mmultiscripts > *:first-child {display:table-row;} mprescripts + * + * {display:table-header-group;} mmultiscripts > *:first-child:before {display:table-cell; content:"\A0";} mmultiscripts > * + * {font-size:0.7em;} none {content:"\A0";} It's tricky because prescripts appear after base in markup, while their inflow position preceeds base. So stylesheet involves interaction between anonymous table objects and generated content. Since anonymous table objects are effectively unstylable this construction works only in simple cases, nested prescripts like the ones below are broken: <math xmlns="http://www.w3.org/1998/Math/MathML"> <mmultiscripts> <mi>A</mi> <mprescripts/> <mmultiscripts> <mi>B</mi> <mprescripts/> <mi>D</mi> <mi>E</mi> </mmultiscripts> <mmultiscripts> <mi>C</mi> <mprescripts/> <mi>F</mi> <mi>G</mi> </mmultiscripts> </mmultiscripts> </math> One can solve issue by requesting users to wrap nested schemata into extra mrow containers: <math xmlns="http://www.w3.org/1998/Math/MathML"> <mmultiscripts> <mi>A</mi> <mprescripts/> <mrow> <mmultiscripts> <mi>B</mi> <mprescripts/> <mi>D</mi> <mi>E</mi> </mmultiscripts> </mrow> <mrow> <mmultiscripts> <mi>C</mi> <mprescripts/> <mi>F</mi> <mi>G</mi> </mmultiscripts> </mrow> </mmultiscripts> </math> But this make markup more verbose and confusing for average user. Having ::outside pseudo-element would allow us to replace unstylable anonymous table object with stylable containers and avoid nesting problems. ----------------------- White-space-collapse ----------------------- 4. MathML white-space collapse mechanism requires white space characters that appear between token elements to be removed (in addition leading and trailing spaces in token elements are removed). This behaviour is not covered by CSS 2.1 white-space-collapse model, it is partly addressed in CSS3 by introducing white-space-collapse property, it is important to keep this property in CSS (we need white-space-collapse:discard; for space between tokens) and if preferably add possibility to remove leading and trailing spaces inside *inline* elements (something like white-space-collapse:discard-trailing). Use case for white-space-collapse: MathML requires any space characters that appear between token elements to be removed. This implies that <math xmlns="http://www.w3.org/1998/Math/MathML"> <mn>2</mn> <mo> + </mo> <mn>2</mn> <mo> = </mo> <mn>4</mn> </math> is treated like <math xmlns="http://www.w3.org/1998/Math/MathML"><mn>2</mn><mo>+</mo><mn>2</mn><mo>=</mo><mn>4</mn></math> CSS2.1 white space processing model does not cover this case. However CSS3 white-space-collapse property is useful for us as it can at least collapse spaces between token elements: math {white-space-collapse:discard} mn, mo, mi, mtext, ms {white-space-collapse:collapse} Further extension of property to allow discarding leading/trailing spaces in token elements would be useful. ------------------------------------- Content sensitive selectors ------------------------------------- 5. Content sensitive selectors Spacing between MathML operators as well as some stretching and sizing properties often depend on content of mo token elements (in accordance with operator dictionary). CSS3 had :contains() selector that could help us to define content sensitive formatting of token elements. Unfortunately this selector was removed, even so some CSS rendering engine support it (Prince XML formatter). It would be nice to restore property in some form. Usecase for content sensitive selectors Consider example: <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>(</mo><mi>a</mi><mo>+</mo><mi>b</mi><mo>)</mo></math> In MathML some operators require extra spacing to be added before/after them, some don't. One way to distinguish these cases is to use content sensitive selectors: mo:contains("+") {padding:0 0.5ex;} another case is to use explicit attributes <math xmlns="http://www.w3.org/1998/Math/MathML"><mo fence="true">(</mo><mi>a</mi><mo>+</mo><mi>b</mi><mo fence="true">)</mo></math> mo {padding:0 0.5ex;} mo[fence="true"] {padding:0;} Using explicit attributes puts extra burden on user and bloats markup so we would prefer :contains() selector to be retained in some form. Robert Miner Vice President, Research and Development Design Science, Inc. 140 Pine Avenue, 4th Floor Long Beach, California 90802 USA Tel: (651) 223-2883 Fax: (651) 292-0014 robertm@dessci.com www.dessci.com ~ Makers of MathType, MathFlow, MathPlayer, WebEQ, Equation Editor, TexAide ~

Received on Tuesday, 6 November 2007 20:50:00 UTC