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-----