Skip to main content

When Table Cells are Smaller than the Table

I ran into an issue at work the other day that was a bit strange. A portion of one of our forms is using tables for layout (Yeah, I know... it's older code), in all other browsers the fields lined up with the others on the page, but in IE9 there was some unexpected extra space throwing the layout all off.

I took a look, and noticed a few things:

  • The table had a fixed width of 690px
  • There were only two columns in the entire table, but the second cell had colspan='2'
  • Both table cells had a fixed width
  • The sum of the table cells widths (including padding and all) was less than the width of the entire table

So what does all of this mean?

Well, the main issue is that, since the total width of the cells is less than that of the table, the browser has to figure out what to do with the leftover space.

Let's see what happens (I'm leaving off the colspan and adding some extra elements for demonstration purposes).

cell 1 cell 2
cell 1 cell 2

So it looks like the browser is distributing that extra, unaccounted space across the cells. And if you look close enough, that space should be divided so that the original proportions are preserved. That makes a certain amount of sense. But that's now what we wanted, so how do we fix it?

Well, the people before me set colspan='2' on the second cells. In most browsers, this essentially assumes a non-existant column that can be any width, which absorbs the extra space. All, that is, except IE9 (and maybe higher?).

Here's the table using the colspan trick.

cell 1 cell 2
cell 1 cell 2

But like I mentioned earlier, we found this doesn't work in IE9 (at least). This colspan business seems a bit hacky to me anyway, so I'm not sure I like it to begin with. So what now?

Well, in our situation anyway, the solution was easy... Take the fixed width off of the second column. That allows the column to flow freely and fill in the remaining space. We could have also removed the width from the table, but there was less risk of breaking something somewhere else by changing the cell width.

With the width removed from the second cell, things work as you would expect. This is one reason I don't like using fixed sizes for child elements. I prefer using proportional measurements (where it makes sense, of course. Sometimes you need those fixed sizes).

cell 1 cell 2
cell 1 cell 2
Labels:

Comments

Post a Comment

Popular posts from this blog

Be Careful Using SASS @extend, CSS3 Selectors, and IE8

I recently ran into a situation where some of my styles were broken in Internet Explorer 8. What makes this different from all the other times my styles broke in IE8 was that, as far as I could tell, it was correct. Consider the following code: %highlighted { background-color: #ff0; color: #333; } .keyword.is-active { @extend %highlighted; padding: 10px; text-transform: uppercase; } No problem, right? Then why isn't it working? I wasn't sure, until I looked at the compiled CSS and saw something like this: .some-list:nth-child(2n), .is-highlighted, .keyword.is-active { background-color: #ff0; color: #333; } .keyword.is-active { padding: 10px; text-transform: uppercase; } Since IE8 doesn't support the css selector nth-child , it ignores the entire rule . Without looking at the final output, there's no way of knowing if this will happen ahead of time. So what can you do? Well,...
Post a Comment
Read more

SASS Converts Zero Opacity 'rgba' To 'transparent'

I recently had a strange problem after updating SASS. I have a modal dialog with a semi-transparent overlay behind it. For modern browsers, I'm using a CSS transition from rgba(0,0,0,0) to rgba(0,0,0,.5) For older browsers (namely IE8), I'm using some JavaScript to apply the transparency and animate the transition. To make sure the background gets set correctly, I'm using the standard fallback strategy of defining the background as background: rgb(0,0,0); right before the rgba line. This worked fine, until SASS optimized my code by changing background: rgba(0,0,0,0); to background: transparent; The reason? It's 2 characters shorter. Yes, we've now saved 2 bytes of easily compressible text in exchange for breaking my code. Why did it break? Well, if you haven't already figured it out, normally a browser that doesn't support rgba will simply skip that property and move on. But transparent is supported. So now, instead of h...
Post a Comment
Read more

Flags vs Vendor Prefixes for Experimental CSS

Google recently announced that it will be switching Chrome's rendering engine to a fork of Webkit, called “Blink”. If you're interested, you can read their blog post about Blink . One of the changes we will be seeing in Blink, is the use of browser flags in place of vendor prefixes . What this means, is that rather than prefixing experimental CSS with -webkit-, -moz-, -ms-, -o-, -khtml-, etc.; We will be required to enable these attributes using a flag in the browser (like the ones currently at chrome://flags). If you ask me, both ways have their advantages and disadvantages. Though, in the end, I lean towards the flags over the vendor prefixes, and here's why: #1 Code Bloat On average, using CSS with vendor prefixes requires writing it 5 times . Every time you use it . #2 Future Friendly Eventually, prefixed code will be replaced by the unprefixed code. #3 Browser Dev Friendly Browsers tend to continue to support the prefixed code, even if it doesn...
Post a Comment
Read more