Math WG comments on latest CDF documents

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


*         WICD Core 1.0 <http://www.w3.org/TR/2006/WD-WICD-20060811/>  

*          <http://www.w3.org/TR/2006/WD-CDR-20060811/> Compound Document by
Reference Framework 1.0 

*          <http://www.w3.org/TR/2006/WD-WICDFull-20060811/> WICD Full 1.0 

*          <http://www.w3.org/TR/2006/WD-WICDMobile-20060811/> WICD Mobile
1.0 

We remain concerned that the issues raised in The
<http://lists.w3.org/Archives/Public/public-cdf/2006Jan/0069.html>  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
<http://www.w3.org/TR/2005/WD-CDFReqs-20051219/#reqmt_fwk_cdi_layout>
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