All "left ... ... right ..." commands should probably generate <mrow>+<mo> rather than <mfenced>. Rationale: https://github.com/mathjax/MathJax/issues/359
Mass changes to assign bugs to myself.
Created attachment 81745 [details] New output I've submitted a patch for review: https://gerrit.libreoffice.org/#/c/4632/ I attach the new output that you can view in Firefox. As a separate issue, I have to check the unicode characters used for open/close symbols. At least the angle brackets seem weird in Firefox (bad spacing, not stretchy). I suspect they use the old HTML4 ⟨ and ⟩ rather than the new HTML5 definition.
> As a separate issue, I have to check the unicode characters used for > open/close symbols. At least the angle brackets seem weird in Firefox (bad > spacing, not stretchy). I suspect they use the old HTML4 ⟨ and ⟩ > rather than the new HTML5 definition. I just verified and opened bug 66416.
I’m not sure I like this change, it looks to me like a workaround for a Gecko bug. The specification explicatively state that <mfenced> and its <mrow> + <mo> “expanded” form should render the same, and <mfenced> looks more “semantically” correct to me (OK, it is presentation MathML after all, but preserving some semantics does not hurt).
The <mfenced> and <mrow>+<mo> forms are strictly equivalent so one is not more semantically correct than the others (that's the point of having these fence="true" attributes on the expanded form). <mfenced> immediately gives that something is a fenced construction but you can guess that from the <mrow>+<mo> form with slightly more effort... Anyway that does not help since tools must be able to understand the expanded form too. The reason for this change is more because <mfenced> is really poorly designed and duplicates the <mrow>+<mo> features in an inconsistent and less expressive way. Basically, text is given in attributes rather than as text nodes in <mo> so you can no longer apply any stylistic, hyperlink or <mo> properties and all the tools that work on text nodes (search engines, copy and paste, Firefox DOM inspector) may just ignore the fences. For implementers, that means to maintain more code for <mfenced> and the implementation is inconsistent with the rest of the code base. The Gecko bug is minor here (it happens with very small height IIRC) but there have been / are many serious bugs in e.g. WebKit and MathJax implementations due to mfenced. Many people from the Math WG do not like that element and said it is only here to satisfy the demand of some groups of people. I think most MathML folks would love to drop it. As a comparison, introducing <mfenced> is like if someone would decide to write \mfenced[(][)]x in LaTeX instead of \left( x \right). That's actually even worse, because <mfenced> has the "separators" attribute. Even in LibreOffice code this leads to inconsistencies: <mfenced> is exported when there are exactly two operators and when both of them are stretchy but otherwise we fallback to <mrow>+<mo> since that can not be encoded in <mfenced>. The MathML import code seems to handle both cases but I haven't tested if that works correctly and consistently.
Comment on attachment 81745 [details] New output This is now obsolete after bug 66416.
OK, the fence attribute seems good enough in preserving the left/right semantic.
Frederic Wang committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c61f35275c613cf7ba6f1aa7bc8235340f9df8f7 fdo#66282 - MathML export: improve ExportBrace The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.