# MathML & CSS ; mstyle

From: Frédéric WANG <fred.wang@free.fr>
Date: Wed, 05 Sep 2012 12:19:40 +0200
Message-ID: <5047273C.6010508@free.fr>
To: "www-math@w3.org" <www-math@w3.org>
Dear all,

between the so-called "native" browser implementations against plugins
or Javascript libraries like MathPlayer or MathJax. In my opinion, the
most important difference is the way these implementations react with
respect to the host environment: integration into the surrounding
language (e.g HTML, SVG), styling (how external CSS rules are applied),
dynamic updates (e.g. Javascript, window size, zoom) etc Today I
mmultiscript topic and he proposed to define some default CSS rules for
MathML. Although I'm not sure we could totally achieve this goal (cf the
experience with the MathML for CSS profiles) I think the MathML WG
should, perhaps in a future specification, try to do some efforts
regarding compatibility between MathML and CSS.

More precisely, I would like to open a discussion on the <mstyle>
element. Karl and I are not really big fans of this element, which has
always been the source of several bugs in Gecko's layout engine while
most attributes are not really useful (not to say entirely unused). I
also found bugs with this element in MathJax and MathPlayer but I think,
like Gecko, they support most of the mstyle attributes. But Gecko has
additional issues to deal with, for example Javascript changes or
interaction with the CSS environment. From that point of view, the
<mstyle> element does not seem really appropriate. Perhaps defining new
CSS rules in Gecko would help (see
https://wiki.mozilla.org/MathML:mstyle) but that would be at the cost of
adding a lot of code for, once again, very rarely used attributes.

As far as I know, Webkit does not really support <mstyle> but the
implementation is heavily based on CSS rules so I suspect the <mstyle>
element will be a problem for the Webkit developers too. The MathML for
CSS profile, used by Opera, also drops totally the <mstyle> attribute.
Finally, the MathML WG is also aware of the issue with different
elements sharing attributes with the same name but different semantics.
In general the MathML spec just contains rules to say that the
problematic <mstyle> attributes only apply to one type of element (which
BTW, shows again that these attributes are not really useful for the
other elements). Even with these exceptions, we get bugs in e.g. MathJax
(see https://github.com/mathjax/MathJax/issues/249). There are other
issues like the one I reported previously with the "accent" attribute.

There is one category of attributes that behave nicely with respect to
CSS and are in my opinion the most useful to the users. This is the
category of attributes inherited from the surrounding context like
mathcolor. From the point of view of browser implementers, these
attributes can be mapped into CSS rules in a straightforward way. This
is also typically the use of mstyle, I believe, people have in mind: the
possibility to give a custom style to the formulas. For native browser
implementations, these could be achieve by usual (and arguably more
familiar to users) CSS technologies. For example

mtext {
color: blue;
}

One can of course use all the possibilities provided by CSS (selectors
to restrict to specific elements, external stylesheet to cover several
pages etc) to decide precisely the application of this rule. The
<mstyle> method would be

<mstyle mathcolor="blue">

which gives only the possibility to change the color of a particular
subset of a given [itex] element. Obviously, this is much less powerful
but has the merit to work with other non-native renderers. For example,
I don't think MathPlayer implements the "style" attribute or other CSS
rules and basically just ignores them. MathJax does a better job with
the "style" attribute but doesn't know more general CSS techniques and
the users have to specify CSS rules in a separate JSON structure.

I could also mention lquote/rquote. Does it really make sense to allow

<mstyle lquote="A">
...
<mstyle rquote="B">
... An ms element in this subtree is surrounded by A and B ...
</mstyle>
<mstyle rquote="C">
... An ms element in this subtree is surrounded by A and C ...
</mstyle>
</mstyle>

I agree that it may be useful for users to redefine their own quote
style. But in that case they probably want to define both quotes at once
and the CSS "quotes" property seems the most appropriate thing to do:

.myquotes {
quotes: "«" "»";
}

Similarly, consider the Arabic version of the MathML start page
(http://www.mozilla.org/projects/mathml/start-ar.html). One has to add a
dir="rtl" attribute on each [itex] element. A more natural way would be

math {
direction: rtl;
}

As I said these attributes are not really annoying for the browser
implementers and I think it is fine to keep them if they are useful for
other renderers with limited CSS capabilities. Note that the MathML WG
seems to have already made a step toward CSS by deprecating some
attributes like "fontstyle".

The second category (I read the MathML REC:
http://www.w3.org/TR/MathML3/chapter3.html#presm.mstyle) is the most
annoying. Actually I consider the third category the same as the second
one, except that additional computations are performed. One way to make
this come back to the CSS world would be to add CSS rules for each
mstyle value. For instance, "mstyle-linethickness" would store the
default value to use in mfrac descendants (which is inherited) as
opposed to the actual linethickness value applied to a mfrac element
(which is not inherited). But this would mean adding a lot of CSS rules
and seems a bit overkill if people do not use this feature. Perhaps
someone wants to define a default linethickness of fractions but do
people really want to declare that all <mtable>s in a subtree should
have columnalign="left right center" or all <mo>'s in a subtree should
be stretchy="true" largeop="true"? Even for linethickness and similar, I
suspect MathML converters will probably rely on e.g. LaTeX techniques to
implement this customization and just generate the linethickness on the
final <mfrac> elements. I guess it is really hard to handle this kind of
<mstyle>-based customization in a WYSIWYG editors, for example Amaya
does not provide any UI for this, although it has an UI for CSS styling.
I can also compare this with namedspace values
(http://www.w3.org/TR/MathML3/chapter3.html#id.3.3.4.2.1) which was
implemented in Gecko but added unwanted complexity to the code for a
feature which seems to never have been used.

So I would personally suggest a drastic decision: deprecate <mstyle> for
these two other categories. Only the first category would remain and
hence <mstyle> would become compatible with CSS. If we do not want to go
so far, I think we should at least discuss concrete use cases of
<mstyle> and which values are really worth keeping?

(Sorry for the long message, but the Mozilla MathML team should have
raised the <mstyle> issue for a long time)

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

Received on Wednesday, 5 September 2012 10:20:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:45 UTC