Tests from the MathML testsuite: http://www.w3.org/Math/testsuite/build/main/Presentation/TablesAndMatrices/mlabeledtr/mlabeledtr1-full.xhtml http://www.w3.org/Math/testsuite/build/main/Presentation/TablesAndMatrices/mlabeledtr/mlabeledtrAside1-full.xhtml http://www.w3.org/Math/testsuite/build/main/Presentation/TablesAndMatrices/mlabeledtr/mlabeledtrAside2-full.xhtml http://www.w3.org/Math/testsuite/build/main/Presentation/TablesAndMatrices/mlabeledtr/rec-mlabeledtr-full.xhtml

Because of the vertical alignment requirement, it seems that the most easy way to implement this is to follow the REC's suggested model: "To place a label, an implementor might think in terms of creating a larger table, with an extra column on both ends. The columnwidth attributes of both these border columns would be set to "fit" so that they expand to fill whatever space remains after the inner columns have been laid out. Finally, depending on the values of side and minlabelspacing, the label is placed in whatever border column is appropriate, possibly shifted down if necessary, and aligned according to columnalignment." So maybe we should do something in nsCSSFrameConstructor to add extra column on both ends of an <mtr> or <mlabeledtr> element (with the label placed in the appropriate extra cell in the latter case). We will need to change the implementation of rowlines, columnlines etc to take into account that we have these extra columns. That would give a slightly incorrect implementation of mtable@width, though.

An add-on to workaround this bug: https://addons.mozilla.org/addon/mathml-mml3ff/

Someone from the Webkit MathML team contacted me about this bug today. Adding me as mentor, although I don't know well the code in nsCSSFrameConstructor to change. I think even something like

I think even something like what David Carlisle's XSLT stylesheet do would be OK (adding a column to <mtable>'s that have a <mlabeledtr> child).

Mass change: setting priority to 2 for bugs that would be nice fix if Gecko's MathML support is enabled by default in MathJax but that are not in my opinion strictly required or for which a workaround could be written in the MathJax code.