Mozilla rendering doesn't match suggested W3C rendering

RESOLVED INVALID

Status

()

Core
MathML
RESOLVED INVALID
17 years ago
17 years ago

People

(Reporter: rbs, Assigned: rbs)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

17 years ago
The following is not rendered as suggested (see attached screenshot)
<math xmlns="&mathml;">
  <mrow>
    <mo>&Integral;</mo>
    <mi>x</mi>
    <mo>=</mo>
    <mo largeop="true">&Integral;</mo>
    <mi>x</mi>
    <mo>=</mo>
    <mo largeop="false">&Integral;</mo>
    <mi>x</mi>
    <mo>=</mo>
    <mstyle displaystyle="true">
      <mo>&Integral;</mo>
      <mi>x</mi>
      <mo>=</mo>
      <mo largeop="true">&Integral;</mo>
      <mi>x</mi>
      <mo>=</mo>
      <mo largeop="false">&Integral;</mo>
      <mi>x</mi>
    </mstyle>
  </mrow>
</math>
(Assignee)

Comment 1

17 years ago
Created attachment 25583 [details]
testcase
(Assignee)

Comment 2

17 years ago
Created attachment 25584 [details]
Sugested W3C rendering of the testcase
(Assignee)

Comment 3

17 years ago
Created attachment 25585 [details]
Screenshot of Mozilla rendering of the testcase
(Assignee)

Comment 4

17 years ago
What is happening in Mozilla is that the stretchy elements inside
<mstyle>...</mstyle> are stretched first (i.e., the leaf-elements are processed
first), and their resulting size is determining the size with which to stretch
other surrounding elements. 
(Assignee)

Comment 5

17 years ago
Unless I am missing something, I think this bug is invalid. Mozilla appears to 
be doing the expected thing here. There are 8 possible cases depending on 
whether displaystyle, largeop, stretchy are 'true' or 'false'. I have enumerated 
the 8 cases below and listed the expected renderings that correspond to each:

   display largeop stretchy | expected rendering
   =========================+===================
1: false   false   false    | base size
2: false   false   true     | stretchy size
3: false   true    false    | base size*
4: false   true    true     | stretchy size
5: true    false   false    | base size
6: true    false   true     | strethy size
7: true    true    false    | only the largeop size even if the font can stretch
8: true    true    true     | stretchy size

*case 3 has to be the base size indeed, otherwise the many operators that have 
largeop='true' in the dictionary would have to be strecthed even when not 
needed.

Since by default &Integral; has largeop='true' and stretchy='true' in the 
Operator Dictionary, the testcase corresponds to the following situations:

<math> <!-- inline mode here, so displaystyle='false' -->
  <mrow>
    <mo>&Integral;</mo> <!-- this is case 4 -->
    <mi>x</mi>
    <mo>=</mo>
    <mo largeop="true">&Integral;</mo> <!-- this is case 4 -->
    <mi>x</mi>
    <mo>=</mo>
    <mo largeop="false">&Integral;</mo> <!-- this is case 2 -->
    <mi>x</mi>
    <mo>=</mo>
    <mstyle displaystyle="true">
      ... <-- no issues inside here, rendering matches -->
    </mstyle>
</mstyle>
</math>

So, resolving as INVALID.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.