The only disadvantage to consider is that we need to drop support for Netscape 4, but I think this is well worth the innovation, as we can support 99% of our user base much better, who use some browser that actually works...
Tables where never meant to be used for page layouts, when we say remove tables is meant that we should we stop using it for this wrongful purpose, not entirely. Using tables for tabular data as it is intended is just fine.
Netscape 4 *actually* degrades really well, if you know what you're doing, by using *semantic* markup. For example:
<div class="main_text">
This is just our main body text
</div>
should be banned in place of this more correct markup:
<p class="main_text">
This is just out main body text
</p>
Simple reason is that <div> is a generic block element, it has no style or semantic value by default, whereas <p> does, and even if NS4 doesn't understand the CSS, it will still understand the <p>.
The problem is that Netscape 4 does interpret some CSS, and it does it the wrong way. We have a report of pages displaying wrong in Netscape 4 after my changes the last days (I made the left TOC bar on manual pages use semantic markup instead of tables). The reason is that NS4 interprets the CSS in a wrong way. This is why the @import trick exists to dismiss NS4 as a non CSS compliant browser.
I have tried to validate the frontpage as XHTML 1.0 Strict, as I have seen some "strange" invalid parts, like that input fields shuold be in some container, which I was absolutely anaware of. Though it seems there will be little to add to the pages to make them XHTML 1.0 Strict compliant, if someone is ready to do so.
The solution is that <form> may *not* be nested inside certain tags, but its contents *must* be. The following is valid XHTML 1.0 Strict.
<div id="search_form">
<form ...>
<p>
<input ... />
<input ... />
</p>
</form>
</div>
Ah, great. I was a bit lazy to look this up in the DTD. :)
Goba