CSS Layouts: The Fixed. The Fluids. The Elastic.

Which Cascading Style Sheet (CSS) layout is best? All have their quirks and their unique pros and cons. Is one more accessible than the other? More usable? What are the drawbacks and how are they dealt with? Is one easier to create than the other? Is there an evil, inaccessible layout? I suspect some will say yes to this, but I’m not going to. I like them all and feel all are suitable if steps are taken to ensure easy usability and equal accessibility. All are part of a web site’s presentational layer, so most of the accessibility relies on the extractable semantics and proper usage of the underlying mark-up. What follows is my take on the rigid fixed, the adaptable fluid, and the expandable elastic layouts.


Fixed Width Layouts

A fixed width site is one where the main wrapper is set to a specific immovable width independent of the user agent’s display resolution. A common and considerate fixed width is 760 pixels, a size that ensures users with 800×600 resolution monitors have close to full window viewing without annoying side-scrolling.

The Fixed Width Pros
The main readable content area is tightly controlled without having to set minimum-maximum width (which isn’t universally supported, anyway).
Fixed width layouts are sometimes easier to style depending on the effect you’re after. Some visual designs can only be achieved in a reasonable manner with a fixed width layout.
Based on the example width above — 760 pixels — the typical main content area will be in my opinion an ideal width for optimum readability.

The Fixed Width Cons
My precious “ideal width for optimum readability” pro-listing above can go bad if the text is enlarged greatly since the line-width-to-text-size ratio doesn’t increase along with text resizing. Do note, though, in a good design, this is only a problem if the text is huge.
People with small monitors (640×480 pixels) will end up with a horizontal scroll bar on a 760 pixel fixed width site. This is a very uncommon problem.
A 760px fixed width site can look too narrow on large screen displays.
The narrow width can limit the reasonable number of columns and content, but this may actually be a pro. Think forced moderation.

Some Fixed Width Advice
Place your fixed width content on the left hand side of the page so on a typical site 640×480 pixel monitor users won’t have to side scroll to read the site’s primary content.
Be sure to provide a handheld style sheet to accommodate smaller devices. Supplying projection and TV media-type style sheets may also be a good idea.

Fluid or Liquid Layouts

A fluid or liquid layout is created by not specifying a wrapper width at all or doing so using the percentage unit of measure. In other words, barring borders and padding screwing things up, a 100% width site will take up the entire view port width without producing a horizontal scroll bar.

GrayBit.com is an example of a fluid width site. It resizes to under just under 755 pixels before sprouting a scroll bar, but the use of the scroll bar isn’t required to access the content. In fact, the site remains perfectly usable down to about 560 pixels after which elements start overlapping, getting concealed, or dropping. Most fluid layouts have limitations like this and most that I’ve seen don’t perform well on handheld devices unless styles are removed or a handheld style sheet is furnished.


The Fluid Layout Pros
If done right, a fluid or liquid layout can adapt to just about any view port width making it quite universal. This is seldom a reality, but in theory, and if care is taken to ensure it, it is possible.
Fluid widths match the browser default layout method making this the “purist” of them all. But does a developer’s want of site purity sometimes stand in the way of usability? I think it may.
The fluid layout makes the most out of available screen real estate. More content should be above-the-fold (meaning it’s available without scrolling in any direction). But…

The Fluid Layout Cons
Too much available content and a strong desire to fill white space can be a detriment to usability. Too much content can confuse the user and make a site too congested or cluttered. There is an expression: “White space sells” and it’s a truthful statement, even on the web.
If width limiters using the CSS property max-width — which isn’t supported by Internet Explorer (IE) version 6 or older, by the way — aren’t supplied, you may very well, in your quest for layout purity, create a site that is at best difficult to use. Try reading a line of text that is over 1000 pixels wide and you’ll begin to see the problem.

