Re: Ideas for future improvements

Frédéric WANG <[email protected]> Thu, 04 Dec 2014 09:01:28 +0100
Newsgroups gmane.comp.web.mathematics
Message-ID <[email protected]>
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
signature.asc (application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUgBTYAAoJEAuo3hqm2siDnN0QAIRKNDzoEu1xZFwQZy2KB+lU
EKQIWj8KWMHF4PAfC+Cf2B3J8bBCXzvOKvKasWMWh3AWQkr8hyGNCe8XF+OmZZ/F
hWR2qMWZ0P7RpvR0gmDghQAgDGII0JYqANGyNwlslzlUkGJ8m/Em9NUpOCuIOtXY
srClu0V6yUZD7+e9FlzYIdko+w+VG4XUcRkgwoej37MZgH2OUWbWqVf4yxaUm8Ve
/fCbpnm4S+Yer5KZlYj1yBVZMiDUrGpii/4VdaH6QDtYRYakQkLzU6LOBwjp1Pw/
hW1B6+0DyiDdkbRQPKTzSfbzWKZHqH6dDbE96qTWlDaVbH1JVtauAKLcZzplmy7H
0NN6y29yOKE3EPHjxKI3oGPWRUQvzIOUB4gDFXKFtjq7+rmpyM4yEX3h0FNpQta+
ULtNu6ylMamUQeR8sU6lAojhSVZP13z+lLUP/Sh7kUYWqFkuUCUY7BHngj2p7zmG
v6Q7h8souP4LxpalKOsk92t4VGTCyZeyM+Gh5K+Wz1OhjGCwqRJBdMdTAMVhzkQK
03zg2ZSHQf4ArS+0Eu8/1XONEckzj1ZmFAgnKqFMaIs9w7S0dl0U0i1wO+DD2n0u
R3rhSvsznbbLBuujXwQ1mwgs5XxR303O3GCWtFoQvLraJs4B/odx8x69WnGf27Kj
OKmPsdxnPXlHJ0iBtRMc
=+bvW
-----END PGP SIGNATURE-----