Markup suggestions for a layout and some more general questions

Question

Let me explain the basic layout below:

|----------------------------|
| title banner               |
|                            |
|----------------------------|
| logut-row                  |
|----------------------------|
|      aN                    |
|    <<to be explained>>     |
|                            |
|                            |
|                            |
|                            |
|                            |
|                            |
|----------------------------|
| footer                     |
|----------------------------|


a1:
| Use entire width for text  |
| and images.                |

a2:
|nav- | con                  |
|iga- |                      |
|tion |                      |

a3:
|nav- | con1     | con2      |
|iga- |          |           |
|tion |          |           |

a4:
|nav- | con1  | con2  | con3 |
|iga- |       |       |      |
|tion |       |       |      |

• "title banner" will contain one or two images and will not be clickable.
• "logut-row" will contain text and some form elements enabling the user to logout.
• "footer" will contain some links and some text.
• All three of the above mentioned parts will have one column only.
• "a" could be no columns (a1), two columns (a2), three columns (a3) or four columns (a4).
• "conN" is the main content where N could be the empty string or 1-3.
• The content could be in 1-3 columns with a navigation menu column. There is also a special case where there is no navigation menu column and a single column.
• The columns will be separate parts. No text beginning in col1 will continue in col2. Rather col1 might hold text and col2 some unrelated information like a list of the latest news.

---

Questions about the layout: (Nr 4 is most interesting)

1. We tought the width could be fixed and around 1000px. Comments?
2. Should we specify the width using em to make the layout more scalable for different font widths?
3. Since the web site will be launched in about a year from now we skip support for IE6 and focus on IE7, IE8, Firefox 3.x+ and Safari (version to be decided). Comments?
4. Suggestions on the markup and CSS for this?
5. Which version of (X)HTML and CSS would you recommend? Why?
6. Do you think a version for devices with small screens could simply be based on a custom CSS or would it need differences in the layout markup?

Answer 1

For number 1, I suggest fixing it at 960px wide - see the 960 Grid System for examples and benefits. The number divides into a grid very nicely and should work in all major browsers (+ scrollbars) easily at 1024 x 768 (or 600-ish in netbooks) resolutions.

Answer 2

1. When deciding what dimensions to make a layout, I usually consult major high traffic sites like Google.com, Yahoo.com, BBC.co.uk, etc. They're usually decent indicators of what an acceptable layout dimension is. Right now, Google News has a layout which autosizes to 100% width, but has a minimum width of 765px. BBC.co.uk, OTOH, has a fixed layout of 974px. You may want to do your own survey of similar-type sites, but the site I'm working on at the moment has an 800px fixed width. It is a reasonable dimension for displaying the type of content we are offering, and it will not alienate netbook/sublaptop users.
2. No. A website's dimensions should be specified absolutely, in pixels, or relative to the screen/Window size. There's no reason to define the width of your layout according to the height (or width) of a typeface. Just because a bigger font size is used does not mean the user's screen resolution is automatically increased. Unless you are working with fixed-width/monospaced fonts where you can define the number of characters on each row of text, there isn't much point in making your layout dimensions proportional to type dimensions--your text will automatically wrap around the column width anyway.
3. Personally, I use frameworks like YUI or jQuery to shorten development time. These frameworks also largely conceal inconsistencies between different browsers. jQuery masks inconsistencies in ECMA scripting implementations between different browsers. YUI largely does the same but also provides advanced UI components and CSS resets that work across most major browsers. Beyond this, I no longer worry about supporting standards-flouting browsers like IE.
4. The layout seems pretty straightforward. If you understand how to build table-less layouts (box model, float, clear, etc.) and separate presentation from content, then you should be good.
5. XHTML 1.0 is the current W3C recommendation. I don't think XHTML 2.0 is supported by any major browsers yet. IE still does not even fully support XHTML 1.0, so it is best to write HTML-compatible XHTML. CSS1 is fully supported by most major browsers, while CSS2 is mostly supported.
6. We're planning to launch a separate version of the site with a format specially tailored to mobile devices. As tvanfosson mentioned, mobile users will likely be interested in different content from desktop users. Things like banners, photos, and other images will have to be removed or scaled down. Navigation interfaces and website flow will have to be altered as well.

Answer 3

1. Go for it - 800x600 are becoming rare. Think about resizable layouts, though - nicer, imho, than a fixed 1000-something.

2. No - a user with a small screen, but large fonts, will get hor-scroll, which is a big no-no.

3. IE7/8, FF3, Safari 3, and Chrome. Opera for bonus points.

4. Blueprint CSS. Reset CSS. jQuery for JS needs.

5. 4.0 Transitional or XHTML 1.0 if you use XML tools, CSS 1.0, with non-critical enhancements from 2.0 possible. Reasoning being that going X does not really matter if the page validates properly, and you lose some useful transitional attributes.

6. Could simply be based on a custom CSS. Depends on how many mobile users you have, how important they are to you, and the nature of the site.

Answer 4

With respect to (6), the tack we are taking (as are many others) is to have a completely separate interface for mobile devices, where the likelihood of mobile devices hitting the site is reasonably high. In the cases where mobile users are likely to want to access the site, we figure out what pieces they are most likely to want and write a separate app to serve up those features with the best possible interface for mobile devices. We are primarily targeting the iPhone since it's the dominant mobile device that we see accessing our sites.

Our main points of emphasis are what I would call "context" data -- maps, "live" data, etc. The idea is that you might have a lot of static information, but the requirement for that while you're on the go, is relatively small. What is of interest is data that is important to getting there (maps, weather, traffic) or information that may change whether I go or how I get there (closures, availability). Of course, this is highly dependent on your user population and their choices with respect to how they prefer to get information.