Re: menclose: several values in the "notation" attribute

>> Neil Soiffer writes:
>>
>> > The current draft spec says:
>> >
>> > "Any number of values can be given for notation separated by
>> > whitespace; all of those given and understood by a MathML
>> > renderer should be rendered.  Each should be rendered as if
>> > the others were not present; they should not nest one inside
>> > of the other. For example, notation="circle box" should
>> > result in circle and a box around the contents of menclose;
>> > the circle and box may overlap. This is shown in the first
>> > example below."

> On Tue, Jan 20, 2009 at 6:31 PM, Karl Tomlinson <w3@karlt.net> wrote:
>
>> I assume that implementations are permitted to position and size
>> the menclose (as a whole), thus positioning all the notations,
>> relative to the menclose's sibling and ancestor elements, in a
>> manner that depends on (the maximum extents of) the particular set
>> of notations.  But I don't think a reader would be likely to infer
>> otherwise from the text above.

Neil Soiffer writes:

> Yes (and a little no).  The amount of space used by the notations is not
> defined so renderers are free to draw what looks best in their opinion.  I
> think though that the baseline for every element should be defined so that
> users and implementers know what will/should happen for horizontal
> alignment.  This should be the case for all elements, so if it is missing,
> I'd appreciate someone pointing out the elements on which this isn't said.
> Does saying that the baseline of the meclose element should be the same as
> the baseline of its child (which might be an implied mrow) seem right?  It
> is what MathPlayer does.

Yes, "the baseline of the menclose element should be the same as
the baseline of its child (which might be an implied mrow)" seems
right, and I never considered otherwise.

I was really only trying to make a distinction from a theoretical
situation where there might be an element type that added ink
without taking up space, similar to CSS's "outline" property.

Received on Wednesday, 21 January 2009 03:31:46 UTC