MathML & CSS ; mstyle

Dear all,

I recently had a discussion with Paul Topping about the difference 
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 
received a copy of David Barton's message about the previous 
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 <math> 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 <math> 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