- From: William F Hammond <hammond@csc.albany.edu>
- Date: Tue, 27 May 2008 13:45:48 -0400
- To: www-math@w3.org
Neil Soiffer writes in reply to me: >> (In my Firefox (2.0.0.14) it seems that only 2329 and 232A are appropriately >> stretchy.) >> >> It strikes me, however, that to the extent presentation markup can be >> maximally semantic (which is related to what one might be able to coax >> out of most mathematical authors some day), these brackets and other >> stretchy balancers should, for presentation markup, be deployed via >> <mfenced> (the list constructor). >> >> Routes for this include LaTeX's \left<...\right> or gellmu's \vect[<>]{...} >> and \bal[<>]{...} [in releases so far, actually, \balab{...}]. > > mfenced is defined to be equivalent to <mrow> with <mo>s for the > fences and separators.[1] Thus, there should be no advantage other > than "convenience" (the term used in the spec) for using <mfenced>. I've always interpreted that text as a user agent guide for screen rendering. I hope you are not saying that _any_ processor, e.g., a processor trying to upgrade presentation mathml to content mathml should first translate every mfenced to mrow in the manner described. >> Then might one hope that user agents will durably pick up the right things >> when rendering <mfenced open="<" close=">">...</mfenced>? >> >> Beyond that one might hope with <mfenced> that user agents will durably >> pick up the right things with any of the aforementioned balancing pairs >> as values for the <mfenced> attributes. >> >> Or is this asking too much of user agents? > > . . . > > "<" and ">" aren't typically meant to stretch, and I would > discourage the use of them as bracketing chars. That is not their > intended use according to Unicode. But, in fact, MathPlayer does stretch them -- see http://math.albany.edu:8010/pers/hammond/G/Doc/langlerangle.xhtml -- while my Firefox 2.0.0.14 does not. My suggestion is that user agents handle mfenced open/close pairs [well, maybe not the CJK pair unless it has really been deployed] symbolically. I suppose that could be done before translation of mfenced to mrow or it could be incorporated under well-defined circumstances in mrow. Otherwise we'll be headed for the same kind of mess we've had with straightphi and varphi. I hope it's not asking too much. -- Bill > . . . > [1] http://www.w3.org/TR/2003/REC-MathML2-20031021/chapter3.html#presm.mfenced > [2] http://www.w3.org/TR/2003/REC-MathML2-20031021/chapter3.html#id.3.2.5.8
Received on Tuesday, 27 May 2008 17:46:27 UTC