135994 - anonymous table object doesn't force line break when parent 'display: inline'

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect, P3)

Description

[James F. Cerra]

From Bugzilla Helper (edited):
BuildID:    2002040412

table elements with style "display: inline; border: 1px solid red; vertical-
align: middle;" do not render correctly.

The correct rendering would be a table displayed inline with the text, with 
all of the style options availed to inline elements also availed to the 
table.  According to the style sheet above, a table should render (See 
the "expected results" for a relatively precise, preformatted, text rendering 
of the, well, the expected results):

1) In line with the text, as opposed to by itself with no other text displayed 
to the right or left of the table (as a block-level element);
2) with the horizontal-center axis of the table aligned to the horizontal-
center axis of the surrounding text font;
3) with a 1px, solid, red box surrounding the entire table.

However, my build (2002040412, on a WinXP pro system) does not display a table 
with that style sheet correctly.  The actual rendering shows that the table 
element is displayed inline with the text, and all of the above style rules 
apply.  However, the table element's height is only 1em (or the height of the 
surrounding text) and the contents of the table are displayed above the table 
element's (css) box.  There is an identical rendering in both standards and 
quirky mode.

This bug is simular to bug number 18217

Reproducible: Always
Steps to Reproduce:
1. create an html page with the style sheet:
table {display: inline; border: 1px solid red; vertical-align: middle;}
2. type a div tag into the body.
3. write some text.
4. create a two column, two row table.
5. put the text 1 into the first cell of the first row.
6. put the text 2 into the second cell of the first row.
7. put the text 3 into the first cell of the second row.
8. put the text 4 into the second cell of the second row.
9. write some more text.
10. type the closing tag of the div element and finish the html page.

Actual Results:
<pre>                                            1 2
                                          -------
text text text textandmoretext blabla bla | 3 4 | text text text 
textandmoretext blabla bla
                                          -------</pre>

Expected Results:
<pre>                                          -------
                                          | 1 2 |
text text text textandmoretext blabla bla |     | text text text 
textandmoretext blabla bla
                                          | 3 4 |
                                          -------</pre>

Additional Notes:
* see attached file for code that reproduces the problem.
* works correctly on IE6 for WinXP pro.  Does not work on NS4- in addition to 
mozilla.  Will test with opera, NS6.  I expect it not to work for NS6.

Comment 1

[James F. Cerra]

Attachment: shows the example HTML which reproduces the bog

Comment 2

[Amarendra Hanumanula]

*** This bug has been marked as a duplicate of 18217 ***

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

'inline-table' and 'inline' are different.  That rendering would be correct if
we had broken the lines for the anonymous table that was created when the table
element's display was changed to 'inline'.  See the CSS2 chapter on tables.

This isn't really a duplicate, though.  It's part invalid and part a real bug.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Reopening.  See above.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Confirming that we should break the line at the anonymous table...

Comment 6

[Amarendra Hanumanula]

*** Bug 124956 has been marked as a duplicate of this bug. ***

Comment 7

[Boris Zbarsky [:bzbarsky]]

*** Bug 172789 has been marked as a duplicate of this bug. ***

Comment 8

[James F. Cerra]

Attachment: HTML which simulates expected behavior

The HTML show simulates the expected bahavior.

I used span-elements to put the "table" inline, while an image-element acts as
a spacer for the table.  The span-element encompasing the entire table is
positioned absolutely, while it's children span-elements are displayed are
blocks positioned relative to the line (.5em up).  Finally, the span-elements
that contain each cell's contents are displayed inline.

Though this work-around seems to provide the required bahavor, it is ugly and
limited and it only works with modern browsers (tested on mozilla 1.2a and IE
6).  However the code may provide some insight on how to correct the problem
from mozilla's internals.

Comment 9

[karnaze (gone)]

mass reassign to default owner

Comment 10

[Daniel Potter]

*** Bug 195270 has been marked as a duplicate of this bug. ***

Comment 11

[Mats Palmgren (inactive)]

*** Bug 204760 has been marked as a duplicate of this bug. ***

Comment 12

[石庭豐 (Seak, Teng-Fong)]

HELP!!!
Could you go to bug 212661 to judge if that bug is invalid.  Personally, I'm not
convinced it's invalid.
That bug's about using {display:inline} in <table> element so as to have more
than one table on one line.
IMO, IE displays correctly, but not Mozilla.

Comment 13

[Mats Palmgren (inactive)]

*** Bug 213621 has been marked as a duplicate of this bug. ***

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 118553 has been marked as a duplicate of this bug. ***

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 212661 has been marked as a duplicate of this bug. ***

Comment 16

[Ferran Casarramona]

*** Bug 280501 has been marked as a duplicate of this bug. ***

Comment 17

[Ferran Casarramona]

(In reply to comment #16)
> *** Bug 280501 has been marked as a duplicate of this bug. ***

I reproduce a comment of the duplicated bug signaling the specs relevant here.

Acording to CCS2 specification
(http://www.w3.org/TR/REC-CSS2/tables.html#q5) "In terms of the
visual formatting model, a table may behave like a block-level or replaced
inline-level element."

In this case a table may behave as a replaced inline-level element.
With replaced inline-level elements the 'height' must be the intrinsic one, not
the calculated by the 'line-height' property as stated in
http://www.w3.org/TR/REC-CSS2/visudet.html#Computing_heights_and_margins

Comment 18

[Boris Zbarsky [:bzbarsky]]

*** Bug 201485 has been marked as a duplicate of this bug. ***

Comment 19

[Ferran Casarramona]

The described behavior is not possible with CSS 2.0, but with CSS 2.1 you can
use 'inline-block' value to get it. (not implemented yet)
See http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#display-prop

Comment 20

[Ferran Casarramona]

Attachment: Partial workaround of the bug

This is a partially workaround. It renders in the same way with FF, IE and
Opera. But if a bakgound color in teh div is defined, then all are different!
I have used this css trick in http://photoastronomy.org to dinamically arrange
photos in a gallery. However, "text-align:center;" for the image don't display
correctly the first time, but after pressing F5 it displays right. Maybe it is
another bug.

Comment 21

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

Attachment: fix

This fixes ProcessInlineChildren so that psuedoframes are taken into account
when we compute allKidsInline. It's very straightforward.

Comment 22

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

One thing that occurs to me is that maybe we should put "background:inherit",
"border:inherit" and "outline:inherit" on -moz-anonymous-blocks.

Comment 23

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

I think the thing to do here is to make the anonymous table frame be
'inline-table'. I will do that in bug 297537. This patch can go in after that
one is fixed.

Comment 24

[Gérard Talbot]

*** Bug 331445 has been marked as a duplicate of this bug. ***

Comment 25

[Wayne Mery (:wsmwk)]

roc, is patch waiting on anything other than bug 297537?
is this a blocker to bug 18217?

Comment 26

[Wayne Mery (:wsmwk)]

*** Bug 237135 has been marked as a duplicate of this bug. ***

Comment 27

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

More likely this is blocked by 18217.

Comment 28

[Wayne Mery (:wsmwk)]

dbaron in bug 18217 comment 25 says bug 135994 is "NOT related at all" to this bug. (if I'm getting the context correct)   "'display: inline' and 'display: inline-table' are two very different things."  (but he said that a long time ago) 

Anyway what needs to be done before checking in this patch?  

Comment 29

[Boris Zbarsky [:bzbarsky]]

Actually, the spec got changed here.  The new language says:

  If the parent P of a 'table-row-group' (or 'table-header-group',
  'table-footer-group', or 'table-column-group' or 'table-caption') box T is
  not a 'table' or 'inline-table', a box corresponding to a 'table' element
  will be generated between P and T. If P is an 'inline' box, then the
  generated box must be an 'inline-table' box instead of a 'table' box. This
  box will span all consecutive sibling boxess of T that require a 'table'
  parent: 'table-row', 'table-row-group', 'table-header-group',
  'table-footer-group', 'table-column', 'table-column-group', and
  'table-caption', including any anonymous 'table-row' boxes generated
  by rule 1.

So we should be generating an inline-table here, and the line should not break.

Marking invalid.  The generation of the inline-table will happen in bug 18217 or 9458 (wherever the patch ends up).