Hi all,
Google stats tell me around 11% of my visitors have a screen rez of 800x600. So I designed my ecom site to 760px wide fixed. It's not a big site, so fixed works fine.

I'd like to take the width to 960px wide.

I'm trying to present more marketing content while not annoying my 800x600 screen rez visitors. My plan is to keep the newly-added 200px on the right, populate it with "featured products" and such, but keep all the product info, cart and checkout content contained within the left 760px. That way the lower rez visitors can scroll to see more content, but won't need to to view products, order them, checkout, etc. Higher rez visitors can set their browsers to see everything without scrolling or not as they choose.

Or is an elastic layout a far better solution?

Most webdesigners would say that the 2. option is the best solution.

best regards,

atothek

My solution would be to use a fluid layout

If you're having trouble finding a layout that works, take a look at some examples on positioniseverything.net - in particular:

http://positioniseverything.net/articles/jello.html
http://positioniseverything.net/article … clean.html
http://positioniseverything.net/thr.col.stretch.html

They're far from pretty - but that's to show how the page divisions work - you just ned to style them to suit your needs.

<ak>Well done, this sites are working  fine without using tables.

I try to get knowledge in using divs at the moment. I´m quiet not sure what the benefit is,I researched that divs exist for a longer time, but browsers weren´t able to display them correctly.

</ak>

I like the elastic solution.  Its nice to be able to resize.

Also, you shouldn't expect someone to maximize their browser window to use your site.

I went with the elastic solution myself.  It seems like such a waste if a user has a 1280x1024 screen to limit my pages to 760px wide.  But of course like you've found, there are people using just 800x600 screens so I have to accomodate that as well.  The one drawback though is depending on the resolution it gets stretched to, it could start to look sparse in the middle, or on the other end fill up so much that they have to scroll down more.

Unlike Northie though I went with a more old fashioned approach of using tables.  I'll have to look into those references and learn more on how to use divisions for that.

or the other option is to use javascript to find out the pixel width of the browser window and if this is greater than 800 print some extra info to right of the document

browsers with a smaller width won't show it though document.write statements might not be read by spiders.

as always there's pros and cons

mobtex wrote:

or the other option is to use javascript to find out the pixel width of the browser window and if this is greater than 800 print some extra info to right of the document

browsers with a smaller width won't show it though document.write statements might not be read by spiders.

as always there's pros and cons

You can go one step further......

Server side scripting can re-write stylesheets and widths, etc, but being server side it can't detect browser screen sizes

Java script, being client side, can see the screen size, but I find re-writing with js is messy.

But client side scripts and server scripts have one thing in common - cookies.....

Here's the theory:

1. Server looks for a cookie that contains browser and resolution info
2. If the server can't find the cookie javascript is sent to set one (and then reloads the page)
3. If the server can find the cookie it can use that info to write a bespoke stylesheet for the user based on screen size, browser and OS

Northie wrote:

Here's the theory:

1. Server looks for a cookie that contains browser and resolution info
2. If the server can't find the cookie javascript is sent to set one (and then reloads the page)
3. If the server can find the cookie it can use that info to write a bespoke stylesheet for the user based on screen size, browser and OS

Now that's what I call accessibility!!!!!!:

We all know that the web isn't a static medium, unlike printed media, so why treat it as such?????

I think this is one of the best ideas of heard of, in regards to accessibility - 10/10 Northie

Just remember to be ready for people like me who disable javascript by default when getting to a new site.

Tink wrote:

Just remember to be ready for people like me who disable javascript by default when getting to a new site.

That must be tedious, I must see 100 new sites every day.......

Thanks for the input everyone.

Question: is there any advantage to building an elastic layout in html tables rather than only css?

cypressotter wrote:

Thanks for the input everyone.

Question: is there any advantage to building an elastic layout in html tables rather than only css?

Good question cypress...I would be interested in the answer to that one....Northie?...come on...you ALWAYS have them, LOL.

*I just give my customers the one they prefer...fixed or 100%.  Personally, I prefer 100%.  And like Steven, I use tables.

cypressotter wrote:

Thanks for the input everyone.

Question: is there any advantage to building an elastic layout in html tables rather than only css?

That's a heavy-duty question that raises alot of pro and con arguments -- suggest you read thru several of these websites to learn more and come to your own conclusion.

thebjer wrote:

cypressotter wrote:

Thanks for the input everyone.

Question: is there any advantage to building an elastic layout in html tables rather than only css?

Good question cypress...I would be interested in the answer to that one....Northie?...come on...you ALWAYS have them, LOL.

OK,

[sorry been away for a few days...lol....]

What was the question again? Oh yeah, why use css over tables.

1 - semantic code structure - SEs love them and if the layout is a little complicated then coding and styling becomes easier
2 - tables add too much code to the page (IMHO)
3 - tables are prone to break
4 - tables have a mind of their own unless extra styles and commands are put in (eg valign/vertical-align:top; or table cell widths)
5 - tables read and are drawn top-left to bottom-right. My css sites read (as rendered on-screen) top, middle col, left col, right col, footer

To be honest, point (5) - source ordering - is the biggest for me. I have had tremendous natural SERPs results from getting my relevant content near the top of my source code

I forgot one last point:

The separation of data and structure
The separation of structure and styles

When one has been doing all the programming using MVC principles it's hard to let it go on the final HTML output!

Northie wrote:

thebjer wrote:

cypressotter wrote:

Thanks for the input everyone.

Question: is there any advantage to building an elastic layout in html tables rather than only css?

Good question cypress...I would be interested in the answer to that one....Northie?...come on...you ALWAYS have them, LOL.

OK,

[sorry been away for a few days...lol....]

What was the question again? Oh yeah, why use css over tables.

That wasn't the question, was it?

There is no advantage to building elastic layouts in tables over CSS

My previous post highlights some of the advantages of building any site using css, over tables

IMHO I believe all good sites should be elastic/fluid

Northie wrote:

There is no advantage to building elastic layouts in tables over CSS

IMHO I believe all good sites should be elastic/fluid

We definitely agree on those points!

Northie wrote:

There is no advantage to building elastic layouts in tables over CSS

My previous post highlights some of the advantages of building any site using css, over tables

IMHO I believe all good sites should be elastic/fluid

Thanks for your humble opinion Northie!

travelagent wrote:

Northie wrote:

There is no advantage to building elastic layouts in tables over CSS

IMHO I believe all good sites should be elastic/fluid

We definitely agree on those points!

That makes three
Also need to remember that tables are designed for data.

ColoEagle wrote:

Also need to remember that tables are designed for data.

Semantics, great - that makes 2!