- 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