1131000 - MathML: semantics elements interfere with width

Status: RESOLVED FIXED

(Core :: MathML, defect)

Description

[Peter Krautzberger]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150125221831

Steps to reproduce:

Hi,

The following snippet

<math display="block" xmlns="http://www.w3.org/1998/Math/MathML">
  <semantics>
    <mtable width="100%" mathbackground="red">
      <mtr> <mtd><mi>x</mi></mtd> </mtr>
    </mtable>
    <annotation encoding="application/x-tex">x</annotation>
  </semantics>
</math>

does not render as expected, i.e., at full width as would

<math display="block" xmlns="http://www.w3.org/1998/Math/MathML">
  <mtable width="100%" mathbackground="red">
    <mtr> <mtd><mi>x</mi></mtd> </mtr>
  </mtable>
</math>

Similarly to  https://bugzilla.mozilla.org/show_bug.cgi?id=468059, we can work around this by repeating the styling. 


<math display="block" xmlns="http://www.w3.org/1998/Math/MathML">
  <semantics style="width:100%">
    <mtable width="100%" mathbackground="red">
      <mtr> <mtd><mi>x</mi></mtd> </mtr>
    </mtable>
    <annotation encoding="application/x-tex">x</annotation>
  </semantics>
</math>

It seems unexpected and it would be great to agree with other MathML renderers on the expected behavior. I asked the MathWG via www-math and it seems the spec leaves this kind of interaction open.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You get these results in Gecko because by default <semantics> shrink-wraps like other MathML content. I can see that in this case you don't want it to shrink-wrap or affect widths, but what about

<math display="block" xmlns="http://www.w3.org/1998/Math/MathML">
  <semantics style="border:100px solid black">
    <mtable width="100%" mathbackground="red">
      <mtr> <mtd><mi>x</mi></mtd> </mtr>
    </mtable>
  </semantics>
</math>

It should affect the table width in this case, right?

What about
<math display="block" xmlns="http://www.w3.org/1998/Math/MathML">
  <semantics style="border:100px solid black">
    <mtable mathbackground="red">
      <mtr> <mtd><mi>x</mi></mtd> </mtr>
    </mtable>
  </semantics>
  <semantics style="border:100px solid black">
    <mtable mathbackground="red">
      <mtr> <mtd><mi>x</mi></mtd> </mtr>
    </mtable>
  </semantics>
</math>
?

In this cases, should <semantics> shrink-wrap?

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Never mind, I can make this work assuming sensible answers to the above.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Implement nsMathMLSelectedFrame::ComputeSize to delegate size computation to the selected frame

Comment 4

[Mats Palmgren (inactive)]

The patch looks fine, with the usual s/nsRenderingContext */nsRenderingContext* /

But it makes us deviate from Safari and Opera for the testcase and introducing
incompatibility doesn't seem good to me.  I don't know much about MathML so I have
no clue what the desired rendering is.

Frédéric, can you confirm this patch gives the desired result for the testcase?

Comment 5

[Peter Krautzberger]

Sorry for the delayed response and thanks again for looking into it!

Rob wrote

> It should affect the table width in this case, right?

Yes, I think I agree it should (fwiw, we'll have to change MathJax's behavior as we remove the semantics internally). It's a bit theoretic since I don't think anyone will use semantics will style that.

@Mats yes, WebKit handles it similarly (which makes sense since both are probably due to Fred's work). I'm guessing with Opera you mean Presto? That's a very limited implementation using the unmaintained MathML-CSS profile (which depended on an abandoned table module IIRC) so I think it's not helpful to compare.

FWIW, on www-math, [1], David Carlisle compared the situation to adding extra mrows. Which brings up a similar issue actually -- mrows also shrink-wrap the mtable which, imho, they shouldn't. Again, the spec isn't always clear on the interaction with CSS but "clean" mrows are always considered redundant/removable. At the same time, the spec also warns that removing mrows can affect CSS selectors so again a positive to Rob's question, I think.

Should I open a separate issue for mrow's?

[1] http://lists.w3.org/Archives/Public/www-math/2015Jan/0006.html

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Mats Palmgren (:mats) from comment #4)
> But it makes us deviate from Safari and Opera for the testcase and
> introducing
> incompatibility doesn't seem good to me.  I don't know much about MathML so
> I have
> no clue what the desired rendering is.

Safari and Opera don't have good MathML support so I'm not bothered by this.

We can apply similar logic to mrows in a separate bug if you want.

Comment 7

[Mats Palmgren (inactive)]

(In reply to Peter Krautzberger from comment #5)
> @Mats yes, WebKit handles it similarly...

Safari 8.0.2 does handle it the same as we do currently (without the patch).
With the suggested change we will NOT be compatible, which was my concern.

> I'm guessing with Opera you mean Presto?

Yes, Presto.

Comment 8

[Mats Palmgren (inactive)]

Comment on attachment 8573016 [details] [diff] [review]
Implement nsMathMLSelectedFrame::ComputeSize to delegate size computation to the selected frame

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #6)
> Safari and Opera don't have good MathML support so I'm not bothered by this.

Fair enough.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/16f240fd86de

Comment 10

[Mats Palmgren (inactive)]

> though we don't really support them during reflow anyway...

File a bug if this is something we should support?

Comment 11

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/16f240fd86de

Comment 12

[Peter Krautzberger]

Thanks again for moving this along so quickly, Rob. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1141458 for the corresponding mrow issue.

Comment 13

[Frédéric Wang (:fredw)]

I think there are two points to consider:

1) How semantics should render. I believe we can treat it as

  <mrow>child1 child2 ... childN</mrow>

  where all but the selected child have CSS display: none.

2) How to do intrinsic width & linebreaking in MathML. Currently, there is not any implementation of MathML linebreaking compatible with CSS, so comparison is not really relevant here.

I believe roc's patch only fixes a very special case but I guess it won't handle equivalent markup like

<math display="block" xmlns="http://www.w3.org/1998/Math/MathML">
  <mrow>
    <semantics style="width:100%">
      <mtable width="100%" mathbackground="red">
        <mtr> <mtd><mi>x</mi></mtd> </mtr>
      </mtable>
      <annotation encoding="application/x-tex">x</annotation>
    </semantics>
  </mrow>
</math>

<math display="block" xmlns="http://www.w3.org/1998/Math/MathML">
  <semantics style="width:100%">
    <mrow>
      <mtable width="100%" mathbackground="red">
        <mtr> <mtd><mi>x</mi></mtd> </mtr>
      </mtable>
    </mrow>
    <annotation encoding="application/x-tex">x</annotation>
  </semantics>
</math>

or more complicated nested structures with embedded <mtable>'s. So I think we'll really need a more general solution (bug 534962).