Some Fluid Layout Advice
Use this layout method purposefully. Don’t do it because it’s “pure” and for no other reason. I suspect there has to be a better reason than this. If you do create a fluid width layout, make sure it fits in a large variety of view port sizes. Else, why bother?
If you’re making a fluid layout site and have fixed width content areas, you have essentially made a fluid/fixed width layout hybrid and can only be as narrow as the width defined by the fixed width content section or largest object. Be careful. If you’re going to make a site that is fluid, make sure it’s really fluid and not just in name only.
If you do create a fixed/fluid hybrid anyway, like that shown on my CSS tutorial, make sure it fits 800×600 view ports.

Elastic Layouts

An elastic site’s main wrapper and other elements are measured using ems as the unit of measure. Ems are relative proportionally to the text or font size. Thus, as the text size is increased, the sections measured in ems will increase in size as well.

An elastic width example can be seen in my CSS Zen Garden submission (limited elastic-fluid hybrid). To the best of my knowledge, this is the only CSS Zen Garden submission that is elastic and meant to be as accessible as the non-editable markup would allow. I’m proud of this project.

The Elastic Layout Pros
If done right, this is a very stable layout method because everything resizes at the same rate. The result is nothing changes disproportionally.
An elastic layout is challenging and cool as hell. The first time I saw one was Tommy Olsson’s site (which happens to be an exceptionally well done example of how an elastic site should be done). This blew my mind, made me laugh, and generally impressed the hell out of me. Elastic width sites are best enjoyed by enlarging the text using ctrl and mouse scroll wheel… let me hear you say “Zwoop.”

The Elastic Layout Cons
Aside from the cool factor, I don’t really see much of a benefit to this type of layout. This makes me wonder what the point is.
Unless limited, this layout method can be a usability disaster as it’ll get wider and wider and wider — without benefit.


Some Elastic Layout Advice
If you’re going to make an elastic layout, make sure it works on small monitors. Else, what’s the point?
Limit an elastic layout specifying a max- pixel or fluid width measurement (hybridize it). For instance: #wrapper { width:60em; max-width:98%; }. Purists may argue that it’s not a true elastic layout if it’s limited or hybridized, but I really must ask: who cares? Again, layout purity is all fine and good, but not when it’s at the expense of usability.
Remembering that IE 6 and older doesn’t support max-width, try to start narrow enough that the text can be enlarged to its highest IE setting without producing a scroll bar at 1024×768. You’ll see that is the case with my CSS Zen Garden submission. To step it up a notch, you can make it narrow enough that it’ll be enlargeable to it highest setting in IE on an 800×600 monitor as well. An example of this can be seen on my skinny elastic web hosting site (limited elastic-fluid hybrid). I do plan to re-do this in less than a year, but the link is good for now.

In Summary
As you can see, all of these layout methods have their pro and cons (can you think of others?). As far as which one is better I don’t know. It is just a site’s presentational layer as I noted previously, so with a little care and consideration, I think all of these methods are solid and usable when creating accessible, usable sites. That said, I do suggest not falling into the web purist trap of doing things because they’re more “pure,” sometimes at the expense of usability or accessibility. I’m not trying to criticize those self-proclaimed purists, they make us think and are a source of insight, but if you follow that route, do so cautiously. Have a purpose and a plan. “Just because” is not a reason — or so I tell my kids.

Read more »

Formatting Tips To Speed up Your Website

While more and more people are getting access to high speed internet, there are many left on dial up. Be kind to those visitors and do a few, simple things to speed up your webpages. Not only will these tips give you a faster load time, most will also help keep your bandwidth fees low as well!

Use CSS For Faster Pages

Even if you decide to use tables, CSS can greatly improve your web sites load time! With your styles in an external .css file, the browser can cache all the formatting and stylizing for your pages instead of having to read each and every single tag all over again. Also it cuts down on long drawn out tags and replaces them with smaller class styles instead.

Use External Scripts

Use the same script on multiple pages? Switch to an external script. I'm not talking about remotely hosted, I mean loading javascript files from one source instead of adding all that code to each of your pages like this:

That way the browser already has it in it's cache and won't have to read it each time another page loads. This one saves a ton of load time, specially for larger scripts!

Remove Anything You Don't Really Need

