325200 - By using display: block on tables, Firefox loses some of the CSS styles on the table

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect)

Description

[Ido Kanner]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060110 firefox/1.5.dfsg-4 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060110 firefox/1.5.dfsg-4 Firefox/1.5

When you use Javascript in order to show and hide tables, some of the CSS instructions (such as width and centering the table) get lost when the display returns.

Reproducible: Always

Steps to Reproduce:
1. create two tables.
2. one with css style that display contain "block" and bigger width then needed
3. one with css style that display contain "none" and bigger width then needed
4. execute a Javascript code that change the visible style of each table
Actual Results:  
The tables aligned to left, and looses the width that was given to it, and places the "default" width of the table

Expected Results:  
Keep the same width and alignment that was set by CSS.

I tested the same code with Internet Explorer, Konqueror and Firefox 1.5 for windows.

Internet Explorer and Konqueror display the tables currectly.

Comment 1

[Ido Kanner]

Attachment: Proof of Concept for the issue

This is a Poc that I created to display the problem.

Comment 2

[Thomas Andrews]

The proper 'display' type for a table is 'table,' not 'block.'  When you change your javascript to say:

  document.getElementById(CreateItems[value]).style.display="table";

it works.

Basically, when you set the display type of the table to 'block' it became the equivalent of a '<div>' tag.

Comment 3

[Ido Kanner]

Well, if I'll do the same code on divs , each div will keep it's CSS properties of width, height (I added height for div as well) and alignment, so if the table suppose to act as div, I think it might be a bug regarding on how the tables are working with the display: block value.

Please note that IE, does not support the 'table' value in display, and therefor there is a need to use the 'block' value instead if you wish to have multi-browser support for your web applications.

