Re: Displaystyle and mtable

On 11/06/2014 16:01, Davide P. Cervone wrote:
>>> I take "being present" to mean being specified explicitly or by 
>>> inheritance (in the same way that the mathvariant value is present 
>>> by inheritance in my earlier example).  Since displaystyle is 
>>> inherited (as you pointed out in your first message), I take 
>>> <mtable> to have displaystyle="true" in both of these examples.
>> I still don't see how MathJax honors 'the |mtable| element sets 
>> |displaystyle| to "false" within the table elements.' when the 
>> attribute is absent. If the inherited value is true, it will set the 
>> value to true with your interpretation. If the inherited value is 
>> false, then there is no need to "set" the value to false. So this 
>> sentence from the spec is irrelevant and it would make more sense to 
>> say that the displaystyle value on the mtable is inherited (unless it 
>> is modified by an explicit displaystyle attribute on the mtable). 
>> This is what Gecko used to do.
> If I understand you correctly, your argument is that in the statement 
> (section
>     Some attributes, such as displaystyle or scriptlevel (explained
>     below), are inherited from the surrounding context when they are
>     not explicitly set. Specifying such an attribute on
>     an mstyle element sets the value that will be inherited by its
>     child elements. Unless a child element overrides this inherited
>     value, it will pass it on to its children, and they will pass it
>     to their children, and so on. But if a child element does override
>     it, either by an explicit attribute setting or automatically (as
>     is common for scriptlevel), the new (overriding) value will be
>     passed on to that element's children, and then to their children,
>     etc, unless it is again overridden.
> the mtable element falls into the category of modifying the attribute 
> automatically (like mfrac does), and that your quoted statement about 
> setting displaystyle to false is that automatic modification.
> On the other hand, section 3.1.6, that describes displaystyle and 
> scriptlevel, says
>     These values are initialized by the math element according to the
>     display attribute. They are automatically adjusted by the various
>     script and limit schemata elements, and the elements mfrac and
>     mroot, which typically set displaystyle false and increment
>     scriptlevel for some or all of their arguments. ... They also may
>     be set explicitly via the displaystyle and scriptlevel attributes
>     on the mstyle element or the displaystyle attribute of mtable. In
>     all other cases, they are inherited from the node's parent.
> Here, the elements that automatically adjust displaystyle are the 
> script and limit elements, mfrac, and mroot (note that mtable is not 
> listed here).  The mstyle element can modify the value, and an 
> explicit displaystyle on mtable can set the value.  All other cases 
> inherit the value.  So this section does not support the reading that 
> mtable automatically modifies displaystyle.
> My own feeling is that, as you describe above, the sentence is 
> essentially irrelevant, and I think that the spec actually DOES say 
> that the displaystyle value on mtable is inherited unless it is 
> modified by an explicit displaystyle attribute on mtable.  In that 
> reading, sections and 3.1.6 are consistent, though the 
> sentence about displaystyle in is redundant.  Your reading 
> causes and 3.1.6 to be inconsistent.  What the authors of the 
> spec actually intended, I'm not sure.  I guess we'll have to await 
> word from the committee on that.
> Davide

The attribute table for mtable lists displaystyle as having default 
value of "false" (rather than "inherited") and the wording in prior 
versions of mathml that did not have these tables was I believe 
consistent with that.  So I think the intention has always been that the 
default for mtable is like that of latex array and  cells should use 
inline math unless displaystype=true is  explicitly set on the mtable 
(or individual cell)

This is a personal response (and this goes back to before I was on the 
group so I can't speak directly of the original intent:-)


Received on Wednesday, 11 June 2014 15:29:24 UTC