Re: Ideas for future improvements

Le 03/12/2014 23:29, Murray Sargent a écrit :
> <nary> has three arguments: two limits and a n_aryand, whereas the pot pourri tags don't identify the n-aryand.
In MathML this is <munderover>A B C</munderover>

where A is an <mo> with property "largeop" (explicitly or from the
operator dictionary). The "movablelimits" of the <mo> property indicates
whether they should become subsup in inline mode.

(I agree having <mover></mover> and <munder></munder> seems a bit
duplicate, but in Gecko we end up merging the implementations, which
does not seem trivial with <mfenced>)

> A delimiter object is handy since you measure its contents and then display the result with brackets that fit (according to special rules)
<mfenced> is equivalent to <mrow> as specified by the MathML spec.
Again, you need to use the operator dictionary to determine whether the
first and last child are stretchy / fences. This just need some
additional verifications on the first and last child, but that won't
make layout or a11y algorithms harder.

> For the same reason, I prefer <mfract> to <mrow>...<mo>/</mo>...</mrow>. We use nontrivial code to convert the inline versions to the prefix versions.
This is <mfrac bevelled="true"> in MathML.
> In any event, this is all water over the dam. Deprecating any Presentation MathML tags would break too many implementations.
<mfenced> is different to what you mention above:

- The spec explicitly indicates the equivalent markup and requires the
implementation to render the two versions exactly the same. You can not
choose the one version you prefer, so implementers have double work.

- The structure is quite different because the operators in <mfenced>
are in attribute values rather than in elements. As a consequence,
native implementations need to create anonymous frames to represent
these operators.

- Deprecating will not break conforming implementations (they implement
the two versions, as currently required by the spec) but only poor
implementations like the one that used to be in Opera. As said by
William, the only risk is breaking old documents. What I'm proposing is
that browsers display a deprecation warning and encourage people to move
to the equivalent version, to prepare future removal in a (very) long term.

-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic