415533 - Table rendering algorithm wrt overflow on child-elements changed

Status: RESOLVED DUPLICATE of bug 409736

(Core :: Layout: Tables, defect)

Description

[crisp]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

Firefox 3 obviously changed it's table-rendering algorithm. When a blocklevel child-element in a table-cell has overflow:hidden this is not anymore honoured in order to try to fit the table to a specified width.

This broke for instance our javascripted text-overflow:ellipsis implementation and we had to implement a simular workaround as for Internet Explorer which has the same table-layout behaviour. At this moment it seems that only Opera still has a sane algorithm that makes it possible to do ellipsis overflow in table-cells without having to resort to all kinds of javascript tricks (besides the scripting necessary to workaround Firefox' lack of text-overflow support).

This looks to me to be a regression, or was it deliberate in order to match IE's behaviour?

Reproducible: Always

Steps to Reproduce:
1. Open http://therealcrisp.xs4all.nl/upload/firefox3_table_rendering.html
Actual Results:  
The table is rendered wider than the 400px specified. The content in the division in the first table-cell is not cut-off although overflow:hidden was specified

Expected Results:  
I expected the same results as in Firefox 2; that the table layout algorithm would try to fit the table within the specified 400px thereby using the overflow on the division to make that column smaller (basically the minimum width for that column can be calculated as being 0)

Comment 1

[crisp]

Attachment: testcase

Comment 2

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

This was intentional, per bug 402567 and bug 309110.

Comment 3

[crisp]

Well, I'm not to happy about that since it breaks our production site, eg the table on http://tweakers.net/pricewatch/cat/344 where we have the productnames in blocklevel anchors with overflow:hidden (and using some javascript to simulate text-overflow:ellipsis in Firefox). Now we had to make it javascript-dependent in order to make the table fit within the boundaries of the layout (something we already had to resort to for IE).

This will certainly also make it hard for Mozilla to ever implement text-overflow that will work within table-cells, something only Opera seems to get right at this moment.

Is the reationale behind this change only the better compat with IE's implementation (where text-overflow also only works in table-cells when you use table-layout:fixed)? Than I'd say this is actually a step backwards...

Comment 4

[Martijn Wargers (dead)]

Yeah, this is for better compatibility with IE.
I wonder if a special CSS property would give min width of 0 back for scrollframes, but I guess that's probably a bad idea.

Comment 5

[crisp]

IE does support text-overflow but also makes it impossible to use that within non-fixed layout tables which is already a pain. Therefor this change seems unlogical to me and also makes it more of a pain to simulate text-overflow in Firefox for such tables.

I would favor some css property to get the old (and sane) rendering behaviour back; perhaps text-overflow would be an idea? ;)

Comment 6

[Martijn Wargers (dead)]

I'll make it blocking the bug that caused it at least, to be able to track what amount of trouble it is causing.

Comment 7

[Martijn Wargers (dead)]

So you fixed this now by using the javascript-dependent solution like in IE?
There is some talk in bug 407257, comment 35, about letting authors a way to choose between the two behaviors, but not sure if something is going to get implemented.

Comment 8

[crisp]

Yes, we use a colgroup in which we 'mark' a col-element as defining the column in which the cellcontent may be 'cut' (ellipsed in browsers that support it) in order to fit the table to it's defined width. We then use javascript to (re)calculate the width for each column and explicitly set these widths on each col-element.

The actual content of these tables varies too much to be able to use fixed tablelayout.

It's a real pain having to do that, not only because it requires javascript but also because reflow is needed (performance issue) and is visible to the user.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to comment #4)
> Yeah, this is for better compatibility with IE.

(and WebKit as well).


(In reply to comment #5)
> I would favor some css property to get the old (and sane) rendering behaviour
> back; perhaps text-overflow would be an idea? ;)
(In reply to comment #7)
> There is some talk ... about letting authors a way to
> choose between the two behaviors

Bug 433621 is filed for this.