[MathML4] Simplification of the mstyle element
Frédéric WANG <[email protected]> Wed, 27 Jul 2016 10:10:10 +0200
| Newsgroups | gmane.comp.web.mathematics |
|---|---|
| Message-ID | <[email protected]> |
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WFffhD9nILFgr8cW01skWlRmEWDTgVhDF Content-Type: multipart/mixed; boundary="k8kWGtGVeDS5er62wQLTP7sG8G3NObPG1" From: =?UTF-8?B?RnLDqWTDqXJpYyBXQU5H?= <[email protected]> To: "[email protected]" <[email protected]> Message-ID: <[email protected]> Subject: [MathML4] Simplification of the mstyle element --k8kWGtGVeDS5er62wQLTP7sG8G3NObPG1 Content-Type: multipart/alternative; boundary="------------4E034BD5D0409977B18CC4B7" This is a multi-part message in MIME format. --------------4E034BD5D0409977B18CC4B7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Continuing with suggestions for future Math WG work, let's come back again to the idea of simplifying the mstyle element. It duplicates the CSS inheritance mechanism in a CSS-incompatible way and has many exceptions that make it hard to understand: there are three different types of inheritance described in the specification, mathbackground applies more naturally to the element that bears the attribute than to each token descendants, mpadded/mspace share attributes names that have different syntax etc For example, in previous discussions the case of displaystyle seemed really clear in the mind of spec authors but less in the one of the various implementers. In practice, many of the mstyle attributes are not useful and never used. It is a burden for implementers since they essentially have to reimplement a specific "attribute" inheritance mechanism to support the general case even if the most prominent attributes have obvious mapping to CSS. It is also a performance issue to perform the rendering and keep it up-to-date since the rendering on any node may depend on its mstyle ancestors. Support for mstyle has been simplified in Gecko several years ago. When this was reported to this mailing list, there have not been strong complaints against the idea (only a few extra attributes were reported to be used in the MathML3 test suite). There has not been any bug reports regarding removal of attributes, confirming they were not used (this contrasts with the case of displaystyle for which aligning on the specification caused some trouble). Support for some important mstyle attributes have been implemented in WebKit but there are no plans to handle the general cases. Given this, the proposal is as follows: restrict mstyle to attributes used in practice listed below. Also the inheritance can in most cases be more easily described with CSS rules or attribute mapping. 1) dir: mapped to the CSS direction property. 2) mathsize: mapped to font-size. Note that MathML has the keywords "small", "normal", "big" that adds some parsing code before the mapping. It's not clear whether these keywords are very important (small is 100%, small/big are unspecified...) so they could be deprecated too to simplify the mapping code. 3) mathbackground: mapped to CSS background property. 4) color: mapped to CSS color property. 5) displaystyle: this one will be preserved but inheritance can be more clearly described to people familiar with CSS as equivalent to having a CSS property with values false/true, which is inherited, has computed value "as specified" and with the following rules in the user agent stylesheet. math { displaystyle: false; } math[display=3D"block"] { displaystyle: true; } math[display=3D"false"] { displaystyle: false; } math[displaystyle=3D"false"] { displaystyle: false; } math[displaystyle=3D"true"] { displaystyle: true; } mtable { displaystyle: false; } mtable[displaystyle=3D"true"] { displaystyle: true; } mstyle[displaystyle=3D"false"] { displaystyle: false; } mstyle[displaystyle=3D"true"] { displaystyle: true; } mfrac > * { displaystyle: false; } mroot > :not(:first-child) { displaystyle: false; } msub > :not(:first-child), msup > :not(:first-child), msubsup > :not(:first-child), mmultiscripts > :not(:first-child) { displaystyle: false; } munder > :not(:first-child), mover > :not(:first-child), munderover > :not(:first-child) { displaystyle: false; } 6) mathvariant: this one will be preserved but inheritance can be more clearly described to people familiar with CSS as mapped to a CSS property with all the mathvariant values + an "auto" value (to handle automatic italic), initial value "auto", which is inherited and has computed value "as specified". 7) scriptsizemultiplier: can be described as a CSS property with <number> values, initial value 0.71, computed value "as specified" and which is inherited. It's not clear whether the attribute is really useful as in practice it is left to its default value. Also this is in conflicts with ScriptPercentScaleDown and ScriptScriptPercentScaleDown properties of the MATH table. 8) scriptminsize: can be described as a CSS property with <length> values, initial value 8pt, computed value "as specified" and which is inherited. Again, it's not really clear whether the attribute is useful as in practice it is left to its default value. 9) scriptlevel: This one must be preserved but it is not clear whether it can be described as a pure CSS property without adding too much complexities. There is a proposal on http://www.mathml-association.org/MathMLinHTML5/S2.html#SS3 but the increment in munderover/munder/mover should really depend on the accent/accentunder property which itself depends on specified attributes or implicit/explicit operator properties in the overscript/underscript subtrees. A rule to determine the computed value for font-size must also be provided, for example: FontSize_Child =3D max of ScriptMinSize_Parent and [FontSize_Parent times ScriptSizeMultiplier_Parent^(FontSize_Child - FontSize_Parent)]= with possible additional edge cases to handle. Unless something has been forgotten above, all the other mstyle attributes could be safely deprecated and removed. --=20 Fr=C3=A9d=C3=A9ric Wang --------------4E034BD5D0409977B18CC4B7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf= -8"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> <p>Hi,<br> <br> Continuing with suggestions for future Math WG work, let's come back again to the idea of simplifying the mstyle element. It duplicates the CSS inheritance mechanism in a CSS-incompatible way and has many exceptions that make it hard to understand: there are three different types of inheritance described in the specification, mathbackground applies more naturally to the element that bears the attribute than to each token descendants, mpadded/mspace share attributes names that have different syntax etc For example, in previous discussions the case of displaystyle seemed really clear in the mind of spec authors but less in the one of the various implementers.<br> <br> In practice, many of the mstyle attributes are not useful and never used. It is a burden for implementers since they essentially have to reimplement a specific "attribute" inheritance mechanism to support the general case even if the most prominent attributes have obvious mapping to CSS. It is also a performance issue to perform the rendering and keep it up-to-date since the rendering on any node may depend on its mstyle ancestors.<br> <br> Support for mstyle has been simplified in Gecko several years ago. When this was reported to this mailing list, there have not been strong complaints against the idea (only a few extra attributes were reported to be used in the MathML3 test suite). There has not been any bug reports regarding removal of attributes, confirming they were not used (this contrasts with the case of displaystyle for which aligning on the specification caused some trouble). Support for some important mstyle attributes have been implemented in WebKit but there are no plans to handle the general cases.<br> <br> Given this, the proposal is as follows: restrict mstyle to attributes used in practice listed below. Also the inheritance can in most cases be more easily described with CSS rules or attribute mapping.<br> <br> 1) dir: mapped to the CSS direction property.<br> <br> 2) mathsize: mapped to font-size. Note that MathML has the keywords "small", "normal", "big" that adds some parsing code before the mapping. It's not clear whether these keywords are very important (small is 100%, small/big are unspecified...) so they could be deprecated too to simplify the mapping code.<br> <br> 3) mathbackground: mapped to CSS background property.<br> <br> 4) color: mapped to CSS color property.<br> <br> 5) displaystyle: this one will be preserved but inheritance can be more clearly described to people familiar with CSS as equivalent to having a CSS property with values false/true, which is inherited, has computed value "as specified" and with the following rules in the user agent stylesheet.<br> <br> math {<br> =C2=A0 displaystyle: false;<br> }<br> math[display=3D"block"] {<br> =C2=A0 displaystyle: true;<br> }<br> math[display=3D"false"] {<br> =C2=A0 displaystyle: false;<br> }<br> math[displaystyle=3D"false"] {<br> =C2=A0 displaystyle: false;<br> }<br> math[displaystyle=3D"true"] {<br> =C2=A0 displaystyle: true;<br> }<br> mtable {<br> =C2=A0 displaystyle: false;<br> }<br> mtable[displaystyle=3D"true"] {<br> =C2=A0 displaystyle: true;<br> }<br> mstyle[displaystyle=3D"false"] {<br> =C2=A0 displaystyle: false;<br> }<br> mstyle[displaystyle=3D"true"] {<br> =C2=A0 displaystyle: true;<br> }<br> mfrac > * {<br> =C2=A0 displaystyle: false;<br> }<br> mroot > :not(:first-child) {<br> =C2=A0 displaystyle: false;<br> }<br> msub > :not(:first-child),<br> msup > :not(:first-child),<br> msubsup > :not(:first-child),<br> mmultiscripts > :not(:first-child) {<br> =C2=A0 displaystyle: false;<br> }<br> munder > :not(:first-child),<br> mover > :not(:first-child),<br> munderover > :not(:first-child) {<br> =C2=A0 displaystyle: false;<br> }<br> <br> 6) mathvariant: this one will be preserved but inheritance can be more clearly described to people familiar with CSS as mapped to a CSS property with all the mathvariant values + an "auto" value (to handle automatic italic), initial value "auto", which is inherited and has computed value "as specified".<br> <br> 7) scriptsizemultiplier: can be described as a CSS property with <number> values, initial value 0.71, computed value "as specified" and which is inherited. It's not clear whether the attribute is really useful as in practice it is left to its default value. Also this is in conflicts with ScriptPercentScaleDown and ScriptScriptPercentScaleDown properties of the MATH table.<br> <br> 8) scriptminsize: can be described as a CSS property with <length> values, initial value 8pt, computed value "as specified" and which is inherited. Again, it's not really clear whether the attribute is useful as in practice it is left to its default value.<br> <br> 9) scriptlevel: This one must be preserved but it is not clear whether it can be described as a pure CSS property without adding too much complexities. There is a proposal on <a class=3D"moz-txt-link-freetext" href=3D"http://www.mathml-associ= ation.org/MathMLinHTML5/S2.html#SS3">http://www.mathml-association.org/Ma= thMLinHTML5/S2.html#SS3</a> but the increment in munderover/munder/mover should really depend on the accent/accentunder property which itself depends on specified attributes or implicit/explicit operator properties in the overscript/underscript subtrees.<br> <br> A rule to determine the computed value for font-size must also be provided, for example:<br> <br> FontSize_Child =3D<br> =C2=A0 max of ScriptMinSize_Parent and <br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [FontSize_Parent t= imes<br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ScriptSizeMu= ltiplier_Parent^(FontSize_Child - FontSize_Parent)]<br> <br> with possible additional edge cases to handle.<br> <br> Unless something has been forgotten above, all the other mstyle attributes could be safely deprecated and removed.<br> </p> <pre class=3D"moz-signature" cols=3D"72">--=20 Fr=C3=A9d=C3=A9ric Wang </pre> </body> </html> --------------4E034BD5D0409977B18CC4B7-- --k8kWGtGVeDS5er62wQLTP7sG8G3NObPG1-- --WFffhD9nILFgr8cW01skWlRmEWDTgVhDF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXmGxjAAoJEL8nnpULUzQOYfgQAKQOcY+fcA6ZQi5tLnmEAtJQ NIhW/fm/bHfS+vqNa55lcB14waLa+zKavF/FK3i8KMIz9RRxE3PIdvnh5Xq1EGzf gmk1wfAUqBz7EKaL1im7tlxLBa102gB/mhotyrzMCAXn/0l5yiuKlQS+6lJrSpnv mnSnNsI6s12UkfgrRCBr6JkvFONPCgVhle0c+/l+QdhJ1Men5kTCrlfHvAtNIETD Bois1gFlKyl+fHtHmQ88cFGwTx2tP8Ap7rMDr1UgEweHd68jAOP/U2t1pOyxIvmA 49FctLFpNLNrm5sxgFhpggal+AWRl1mkMraI7Psy520uvZwNCKjsQtLe9nREOrPC szyBAniiZ6UDiKFjZUuBU2f8bxXmjVZ97l4fDOPNzvsKOJU06KCs29KLIB6PaqU3 BJIVJDFnnBXtocWo7lJ/+oOMlIAz92f8FRzntqVciXTxLiteUazq1VfxklBHjIhG MW7JXQpuo9av8KxIufjgZge9TA+o+LLry/a+vt0fHyNDlTZBJaoam+G6Sm7JxvG7 4opokqECwkPL3QMVBF5x+T+JX4OSkn62RzBTckIiC436NWzzii/PwONzpmzDBKNG IHbHdFYxBJ7JLU/7j6lINvQgoSEHSYftSSgZdyuJcS8Wukpf8RJ7oK5pT1aGy3px R2f2gTQGzxtz0vJQ6x/v =HCeA -----END PGP SIGNATURE----- --WFffhD9nILFgr8cW01skWlRmEWDTgVhDF--