Page is a not externally linkable
rocknbil - 4:04 pm on Jan 7, 2012 (gmt 0)
in very general terms, how you might approach a page like this. I am using the nested tables to hold expandable graphic tables in place and control where everything lies, perfectly.
Lies perfectly - visually. The second step in moving forward is that "visually" is only part of the puzzle. Details on that and part one below . . .
That being said,
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Start by using a full valid doctype [webmasterworld.com] and validating your code [validator.w3.org]. This is critical to making CSS and table-less layouts cross browser compatible. If you stick to this, it will cut out at least 90% of your cross browser problems.
Visualize your "outer table cells" as containers, without tables. Example, this conversion is equivalent
<table>
<tr>
<td width="33%">33% on the left</td>
<td width="66%">66% on the right</td>
</tr>
</table>
<div id="container">
<div id="left-section"> 33% on the left</div>
<div id="right-section"> 66% on the right</div>
</div>
One solution would be to float both the inner sections left and assign them widths. That's really the rub - there are MANY ways to solve the above, the float is my preferred way because I seem to be able to do it reliably and with the least amount of code.
In practical application your TOPNAV table could be as simple as
<div id="topnav">
<p id="home-top">HOME </p>
<p id="login-top">LOGIN</p>
</div>
#topnav { width: 100%; }
#topnav p { margin:0; padding:0; }
#home-top {float:left; width: 381px; }
#home-top {float:right; width: 600px; } /* or whatever */
Some tools to get you started,
Don't get "div-itis". Part of the whole idea lies in semantics (described a little more below). Divs (AND spans) are generic containers to divide page sections and should be used only when you don't want to assign semantics to the container itself. Before typing "<div>" one more time, ask yourself: is there a semantic container that describes this content better? Paragraph, head, list? Using my previous example, let's say the left part is a side navigation:
<div id="container">
<ul id="left-section"> <!-- 33% -->
<li>Item one</li>
<li>Item two</li>
<li>Item three</li>
</ul>
<div id="right-section">
<h1>I am the main page heading</h1>
<p>I am a paragraph, and the p tag announces to the
reading devices that is what I am</p>
</div> <!-- 66% -->
</div>
I see so many layouts that are terminal cases of div-itis - and the good part is, if you stick to this principle, it becomes easier to debug. Look how much easier it is to find </p> instead of a sea of </div>'s.
Work inward. Look at each outer section first, then look at your inner sections on their own. Using nested tables as an example, you can extract one of those nested tables, put it in a document by itself, convert it to semantic containers, experiment with the CSS, then add it to your parent layout.
Don't give up, and don't try to do it all at once. Apply a little bit every day. I didn't look at your layout long because you said you don't want it critiqued or solved, but begin with one question:
How can I eliminate THIS table today?
On days you're sick of slaying tables, you can expand your skillset in other ways:
Today's task: eliminate invalid attributes, like background in table cells, valign, align, in table cells and images, <center>, and other invalid HTML 4 code, and make sure I'm using the required alt in images.
Just one. You can't do it all in a day or two. Work on a site and eliminate one table at a time, see work inward above. Begin with the outer table.
Eliminate page markup used to represent spacing. and <br> are going to change if your visitor has different text size settings. They aren't even needed and can be emulated using margins and padding.
Take the time to experiment. I know, we need to get this thing done, pay the bills, answer to clients who want it yesterday, not to mention eating and sleeping at some point, but you can't do something like this on the fly and wing it on a client project. This can absolutely kill your reputation. You need to dedicate at least an hour a day (which you KNOW will grow into two or three) to just EXPERIMENTING. Maybe you tried to eliminate a table today and couldn't figure it out - use this learning time to beat that problem into submission. :-)
One last advice - this one may smart a bit but is the best advice, if you can hear it - get past what you know, and look at every criticism as an opportunity to grow. Too often we (I, included, used to do this a lot) address criticism defensively. When you do this, you've already dismissed the "attack" in your mind and are closed to developing your skill set, which is going to make this even harder on you. Recognize these as opportunities, and really listen - many people are glad to share with you and help you along. For example,
and would cause his site to load slower (microseconds if anything I assured the client). I KNOW these are myths, but the client has concerns.
Sorry, they are not. The search engine claim is indeed is false, but it does affect how well a page can index. The first step to moving forward is admitting the possibility that what you know has changed. :-)
A page will load slower in tables because the entire table has to render before it begins displaying content inside it. Second, what does affect S.E.'s and site accessibility is that the semantic meaning of a table is "Here is tabular data" in the same way a <p> means "here is a paragraph." These semantics tell reading devices - including SE's - the nature of the content. Tables are perfectly valid - for tabular data, an intersection of rows and columns. Try "listening" to one of your sites using a screen reader for the blind, it is extremely enlightening.
This conversion will help your sites in ways you may never have thought of - accessibility, usability, page speed, template interchangeability, cross platform compatibility - the list goes on.
And . . .when you reach what you think is the end of the road, still not done. Enter mobile apps. Tables will rarely work well on mobile apps. Table-less layout will get you much closer to that.
If I speak like a recovering table layout addict, it's because I am, thanks to the generosity of the minds on this board. :-)