Click Here!
Evrsoft.com
  Web Development, Web design, HTML code, HTML tutorials, Javascripts, DHTML, ASP, Perl, CGI scripts  
YOU ARE HERE: Home : Articles : The Great Fixed Vs Relative Table Width Debate
Web Hosting  •  Website Tools  •  HTML Tutorials  •  PHP Resources
The Great Fixed Vs Relative Table Width Debate
By Christopher S L Heng
Visit any web design newsgroups or many of the web authoring guides on the web and you will probably encounter a large number of people proclaiming the evils of having a fixed table width and recommending that you use relative table widths for your tables. On the other hand, if you view the source HTML for the websites you visit, you will find that a large number of them use fixed table widths. Which should you use? As we will find out in this article, the issue is not as straightforward as the proponents of relative table widths make out.
 
For the uninitiated, a fixed table width is one where the width of the table is specified in pixels. For example, the following HTML snippet will most likely produce a table that is 597 pixels wide:
 
    <TABLE WIDTH="597">
 
I say most likely because other factors may cause the browser to display the table at a different width, such as if you were to put an image in the table that is wider what you specify here.
 
A relative table width is specified as a percentage of the width of the visitor's viewing window. Hence the following snippet will most likely produce a table that occupies 80 percent of the screen:
 
    <TABLE WIDTH="80%">
 
1. The Case For Relative Table Widths
 
The arguments raised in favour of making your tables take a relative width usually revolve around the fact that such table widths will yield pages that work regardless of the visitor's screen resolution.
 
For example, a table width of "100%" will always span the entire width of the browser window whether the visitor has a 640x468 display or a 1024x768 display (etc). Your visitor never needs to scroll horizontally to read your page, something that is regarded by most people as being very annoying.
 
With relative table widths, you need not worry whether to code for a restrictive 640x468 display, often regarded as the lowest common denominator (although it is not), or for the more reasonable 800x600 display.
 
2. The Case For Fixed Table Widths
 
At the time of this writing, the pages on thesitewizard.com were constructed with relative table widths. They probably look fine if you were using a 640x468 or 800x600 display. If however, you have a wider display, try viewing it with your browser window expanded to its maximum width (ie, "maximize" it, in Windows lingo).
 
Did you notice that a number of the paragraphs that used to occupy a decent few lines are now displayed as single lines? The article now looks like an elementary school essay - with single lined paragraphs and lots of space in between.
 
Essentially, when you use relative table widths, you have less control over the appearance of your page. It will appear as wide or as narrow as your visitor's browser. As a result, when the browser window gets too wide, everything will appear stretched out. When the browser window gets too narrow, your text and graphics in the various columns will suddenly be misaligned.
 
If you were to create a fixed width table, that table will retain its proportion regardless of the visitor's screen resolution. Of course if the resolution drops below the fixed width you assigned, the visitor would have to scroll horizontally. But at least your page still appears as you planned.
 
3. The Rock and The Hard Place
 
With all the foregoing, which should you use? As long as screen resolutions continue to be as varied as it is now, and as long as the HTML standards do not allow web authors to specify things like "if resolution falls below 640 pixels, use a fixed width of 640, else use a relative width of 80% (etc)", no single solution is going to satisfy everyone.
 
Generally speaking, if you want tighter control over the appearance of your pages, fixed table widths might be the route you have to take, although of course it may cause grief for people with lower resolutions than what you designed for. You should probably test your page under a 640x480 resolution to check if the problems visitors have with that screen resolution are tolerable.
 
If you do not need such a tight control, you might prefer to go with the advice of the majority of web design guides and use relative table widths for your site. You still need to test your page under a 640x480 resolution to see if your layout and alignment goes haywire under a lower resolution.
 
Incidentally, using a fixed table width does not mean your page will look fine under higher resolutions. If your table has a fixed width of say 600 pixels, and a visitor using a 1024x768 resolution system views that page, he'll see an undistorted copy of your table in a sea of white space.
 
Designing for different resolutions can sometimes seem like you are standing between a rock and a hard place. Don't believe the people who say that the use of one method over the other will solve all your problems. You still have to test your pages under a reasonably high resolution and a low resolution to see how it appears. In most cases, you will have to live with some imperfections when your site is viewed under extreme settings.
 
And of course when they invent the 2000x1000 displays...


Source: Copyright by Christopher S L Heng. All rights reserved.
Get more free tips and articles like this, on web design, promotion, revenue and scripting, from http://www.thesitewizard.com/.


More Articles



.

News
  " TARGET="_blank">...

...

...

...

...

 
More News  
Interactive
[an error occurred while processing this directive]
Misc

Join our newsletter!
Join our eNewsletter
for software updates,
freebies and more!


      Subscribe
      Unsubscribe



30,674,408
Domains
Registered Worldwide
...more statistics

Click Here!

 


  Articles are submitted to EDN and licensed from various content sites.
  To report abuse, copyright issues, article removals, please contact [violations (at@) evrsoft.com]

  Copyright © Evrsoft Developer Network. Privacy policy - Link to Us

Contact Evrsoft