Math WG Prioritized Requests

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="&lt;" 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