(In reply to comment #2)
> The proper 'display' type for a table is 'table,' not 'block.'  When you change
> your javascript to say:
> 
>   document.getElementById(CreateItems[value]).style.display="table";
> 
> it works.
> 
> Basically, when you set the display type of the table to 'block' it became the
> equivalent of a '<div>' tag.
> 

Comment 4

[Thomas Andrews]

I see this problem on the Mac but not on Windows.  Well, there is some display difference between the 'block' and the 'table' display, but it isn't nearly as severe.

On the Mac, the initial table is resized to be bigger than its specified width, because the <input> tags are too wide to fit within 550px.

But when you size a div (or "block") to 550px, and its contents are too wide, they overflow outside the div.  So when the display is set to 'block,' the rows and cells overflow over the right border.  It is not 'forgetting' or 'losing' the other CSS instructions - the block is being displayed as width 550px, and it is being centered, although the overflowed items make it look uncentered.

You could decide whether to use 'block' or 'table' based on the user agent.  That's not 100% reliable, since people can change their user agent string, but it is better than this current behavior, at least.

Comment 5

[Thomas Andrews]

Another possible workaround is to change your HTML by putting divs around your tables, so that they look like:

   <div id='AddItemX'>
   <table ...>
   </table>
   </div>
   <div id='AddItemY' style='display: none;'>
   ...
   </div>

removing the ids from the tables and the display:none from the Y table.

You can see this at:

  http://www.thomasoandrews.com/examples/mozilla/325200/workaround.html

Comment 6

[Josh Birnbaum]

> Please note that IE, does not support the 'table' value in display, and
> therefor there is a need to use the 'block' value instead if you wish to have
> multi-browser support for your web applications.

Actually, you can just set the display property to an empty value, which will pick up the initial value.  i.e.

document.getElementById(CreateItems[value]).style.display="";

Comment 7

[Andrew Schultz]

Can you attach a minimal testcase that just exhibits the problem you're encountering?  I don't know what to do with the testcase and/or what to look for.

Comment 8

[Ido Kanner]

Attachment: A simple poc2 based on the previous poc.

I removed any "form" base code, and kept only the structure of the table with pure text as fields.

When you'll change the select item from ItemX to ItemY, you will see that each table cell (td/th) have now a minimal width that is set by the item inside the cell (that depends on the row, and the maximal width of the table is the minimal width that it needs to display the longest row.

Please note that the border (that's why I kept it) is the border of each table, and the width of the whole table remains the same, only the internal table width is changed.

Comment 9

[Andrew Schultz]

Attachment: minimal testcase

With linux seamonkey trunk 2006013001, the cell does not expand to fill the table, which I would expect even for display:block

Comment 10

[Thomas Andrews]

From the CSS 2.1 standard:

   http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes

2 If the parent P of a 'table-row' box T is not a 'table', 'inline-table', 'table-header-group', 'table-footer-group' or 'table-row-group' box, a box corresponding to a 'table' element will be generated between P and T. This box will span all consecutive sibling boxes 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'. T and T's siblings may also be anonymous 'table-row' boxes generated by rule 1.

The CSS2.0 standard has similar language at:

http://www.w3.org/TR/REC-CSS2/tables.html#anonymous-boxes

That means that:

<table style='display:block; width: 500px;'>
<tr><td>A</td><td>B</td></tr>
</table>

should be treated the same (roughly) as:

<table style='display:block; width: 500px;'>
<table><tr><td>A</td><td>B</td></tr></table>
</table>

Unfortunately, this isn't valid HTML, but you could generate a valid version with the following:

<table style='display:block; width: 500px;'>
<tbody style='display:table;'><tr><td>A</td><td>B</td></tr></tbody>
</table>

There is nothing that implies that this <tbody>' should inherit the width of its parent block.

These two examples can be seen on the page:

    http://www.thomasoandrews.com/examples/mozilla/325200/example.html

Note, IE renders these two the same, as well, but that's because it is basically ignoring the CSS rules about tables.

Comment 11

[Thomas Andrews]

For what its worth, Safari renders my example the same as Firefox - it creates the anonymous table and it is not 100% of the parent block.

Comment 12

[Ido Kanner]

(In reply to comment #11)
> For what its worth, Safari renders my example the same as Firefox - it creates
> the anonymous table and it is not 100% of the parent block.
> 

Well, Konqueror 3.5.1 renders the table just like IE, so Apple did something to KHTML version of Safari.

Please note that the issue is a bit more complex then the pure CSS interpretation. You just proved that each browser open this to it's own interpretation, and that means that many web developers out there will make the code look bad for Gecko based browsers (not to mention Safari) and leave it working for IE users.

While I think we all should use standards, my web application, is mostly used by IE users, so this type of things will be much easier just to leave as-is and leave Gekco/Safari users in the dark. I have a list of many web sites in my country that does not support non IE users at all, and this type of issues actually can help us to stay with Gekco/KHTML/Safari/anything else and not try to use wine or whatever to use IE (My desktop is Linux by choice, and in my case, I do not have or want a Windows installation at all).

Comment 13

[Bernd]

We render the minimal testcase correctly a pseudo has the default width:auto. Can we mark this invalid? Or whats the remaining issue?

Comment 14

[Thomas Andrews]

(In reply to comment #12)
> (In reply to comment #11)
> > For what its worth, Safari renders my example the same as Firefox - it creates
> > the anonymous table and it is not 100% of the parent block.
> > 
> 
> Well, Konqueror 3.5.1 renders the table just like IE, so Apple did something to
> KHTML version of Safari.
> 
> Please note that the issue is a bit more complex then the pure CSS
> interpretation. You just proved that each browser open this to it's own
> interpretation, and that means that many web developers out there will make the
> code look bad for Gecko based browsers (not to mention Safari) and leave it
> working for IE users.

My point was purely explanatory.  I was not saying it was open to interpretation, but that Firefox is right and IE is wrong (by the standard only.)  Obviously, to the extent that IE is "the standard," IE is always right.

However, there have been several adequate workarounds in this example.  Comment #5 suggests adding divs around the tables and re-styling the divs.  Comment #6 suggests setting element.style.display to '' rather than 'block'.

Comment 15

[Ido Kanner]

(In reply to comment #14)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > For what its worth, Safari renders my example the same as Firefox - it creates
> > > the anonymous table and it is not 100% of the parent block.
> > > 
> > 
> > Well, Konqueror 3.5.1 renders the table just like IE, so Apple did something to
> > KHTML version of Safari.
> > 
> > Please note that the issue is a bit more complex then the pure CSS
> > interpretation. You just proved that each browser open this to it's own
> > interpretation, and that means that many web developers out there will make the
> > code look bad for Gecko based browsers (not to mention Safari) and leave it
> > working for IE users.
> 
> My point was purely explanatory.  I was not saying it was open to
> interpretation, but that Firefox is right and IE is wrong (by the standard
> only.)  Obviously, to the extent that IE is "the standard," IE is always right.
> 
> However, there have been several adequate workarounds in this example.  Comment
> #5 suggests adding divs around the tables and re-styling the divs.  Comment #6
> suggests setting element.style.display to '' rather than 'block'.
> 

Isn't the "workaround" (that I did before I reported this issue) should be ignored instead of the bug ?!

I develop web based applications. My company's customers are mostly using IE (about 99.98%), so it's either to develop only for IE, or to try and make the code work for all of the browsers. We try to make our products work on all browsers. But if something will not work on IE, we first make it work there!

Secondly, Gecko have its share of unsupported standards such as: https://bugzilla.mozilla.org/show_bug.cgi?id=82711 as one example (can you see the dates on that bug ? the last time I checked -> today, Gecko still does not support this property).

Read the following blog to see that it's a real problem that users see in front of their eyes http://blogs.securiteam.com/index.php/archives/267 .

IMHO the workarounds should be ignored, while the bug should be fixed and not vice versa.

Comment 16

[Thomas Andrews]

>IMHO the workarounds should be ignored, while the bug should be 
>fixed and not vice versa.

Sorry, but when 
   (1) Mozilla is doing the right thing according to the standard,
   (2) There are several workarounds to get the same behavior in IE
       and Mozilla
it would be silly to make Mozilla do the wrong thing just to be compatible with IE.  That's a lot of work, especially since we have no idea what the next version of IE will do.

Yes, there are areas where Mozilla doesn't fully implement standards, that doesn't mean that it also ought to break the standard in other places to mimic wrong behavior in IE.

Comment 17

[Bernd]

Marking the bug as invalid per comment 13, please use the forums for policy discussions and not the bug. Reopen the bug if you think that mozillas rendering of the testcase violates the CSS spec.