I realize that many people on these forums who prefer to use XHTML/CSS for layout. I still code using tables when I need something working quickly. Usually, the fact that I have to do a crap load of hacks in CSS just to get things to work right several different browsers is enough of a turn off. I am an ASP.Net/C# programmer by trade and the last thing we talk or care about is using tables vs CSS when creating our software. But I am in the process of teaching myself CSS based layouts. I understand why people choose to layout this way, but are there any examples of how NOT to code CSS based layouts. If there a best pratices when it comes to CSS based layouts?
I don't think there is any specific don't do's, most people would probably say aslong as the CSS along with the xhtml is valid then your doing everything right. As far as search engines go it would probably be suggested you don't use CSS to hide content from your users that you want there for Search Engine Spiders. I have only recently moved from table to 100% css and it is a bit daunting at first but after you do a bit you realise it was as short as its long. Don't know if that answered your question but I tried David
The BEST advice I can think of on modern layouts are as follows: SEPARATE CONTENT FROM PRESENTATION Constantly ask yourself if the attribute or tag you are adding to your html is just to style it, or if it's content. If it's changing the appearance, that's presentation, that should be in your CSS. There are some tags which will be unavoidable to use inside a paragraph of text - B, I, EM, STRONG - realistically inside a sentance to mark a word or two is the only time those should be used. <h2><b>TOTAL /FAIL/ AT INTARWEB</b></h2> for example is a serious whiskey tango foxtrot. Some tags flat out shouldn't be used anymore - FONT for example has NO PLACE in modern code. When marking up a section, you should also try to use not just tags that describe what something is, but also use classes that describe what it is, NOT how it appears. The whole concept of moving the presentation to the css becomes moot when you start doing nonsense like: <div class="center font12px padding4"> If you don't know what's wrong with that, back away from the keyboard now and take up basket weaving. This also applies to images - if the image is a border or some sort of replacement for text (like say a header) the image should be in your CSS, not as a img tag. Headers and buttons that use image replacement techniques can result in pages that are useful with images turned off, and can in fact be quite attractive that way. Do that, and your dialup users will love you for it. (and like it or not, they are still more than 50% of the installed user base - and if you've been to the american midwest you know why) DO I NEED THIS TAG OR CLASS/ID Whenever you go to add a wrapping DIV around something, ask yourself is it really necessary or can I apply this style to the parent container. Sometimes the answer is no, you need the extra wrapper - MOST of the time it is not. WAY too often you'll see <div style="width:200px; margin:0 auto;"> <ul class="menu"> <li class="item"><a href="#" class="item_a">Item</a></li> <li class="item"><a href="#" class="item_a">Item</a></li> <li class="item"><a href="#" class="item_a">Item</a></li> </ul> </div> Where all they are applying is: .menu { list-style-type:none; } .item { display:inline; } .item_a { padding:0 8px;} /FAIL/ at intarweb. Too many unnecessary classes poluting the HTML and double the needed code. Inlined presentation and wasted wrapper are just the icing on the cake. Should go something like this: HTML: <ul class="menu"> <li><a href="#">Item</a></li> <li><a href="#">Item</a></li> <li><a href="#">Item</a></li> </ul> CSS: .menu { width:200px; margin:0 auto; list-style:none; } .menu li { display:inline; } .menu a { padding:0 8px; } Usually with proper use of semantic tags like headers, properly dispersed and grouped inside classed divs, you can use a lot less classes and therin a lot less code. SHOULD I JUST USE A TABLE Your more rabid zealots will even try to go so far as to try and not use tables for tabular data (like a spreadsheet) - ALWAYS ask when you hear "never use that" is this rhetoric, or based in some sort of fact. Are they 'card stacking' giving some facts while omitting others? Are they just rabidly mimicking what they heard without thinking about it? There is a lot of good stuff in non-table layouts, but there are some things they just flat out cannot do reliably cross-browser and a LOT of misinformation and just plain nonsense being spouted by a good number of so called 'experts'. 1) Vertical positioning - DIV based layouts do NOT lend themselves well to centering dynamic height content top to bottom or flush bottom. PERIOD. Table WINS. 2) equal height columns with dynamic content - while a lot of the time you can 'fake' this using what are called 'faux columns', a lot of times that method ends up a total /FAIL/ and even more code or wrappers than a table - or worse 60k in images to do what could have been done with a tenth that. 3) Hackless 100% height model. This is almost always less code. I'm sorry, table for layout is NOT a hack - and I have yet to hear anything more substantial on the 'hack' claim than 'because "so and so" says so' - that rubbish didn't work on me in church as a kid, it's shure as shine not going to work on me now that I'm past "The age of reason". MYTHS ABOUT TABLES 1) Non-Semantic because it's not 'table data' - does it have columns? SOUNDS like tabular data to me. This arguement has little or no legs to actually stand on especially if you read: http://dictionary.reference.com/browse/table 2) Screws up search engines - Also total rubbish - no search engine is going to screw up just because it hit a table, if it did you'd not get results for products on Amazon, E-Bay, or the half dozen other sites that use table based layouts over the past DECADE. 3) cannot be source order for SEO - Utter Malarkey. You place a empty TD 1px tall, set the next two TD to rowspan=2, then add the first column AFTER the second two. 100% height model CSS styled SEO table layout anyone? http://battletech.hopto.org/for_others/3coltable_SEO/template.html 4) Ends up more code - Given that you can axe that stupid cellpadding=0 cellspacing=0 border=0 on all tables with the border-collapse CSS property, and most of the behaviors you want are the DEFAULT for tables - I really wonder where this particular myth came into being. 5) is non-CSS. See #3 and #4 WHEN NOT TO USE A TABLE 1) To wrap a single TD when you are not doing vertical positioning - utterly pointless but you see people do it all the time. 2) When you may want the ability to swap column order via CSS 3) to wrap multiple verticle elements who's columns do NOT line up. 4) in those cases where it indeed IS more code. Some really simple layouts just don't need a table... most of them being fixed width with relatively flat background colors. MORE STYLESHEETS? OH HELL NO The only good reason to add an extra stylesheet is to add a new media type - if you have to use conditionals or javascript to feed different stylesheets to different browsers, you are probably just doing something wrong in the first damned place. The ONLY browser you usually need to send different data to these days is IE6 or earlier, and you can inline that with * html. 99.99% of the 'hacks' to fix IE7 and IE6 can usually be inlined (haslayout for example) right next to their normal version. I don't know about you, but having the declarations for one media type - say screen - on one item - say the main menu - in three to five different files? To hell with that. If nothing else, all those conditionals result in larger HTML files for stuff that can and should be handled in the CSS file in the first bloody place. REMEMBER THE BASICS Some things NEVER change and should never change when it comes to coding any type of markup, scripting or programming. 1) Simplify, Simplify, Simplify - If you can do it with less code, do so. The less code you use, the less code there is to BREAK. 2) Do not dive for hacks until you have exhausted all other methods of doing the same thing. In HTML there are dozens of ways of doing each. If it doesn't work in ____ browser, try a different technique BEFORE diving for the hacks. 3) VALIDATE. Validation brings to HTML one of the BIG advantages compiling a program in a high level language has - removing buggy invalid code. For too long developers have had a free ride on invalid HTML rendering in IE - to the point that they cannot even FIX the bugs in IE without breaking large portions of the web (hence the whole REASON for quirksmode to exist) as people have become reliant on the behavior of the buggy code instead of just writing valid code in the first place. If tomorrow they fix that bug you are relying on, guess what - all your pages break. BAD IDEA ALL AROUND. Besides to be quite frank, if you cannot bother to at least TRY and write valid code, do us all a favor and stop now. 4) Test, Test, Test and Test again. EVERY time you make a new 'section' of the page, TEST it in each of the four major browser engines. With Safari now available for Windows and Parallels allowing OSX users to run XP programs - Most of us have NO EXCUSE not to be testing at least two versions of IE (6 & 7), Firefox, Safari and Opera. PERIOD. Even linux users don't REALLY have an excuse since they too can run XP in a window under VMWare. Testing each major code block as you add it usually means less work in the long run as once you have the entire page done, just finding where a problem is ends up major work and headaches, where if you just built the section and test, you know exactly where the problem is... a LOT of times a new element will mess up existing elements - finding that once the whole page is done is just asking to /FAIL/. It simply isn't that much work to hit alt-tab, F5, alt-tab, F5, alt-tab, F5, alt-tab, F5. Repeatedly you hear this 'Code for FF, hack for IE' rubbish right alongside 'Most people use IE, the rest should adapt' - both being equally flawed despite being polar opposites. Time and time again you see posts on forums like sitepoint, digitalpoint, IWDN, etc, etc asking "Why is my layout broken in _____" when they've completed the entire page, and are trying to diagnose a problem up near the top and patch it with a 'silver bullet' fix... often the REAL fix being that the entire page's code should be tossed in the trash and started over because the techniques being used just do not work well cross browser. Of course, this gets worse when you mix steaming pile of crap WYSIWYG's like Dreamweaver or Frontpage into the equation. 5) When in doubt, ASK! Even I from time to time (I know, it's hard to believe ) come up against something I don't know, and suddenly my google-fu fails me. Come to someplace like DP and ask. 6) If someone says start over, they might be correct. There is NO point in hacking buggy broken code into behaving properly if it's going to take you three days of hair pulling when it took you ten minutes to write the original. Sometimes it's better to start clean but with the new perspective, coming at the problem from a different angle. (this is a lesson you're open source zealots seem to be forgetting these days - they never seem to throw ANY code away no matter how badly it's written)
Thank you for your very detailed and information post! You gave some very common sense approaches as well. I am going to come back to this one thread often.