Open Bug 219873 Opened 19 years ago Updated 11 years ago

math elements often don't know how high they are


(Core :: MathML, defect)

Windows XP
Not set





(Reporter: steve.swanson, Unassigned)




(6 files, 1 obsolete file)

Using CSS, I gave a dotted border to the <math> elements in the testcase. The 
width seems to always be OK, but the height is often wrong.  Particularly bad 
are <mtable>s.
Attached file testcase
Attached image screenshot
The behavior comes from the fact that <math> is treated as an "inline CSS box",
i.e., its height is the height of the "font box" per CSS, which is rather
non-intuitive if your are not familiar with CSS. By treating it as an
inline-block (when this is supported in Gecko), its height will be what you expect.
Depends on: inline-block
See bug 236963 for a testcase where stretchy fences aren't stretching if 
they're directly nested in a math element.
QA Contact: ian → mathml
Following suggestion of comment 3 seems to fix the bug.
Assignee: rbs →
Attachment #424050 - Flags: review?(roc)
That patch could use a regression test, if possible...
Comment on attachment 424050 [details] [diff] [review]
Replace inline by inline-block

Yes, you should be able to write a reftest for this.
Attachment #424050 - Flags: review?(roc) → review+
Attached patch reftest (obsolete) — Splinter Review
Attachment #424210 - Flags: review?(roc)
Attached patch reftestSplinter Review
just fixing indentation...
Attachment #424210 - Attachment is obsolete: true
Attachment #424252 - Flags: review?(roc)
Attachment #424210 - Flags: review?(roc)
Comment on attachment 424252 [details] [diff] [review]

This fails before the patch, right?
Attachment #424252 - Flags: review?(roc) → review+
(In reply to comment #10)
> (From update of attachment 424252 [details] [diff] [review])
> This fails before the patch, right?

Yes, and applying the patch allows to pass the test.

Does attachment 424050 [details] [diff] [review] needs a superreview?
(In reply to comment #11)
> Does attachment 424050 [details] [diff] [review] needs a superreview?

Keywords: checkin-needed
Closed: 12 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
I had to back this out do to a reftest failures

REFTEST TEST-UNEXPECTED-FAIL | file:///builds/moz2_slave/mozilla-central-linux-debug-unittest-reftest/build/reftest/tests/layout/reftests/bugs/355548-2.xml

REFTEST TEST-UNEXPECTED-FAIL | file:///e:/builds/moz2_slave/mozilla-central-win32-debug-unittest-reftest/build/reftest/tests/layout/reftests/bugs/355548-3.xml
Resolution: FIXED → ---
Guessing this could be our imperfect width calculations leading to line-wrapping within inline-block elements.
(In reply to comment #15)
> Guessing this could be our imperfect width calculations leading to
> line-wrapping within inline-block elements.

Yes, the reftests you mentions do not fail on my computer but I've been able to write a test where I can see a line-wrap. Also, in attachment 131840 [details], it seems that the bounding box of some <math/> elements is too wide / not wide enough.
Would it make sense to make <math/> nowrap?
Attached file testcase width
The MathML spec allows linebreaking. But in Mozilla, it is currently only possible at the <math/> level, not deeper in the formula tree. Moreover, one can not force a newline, so I don't know whether people really use this feature.

Anyway, adding nowrap would not solve the problem of width computation. Attachment 424952 [details] [diff] adds two reftests for the math width, showing that the bug is already present and not fixed by the patch. However, setting math inline-block makes the bug a lot more visible (attachment 424951 [details]).
> The MathML spec allows linebreaking. 

Er... in that case inline-block is the wrong thing to use, no?  If I have this markup:

  This is some equation: <math>x + 2 = 5</math>.

and it needs to line-break after the "2" due to lack of space, then the desired rendering is:

  This is some equation: x + 2
  = 5.

whereas with inline-block you would get:

                         x + 2
  This is some equation: = 5

or so, depending on the exact markup.  Or possibly you'd have a blank line after the "= 5" instead of text continuing after it.
OK, so actually such kind of linebreaking is often used in inline math. But I've no idea about how to fix the bug with the height of <math/> element...
You have to effectively create a new CSS box type for it.  CSS does not have a box type that behaves in the way that seems to be desired here.
We don't support line-breaking of MathML content currently. So I'd be happy to take the inline-block patch if it fixed the bug and didn't cause any regressions.
Linebreaking occurs in Boris' example with


but not with


In the former case, we currently have the first result of comment 21. If we apply the patch, then either we will have the second result of of comment 21, or - if we use "nowrap" - no linebreaking at all.

More annoying is Attachment 424951 [details]: it renders correctly without the patch, but we get an overlap and a gap if block-inline is used.

I don't think the patch should be taken.
Assignee: → nobody
Target Milestone: mozilla1.9.3a1 → ---
You need to log in before you can comment on or make changes to this bug.