OK, while this might sound obvious sometimes the hardest thing about creating a website is not using every fancy trick that you know. Images, flash and sometimes even sound files are very impressive.. but do you really need to showcase all your talents on one page?

Embedded sound files are something many people just find annoying anyway. You'd be surprised how many are surfing at work ;-). The last thing anyone wants is a loud music or sounds announcing to their boss that they're surfing. Also many people have their own music playing... hearing a song over top of what we're listening to is less than pleasant. As for Java applets, try to ditch them or if you want those effects, JavaScript unusually loads faster and can do just as much or more. Stand back and take a critical look at your website, you may see a few special effects that can be let go of for the sake of faster load time.

Avoid Nested Tables

OK, I'm not a big fan of using tables for layout anyway (I'm one of those people that believes content and presentation should be separate.. but thats another tip page). With that said, if in your templates tables seem necessary (or the easier way to do it), try to avoid nesting. Why? When you place a table inside another table, it takes a lot longer for the browser to work out the spacing since it has to wait to read the entire html and then work out the layout. If at all possible, try using CSS to create the columns on your page.

Avoid Full Page Tables for Faster Rendering

If you use tables, try avoiding the whole page being one big table. The browser won't show anything until it's read the whole thing that way. For a faster loading webpage, either try multiple tables (not nested) or having stuff above the main table to make your content in the first table show up faster. That way your visitors will have something to read while the rest of your page loads. It may not really make you page faster, but it will feel like it to your visitors.

Split Up Long Pages - Multiple Short Pages Load Faster

By splitting up long pages into multiple pages you not only make the content show up faster but many people that see a very long scroll bar give up. Remember, people's attention spans are often shorter than a grasshoppers (OK, not literally, but you get my point) since so much information is available at our fingertips. Try breaking it up into more readable lengths.

Remove Excess "Whitespace"

Whitespace is the spaces between your coding, removing the unneeded tabs and spaces can help a lot! Doing this will take a lot of extra bytes off the total size of your page and will speed up load time quite a bit. (Careful using automatic squishers, I find they often squish too much and makes it rather hard to edit later.)

Keep Your Code Clean

If you do use a wysiwyg editor, most times the will add useless code to your pages for example, many will leave empty tags (ie. ). Removing any of those excess tags will not only speed up your load time, but make you pages validate a lot cleaner.

Speed up Images Load Time

Don't Go Overboard On Images

While images can greatly enhance the look of a site they can really slow it down if there are too many. Try to decide if all your images are really needed (quite a few nice effects can be done with css, so sometimes images are unneeded.)

Height And Width Tags

When the page loads and the image size is already defined (ie. you've used the height and width tags), the browser knows where everything will be before the images are loaded. Otherwise the page has to wait and load the images before the text. Same goes for tables, so try to use width tags when possible on those as well for a speedier page.

Faster Images? Reduce Their File Size

There are many totally free, online image optimizers so you don't even have to install anything and it's extremely easy! Online Image Optimizer will greatly reduce the file size of your gif, jpg, or pngs and neither you or your visitors will be able to see the difference other than a page that loads a heck of a lot faster. They also keep the transparency and animations in gifs! For another JPEG reduction, try JPEG Wizard, also free, this one will only work with pictures in your hard drive not ones from the net. You can also choose some simple effects to be done (flip, mirror and rotate).

GIF vs JPG vs PNG

Personally on new sites I design I tend to go for optimized pngs. They have lossless compression (unlike jpgs and can be used without worry (gifs have the potential to have copyright issues) and load fast! With all that said, if you still want to use gifs and jpgs, here's a bit of fast info... If you don't need sharp resolution, choose GIFs over JPEGs, as GIFs generally load quicker. JPGs are generally best for photos, GIFs for anything else.

(I'd add a rant here about how Microsoft had held up the web's development with not making IE6 support png transparency... but *sigh* I've ranted about this already to anyone who will listen. Firefox, Opera and other modern browsers however have been able to show alpha transparency in png for years... oops, sorry, that was a mini rant after all!)

Source:http://www.webweaver.nu

Read more »