Math WG comments on latest CDF documents

The Math Working Group has reviewed the current drafts of the CDF documents:

·         WICD Core 1.0

·         Compound Document by Reference Framework 1.0

·         WICD Full 1.0

·         WICD Mobile 1.0

We remain concerned that the issues raised in The Math Interest Group's comments posted by David Carlisle on January 27 haven’t been addressed. The most critical issue with regard to MathML in compound documents is the lack of support for aligning the baseline of child elements with that of enclosing text, or even mandating that width and height be made available in communication between parent and child documents. We would wish for the ability for child elements to take part in line breaking as well, but that’s less crucial.

The Compound Document profiles and recommendations have an excellent opportunity to address these issues, in keeping with the following requirement from the Compound Document Use Cases and Requirements Version 2.0:

·         3.2.3.3 CDI WICD Core MUST define layout semantics across elements from varying namespace boundaries

CDI WICD Profiles must describe layout behavior in a way that is meaningful when various component languages interact. CDF may define a vocabulary that specifications can use to describe the information that layout algorithms need from or provide to parent or child objects in another document format. Examples of parameters that parent elements need to provide to child elements are width and height.

It would seem that child objects – like inline MathML – which produce content that is “text-like” need to have the ability to participate in the layout flow of the surrounding text. For the implementation rendering the child document to have access to the available width and height, or the ability to provide its intrinsic width and height to the parent, is the minimal requirement, but this doesn't seem to be explicitly mandated anywhere in the recommendations. And while the intrinsic width and height are sufficient to handle layout problems for many image objects, they don’t provide enough communication for good layout of math. Mathematics can contain subscripts and superscripts of arbitrary size and complexity, large operators, fractions, matrices, and any combination of these; there are established standards for properly laying all of these out, but they generally require knowledge of the baseline. In particular, the baseline of the math needs to be aligned with the baseline of the ambient text. While CSS can be used to request positioning the math at the baseline, CSS doesn't currently contemplate a baseline for replaced content, so the result of baseline alignment is to align the bottom of the replaced math with the surrounding baseline. Even if the CSS assumptions can be changed, a containing application can’t align the ambient baseline with the math baseline if only the width and height of the math are communicated. (This wouldn't seem to be an issue solely for MathML. Other content types, such as musical notation or chemical diagrams, XForms objects, bibliographic content, or indeed Ruby markup if it hadn't been incorporated into the XHTML namespace, may also produce replaced content which should be rendered inline, and which would need baseline information for correct layout.)

Similarly, mathematical expressions can reach nearly arbitrary length, and math layout engines typically allow for linebreaking within math. A method to allow negotiation of linebreaking between a child object and a parent would thus be very desirable – and again, this would seem to be potentially useful for other types of content.

CSS can be used to handle some of these issues in some situations, and current browsers (as David indicated previously) have provided ad hoc solutions (or even added native MathML layout support). But a general and consistent solution to the problems of layout negotiation between components and parents needs the child’s intrinsic height and width to begin with, and baseline information as well. And even if we succeed in getting improved CSS support for baseline alignment (that is, getting CSS to allow for a baseline as a property of even replaced content), mechanisms for passing these between child and parent documents need to be mandated in order for the CSS to be properly implemented, especially in situations where a plugin is used to render the child.

We’d very much appreciate your consideration of these issues.

Thanks,

Ron Ausbrooks

Writing on behalf of the Math Working Group