Bug 107856 - mathml fences often look bad
Summary: mathml fences often look bad
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: MathML (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-24 13:19 PST by Ojan Vafai
Modified: 2014-06-21 02:33 PDT (History)
9 users (show)

See Also:


Attachments
test case (1.04 KB, text/html)
2013-01-24 13:19 PST, Ojan Vafai
no flags Details
screenshot (1.94 KB, image/png)
2013-01-24 13:19 PST, Ojan Vafai
no flags Details
modified testcase, mfenced replaced by mrow+mo (1012 bytes, text/html)
2013-01-27 02:23 PST, Frédéric Wang (:fredw)
no flags Details
Screenshot Nightly WebKitGTK+ (14.53 KB, image/png)
2014-06-21 02:32 PDT, Frédéric Wang (:fredw)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ojan Vafai 2013-01-24 13:19:24 PST
Created attachment 184564 [details]
test case

Here's a case where the open fence is stretched using font-size and the close fence is stretched using stacking of multiple characters. Just stumbled across this while working on other mathml stuff.
Comment 1 Ojan Vafai 2013-01-24 13:19:43 PST
Created attachment 184565 [details]
screenshot
Comment 2 Ojan Vafai 2013-01-24 13:25:46 PST
For those not familiar with mathml, the opening curly brace should be the same size/font as the closing paren.
Comment 3 Dave Barton 2013-01-24 14:22:44 PST
Another problem in this particular case is that the outer <mfenced> probably shouldn't have a closing fence at all, given the close="" attribute. The current implementation kind of assumes open and close are each 1 character. (I didn't write this code.)

Actually in Chrome 24 stable (24.0.1312.56) on Mac OS 10.6.8, I don't get the opening fence you're seeing in your screenshot, either with or without STIX fonts enabled. I just get a thin nice-looking brace.
Comment 4 Frédéric Wang (:fredw) 2013-01-27 02:23:36 PST
Created attachment 184906 [details]
modified testcase, mfenced replaced by mrow+mo

Here is a modified version, with mfenced replaced by the equivalent mrow+mo constructions. That looks much better in Webkit with that change.

Some MathML WG members have said in the past that mfenced was only there because of demands from some math communities but they are not really fond of this element: it duplicates the mrow+mo construction and uses a different format (attributes for operators, no way to use mo attributes on them). This has been the source of many bugs in Firefox, MathJax, MathPlayer essentially because the two constructions are not always consistent. Personally, I would encourage people not to use it.
Comment 5 Dave Barton 2013-01-27 14:58:38 PST
I agree about <mfenced> being a bad idea.

Actually, as I read the spec, the <mfenced> in this case isn't even really legal, since there's no closing fence.
Comment 6 Frédéric Wang (:fredw) 2014-06-21 02:31:02 PDT
(In reply to comment #5)
> I agree about <mfenced> being a bad idea.
> 
> Actually, as I read the spec, the <mfenced> in this case isn't even really legal, since there's no closing fence.

I think this testcase has been generated by a previous version of MathJax which incorrectly used <mfenced> to convert thinks like

\left{ ... \right.

into

<mfenced open="{" close=""> ... </mfenced>

which per http://www.w3.org/TR/MathML3/chapter3.html#presm.mfenced is equivalent to

<mrow>
   <mo>{</mo>
   <mrow>
     ...
   </mrow>
   <mo></mo>
</mrow>

I'm not sure it is very good semantically to have this empty <mo> as a closing fence. That's one more good reason not to use the <mfenced> element. Fortunately, MathJax stopped using that element in the most recent versions.
Comment 7 Frédéric Wang (:fredw) 2014-06-21 02:32:29 PDT
Created attachment 233520 [details]
Screenshot Nightly WebKitGTK+

Here is a screenshot of the testcase in a nightly build with Latin Modern Math. We no longer do stretching via font-size and the closing parenthesis is not displayed for close="", as expected.