1

I'm trying to fill 100% of the viewport in WebKit (Chrome) using maths.

What I'm doing right now is counting the number of elements and dividing that into 100 and then setting all of the widths for the elements to the resulting percentage, following the basic plan of liquid elements.

The problem is that as the number of elements gets very high, but even after the first few are added, there quickly begins to be an issue where a large amount of space opens up on the right of the elements as the browser fights between percentages, pixels, and rounding.

So my question is, how might you go about taking a variable number of elements and ensuring that the entire viewport is filled?

CSS and Javascript are both fair game, but I would prefer to avoid jQuery unless it has an incredibly simple solution. However, if you can only do it through jQuery, even if it's longer, post it anyway and I can see if I can unravel it.

I should stipulate clearly that this solution must work for a liquid layout. The browser and the containing elements must be able to resize down to about 200px. Any solution that depends on cutting apart a known quantity of pixels won't work for me.

I've published a test site if you're not sure what I mean.

Tim Visher
  • 12,786
  • 16
  • 58
  • 66

2 Answers2

1

display: table to the rescue!

The problem with my initial solution, of course, is that the elements are floated left and then given explicit widths. The upshot is that as the browser rounds the widths to the nearest pixel, you get jumpiness on the right-hand side of the viewport as you slowly gain and loose total pixels.

The beauty of a table is that the browser already knows that each cell should fill exactly its portion of 100% of the table's width. If the table is 100% as wide as the viewport and you have 4 cells each cell will be 25% of the viewport. Add another and the browser gives each cell as close as it can to 20% of the viewport. It handles all rounding for you so at any given time some of the cells may be a pixel bigger than other ones but the difference is always a pixel and the viewport is still filled perfectly.

The only downside I can see is that you need to have elements that you can put stuff in to be able to use display: table-cell because table cells are non-block level elements and can't be given explicit widths. They need content in order to display. Luckily for me, I can have a ul with li elements filled with a elements and thus I can hang the CSS nicely.

For the list

<ul class="mess">
  <li class="mess-part"><a href="#"></a></li>
  <li class="mess-part"><a href="#"></a></li>
  <li class="mess-part"><a href="#"></a></li>
  <li class="mess-part"><a href="#"></a></li>
</ul>

You need to apply the styles

.mess { display: table; height: 300px; width: 100%; margin: 0; padding: 0; }
.mess-part { display: table-cell; height: 100%; }

And you get a nice, pretty, 100% wide, always filled, liquid-layout spread of elements.

I've published an interactive version of the fix.

Pretty neat, eh?

HT to this question for getting the gears in my head turning.

Community
  • 1
  • 1
Tim Visher
  • 12,786
  • 16
  • 58
  • 66
0

Maybe because for example 5.4% is rounded to bottom, so if you got 10 elements, which all miss 0.4% you are missing 4% of the page, so if you got 20 elements, your missing 8% and so on. Maybe if you Math.ceil 1 element and Math.floor the next one. You will have less white space on the right side. Because you then only miss 0.2% each 2 elements. But still generating a white space.

What is the best solution is to not use % but us PX. Because those are round to PX instead of % which is a lot more. But then still you can use Math.ceil and Math.floor to fix the floating point numbers and have no white spaces anymore.

Niels
  • 48,601
  • 4
  • 62
  • 81
  • I think the best (in terms of result, not in terms of performance) way is calculate the rounded width of the first one (in pixels or percentages), then subtract this from the total remaining width and calculating the next one, etc. That way you'll be sure to use all of the width of the container. – Mr Lister Dec 28 '11 at 14:44
  • @ Niels But if you set the width of an element in pixels, the element won't grow or shrink when the window is resized by the user. Unless you call the calculation routine every time the window gets resized, but that's not a pretty sight. If you put the width in as percentages, the resizing happens automatically and much more smoothly. – Mr Lister Dec 28 '11 at 14:47
  • Thanks for the response! Check out my edits. The solution needs to be liquid width. – Tim Visher Dec 28 '11 at 17:50