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

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

Automatically Calculating Foreground Color using SASS

I ran into the problem, as I'm sure many others have, where I wanted to dynamically assign background colors to my components, but also needed to adjust the foreground color to be readable and visually appealing. It's easy for something to fall through the cracks when changing colors, and then we end up with unreadable text. So to try and avoid this, I put together a SASS function that selects a color for text based on the background color you give it. This also performs checks to make sure the contrast meets a given Accessibility spec (as per W3C rules). So far I've had pretty good results with it. Please feel free to tinker and use this in your own projects. It's far from perfect, but it has See the Pen Calculate Foreground Color by Thomas Pietrosanti ( @Rykus0 ) on CodePen .
Post a Comment
Read more

Element.focus() in IE9 running Jasmine tests with Karma

I recently udpated our Jasmine unit tests to run in Karma ; expanding our browser coverage, adding code coverage reports , and using fixtures for testing DOM manipulation . One of my tests kept failing in IE9, but only when I ran from the console. If I attempted to debug in the browser, everything passed. It turns out that IE9 (at least) needed a few ms to catch it's breath before correctly focusing on the starting element. To do this, I just added a 100ms delay before each test ran (Using Jasmine 2.3). beforeEach(function(done){ loadFixtures('myfixture.html'); // Setting focus in IE requires a delay to work correctly! setTimeout(function(){ done(); }, 100); });
Post a Comment
Read more