You are seeing this very light version of the page, as you are using an outdated
browser!
Onlinetools.org is done in XHTML 1.0 and supports CSS 2.0, please upgrade your
browser if you want a better version of this site.
Thank you, please help us developers keep up with the industry rather than patching our code for outdated applications.
What are "stretchy" pages?
The advantages of stretchy pages
Problems with stretchy pages
How to make stretchy pages
How to design stretchy pages?
What does it mean for HTML Programming?
Are stretchy pages heavier than non stretchy ones?
Stretchy pages are HTML documents that have no fixed width, they rather use the whole screen. The table structure defining the spines and the content are not fixed, but a percentage of the whole window.
If you resize the window of your browser, the page will be resized accordingly. The typeface and the graphics will not resize, and that can cause some weird word wrapping to appear when someone has a really small browser window. Resizing typeface is only possible in flash.
Now what is so great about stretchy pages?
Stretchy pages do make sense, as everyone can read the page no matter what resolution or window size he (or she of course) uses.
People nowadays use higher screen resolutions like they did 2 years ago, a resolution of 1024x768 pixels is more or less standard. And there is nothing as annoying as a page that glues to the left of your screen with 740 pixels width and a blank white rectangle using up the rest of your monitor.
This shiny white unused space is not only wasted when it comes to offering info and advertisements to the user, it is also straining the reader's eyes unnecessarily.
Black on white is good in print, as the eye recognizes the copy as a reflection, light makes the paper readable for us. Monitors, however, send light into the eye and thus make it 10 times more tiring to read longer texts.
This effect increases with the amount of whitespace used. Using the whole screen allows you to use longer texts, as you are not dependent on the pixel dimensions anymore. It simply makes the page appear more compact.
Just make sure to set a certain limit to the width of the copy. Lines that exceed a certain length are tiring to read all the same. Find a solution that keeps the page flexible, but does not display the text on one line for users running very high screen resolutions.
And where is the catch?
The main problem of stretchy pages is that you give away the look and feel of the page to the user. Resizing the browser results in new copy-breaks and things can look nicely arranged or totally crammed.
The technique how to do stretchy pages in HTML needs tables to be flexible, using parts with background color only, to allow stretching.
Tables with sliced images and copy can soon become a nightmare to code and result in loads of nested tables.
With only one spine, copy could become too wide to be readable without being tiring. Usability tests proofed some years ago that anything that exceeds 14 cm on the screen will not be read.
A high resolution screen could look empty when there is not enough copy to display.
Still, how can stretchy pages be done?
Stretchy pages are done using percentages of the window size rather than pixel values. This works nicely with width attributes defining the horizontal size, but height attributes of tables are dodgy and not rendered the same in all common browsers.
Using percentages means you always have to try to make it look as good as possible in all resolutions as mixing defined widths and percentages is very hard to do and not very reliable. Worst case scenario is that the user sees a horizontal scrollbar.
What about design?
Stretchy pages do have a leaner and less complex design than non stretchy ones. If you need to put a gap between copy and a graphic you use a percentage of 1 in this table cell. Depending on the resolution and the size of the window , this can be from 6 up to 20 pixels.
Consider a design now, that has vertical black lines in it. Without using browser-custom cascading stylesheets, you'll have to add a 1 percent table cell with an embedded table, that has a defined width of 1 pixel and background color. Stretching a 1 pixel graphic will not do.
Some things in the design should be avoided
Let's consider the following:
You have a logo and five buttons to display. on a stretchy page, you have the following options:
All in all layouts should be a lot more flexible than fixed ones. Define parts of the page that can be covered only by using background colour, these will be the stretchy ones.
Now, what about the HTML?
Coding stretchy pages is not as easy as it appears. The first thing that you should be aware of is that you have to use nested tables a lot.
As you cannot consider a table that is defined by percentages to be accurate, you create a main table for the document with percentages and put fixed tables in the right and left spine to avoid the spines to stretch out too far.
This is especially needed when the spines need to be as high as the main content. If your design allows left and right tables to have their own height independent from the content, you can use the "align=left" attribute in the table tag to make the content appear next to the menu rather than below it.
Designs that allow this can become really fast rendering and low-weight pages.
However, most stretchy pages tend to become more complex than fixed ones, and the collapse selection option of homesite surely is your friend while editing.
Stretchy tables are also likely not to display rowspan and colspan definitions as good as fixed ones do, so if possible, avoid those.
In the content part of the page the best thing to do is to avoid tables. You can define layout to a certain degree by using paragraph alignment and align attributes in images is to avoid a three level nesting of tables. Also the hspace and vspace attributes can save some headache there.
Hmm, doesn't that add a lot to page weight?
As you need far less blank gifs to define widths, stretchy pages normally tend do be smaller and easier to read than defined ones.
So much for the dependencies. As you need to nest tables, however, the document may become big and surely takes some more time rendering by the browser.
So all in all the pages will not display faster, but there will be less interaction between the server and the client.
Considering the added flexibility and increased usability of the page, this is a small price to pay.