I have a table with 5 columns, 2 of which have a set width, the other three don't. Different browsers interpret this inconsistently.
Have a look at this fiddle in different browsers to see what I mean.
Firefox and IE9 render it the way I'd think correct: all cells have uniform width of 20% (two have a set width of 20% each, and the remaining 60% is divided between the remaining three cells).
Chrome, Opera, IE7 and IE8 force the empty cells without a set width to have zero width, which in turn forces the other two cells to stretch to 50% width each. Putting content into one of the three empty cells makes them take all available width (60% in case one cell has content, 30% if two, etc.). Likewise, removing the content off one of the two cells that have a set width results in a forced 0 width.
Which browsers got it right and which ones are doing it wrong?
Also, I perused the W3C spec regarding tables, but only found the description of the empty-cells property, which is supposed to control the rendering of empty cells with borders/background, but this does not affect the cells' width. I thought the table-layout property might do the trick, but while setting table-layout:fixed in Chrome does make all the columns appear, there is no way (or at least I don't see one) to do the opposite in Firefox. If you could elaborate on this and/or point me to the correct section of the W3C spec that covers this, I would really appreciate it.
The problem arises as the W3C haven't seemed to cover it yet, they haven't suggested any "right" way of dealing with this situation. The browsers have the liberty to interpret it the way they wish, in my opinion is the way IE9 and Firefox do it.
IMHO all the browsers are displaying things RIGHT. As a developer we should understand that what we expect from the empty cells. It is always better to define width or add some spaces even if your cell is going to be empty to achieve consistent display across all browsers.
put inside the "empty" <td>
Related
Two divs, one floating left, one right.
The first contains text (which is static) and has no fixed width, the other has a fixed width.
Is there a way to make the widths sum up to a certain value (eg. width of a containing div)? Preferably a CSS only solution.
The problem is different browsers give the text slightly different sizes, so the first div varies in its width. Setting a fixed width to the first div breaks it in the browsers which would have it longer. I can make it the longest I find, but I might have missed a browser, or the issue might return with a newer version.
fiddle: http://jsfiddle.net/jnfsmile/JcfGN/3/embedded/result/
(In chrome there is a gap between the divs, in IE 10 they overlap. I would like them to meet nicely)
Addition:
The same problem with height has been solved using line-height. Is there something parallel to line-width?
i have a nested display table in a display table cell and i doesnt seem to apply the 100% height to IE 8 or 9 (even a extra containing div wont work), works fine in all other major browsers, here the jsfiddle it should explain everything.
http://jsfiddle.net/bDm4d/12/
try that in firefox/chrome/safari to see how it should look and check in ie8/9 youll understand the issue. Both columns should be equal height, since they are both with in a display table cell. The center (green in the right, pink in the left) have height to auto so it "should expand" like it does in webkit/ff.
A work around for ie would be great conditional or not.
Unfortunately, display: table-cell isn't supported by IE. Luckily, there are several workarounds to get divs with display: block to fill the height of their parents, creating the 'equal height' effect. I found this article to be very helpful when I was faced with a similar layout challenge. Good luck!
Basically the problem I have is that in Safari/Chrome it is changing the width of my columns even though I have specified a) a width on the table, b) table-layout:fixed, and c) specific widths on my first row that when added with the padding and border values add up to the width of the table specified. In IE7 and Firefox 3 the table is rendered the same. But in Safari/Chrome it decides to make the second column bigger by taking space from the other columns.
Any ideas? I have a very simple sample page that you can look at, as well as an image showing how the table is rendered in all three browsers for comparison.
In buggy webkits, table-layout: fixed also gives your table cells box-sizing: border-box. One alternative to browser detection is explicitly set box-sizing: border-box to get consistent behavior across browsers, then adjust your widths and heights accordingly (widths and heights must be increased to include padding and borders).
#my-table td {
box-sizing: border-box;
}
I was able to get around this problem by removing the padding from the <th> with the fixed width. You can then safely add padding to the <td>
After looking around, I think that this is caused by the following webkit bugs: 13339 and 18565. Basically a problem with how it uses the border and padding values in calculating the final width of the columns.
I ended up doing some browser-sniffing and setting some different css values based on that for webkit browsers so that the final rendering was the same as FF and IE.
Have you tried loading some Reset CSS?
http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/
I made a Kendo grid have table:fixed-width. All the columns disappeared but only in Safari. Upon inspection, the td elements all have a computed style width of -3px. If I remove table:fixed-width, it's fine. If I specify custom pixel widths (but not percentages), it's fine. If I disable every style applied from every css source I can find (in the console style tab), the problem is not fixed it and nothing there sets width -3px.
So I have to either set all the column pixel widths or else not use table:fixed-width.
I've got three columns inside of a div that is the full page width. The two on either side are 25% width and the one in the center is 50% width. This layout is working fine except in IE6 where at certain page widths it bumps the right column to the next line. Is there a fix for this? Maybe an alternate way to layout a page like this?
Edit: I'm using a cross browser inline-block hack that works great in FF, IE, S, Chrome. I'm pretty sure this quirk has to do with the way IE calculates widths on fluid content, and happens due to miscalculation (rounding maybe?). I've put up an example here. Try slowly adjusting the window width in IE6 (maybe later versions too) and watch as the green DIV gets bumped down at certain widths.
Thanks,
Brendan
It's a rounding problem in IE6's box model. Generally, you can't have a combination equal 100%. Try making your values sum to 99% of total width, and it should work fine. This solution has always worked for me.
It sounds like a piece of content in that column might have a defined width which is more than what the 25% of page width it is given. Can you provide CSS examples?
EDIT: IE6 does not support inline-block which could also be the issue.
EDIT 2: I looked at it on a 1680x1050 screen in IE6 in a virtual machine. When I drag the width slowly over time from about 800px to 1600px, it randomly moves the right column around. I suspect it's an issue with the hack that you're trying to use. Your code is so simple that I think you should consider researching an alternate hack instead. I've also never seen the *<property>: <value> hack. What's the * do, all compliant browsers?
All the documentation I can find suggests that almost standards mode differs from standards mode only in the way images in table cells are aligned.
This question : Internet Explorer 8 and Checkbox CSS Problem, however indicates that the rendering in IE8 and Opera changed between the two modes, based on how checkboxes are interpreted. Certainly there are neither tables nor images on that page.
So, does anyone know of other differences between these two modes?
Yes, it removes baseline under inline images which are only child of their containers.
MDC reference.
The original almost standards mode only affected images in tables. Other browsers adopting the mode may of course have put other differences in it.
Form fields, and especially checkboxes, are tricky. The standards doesn't really cover how they should be rendered, so it's still pretty much up to the browser to make something reasonable out of it. Checkboxes are inline elements just like images, so some browsers may very well handle them similar to images.
This Microsoft article explains the difference and covers both the common case of images and baselines, as well as the behaviour of checkboxes that prompted this question:
http://msdn.microsoft.com/en-us/library/ff405794%28v=vs.85%29
It says that for Almost Standards mode:
Inline elements contribute to line height if and only if one of the
following is true.
If the element:
Contains text characters
Has a nonzero border width
Has a nonzero margin
Has a nonzero padding
Has a background image
Has vertical-align set to a value other than baseline
Note that a line break is not considered a text character for this
definition unless it is the only content of a line box. In that case,
the line box height remains the uppermost inline box top and the
lowermost inline box bottom on the line, regardless of the specified
line height.
If an img element is the sole content of a table cell, the line box
height of the cell line box height is adjusted to zero.