Hi folks, I designed a pretty simple site (www.diamondintherough.ca) for my friend's business that looks just fine in IE 7 and Firefox, but it's all wrong in IE 6. I'm fairly new to web design so I've been taught to use web standards (or at least as close as I can get). I separated content from design like a good CSS disciple, but the support is terrible in IE 5 and 6 as many of you are painfully aware. I don't care about dinosaurs stuck on IE 5, but the IE 6 group is too big to ignore. Do I have to resort to going against everything I've been taught to believe and redesign the site using sinful tables, or are there some hacks I can use?
Whoa! Keep in mind this is the weekend. In spite of rumors saying otherwise, even web geeks (some, anyway), have a life away from the keyboard. You have a serious syntax error or three that could wreak all sorts of havoc, dependent on the browsers' guesswork of what you meant. It is a Good Thing® to validate your markup. cheers, gary
This layout is so simple I can't see where you'd even be hitting problems in the first place - unless you made the mistake of designing for IE7 first - in other words total /FAIL/ in philosophy. Not everything I'm going to list or say is the root of your problem, but I am going to point out a few 'good behaviors' that should probably have been used from the start. I don't rap, I don't jibe, I don't pussyfoot around what I see wrong and sugarcoat it mollycoddling nubes. Something is wrong in my eyes, I'm going to TELL YOU. There are some issues despite the relatively clean markup - UL can't go inside a P, that .intro section is a bunch of sentance fragments in prose, NOT a paragraph... I'd be concerned about the header representing text without HAVING text inside it (image replacement here we come), the title is too long to show up on most displays and does NOT help navigation, it has that STUPID MALFING clearfix rubbish when there's a perfectly good ID on it... and it looks kind of silly flush left. As to fixing it cross browser, the layout appears to be broken in all browsers except FF on my machine (Opera, Safari and IE7 through 5 hate it) - Opera and IE I assume is the layout breaking from my running 'large fonts' - as to what's messing up Safari - no clue, but it makes it a fairly good indication that your CSS is relying on Firefux's error correction and/or incorrect interpretation instead of valid layout techniques. WAIT, I stand corrected, there's a bug in FF too, the line after "It's your family and your memories" is being cut off in the sidebar by that image. (which shouldn't happen - that image LOOKS presentational) The best approach is going to be to rewrite - I'll rewrite your home page, documenting as I go to show how I'd approach it - because frankly your CSS is gibberish to me. Let's see... First, there's no reason for a new page (This is a new page, right?) to be tranny, so let's strict this bad boy. Chop the title down to the site name with the name of the current page (home) before it so people using tabbed browsers have something USEFUL in their tab titles. No need to abbreviate the title of the site for the CSS - how about instead we say what the CSS is FOR - aka it's media type... and let's not target all, there's no need to be wasting people's ink printing presentational images. I have NO idea why your header is outside the container on a fixed width layout, and in my book id="header" = /FAIL/ hard. if it's a header, shouldn't it be a heading tag? So move that and while we're at it axe that stupid malfing clearfix rubbish. On the topic of that header, let's put the text in there with some formatting to make it appear as close to the logo image as we can. Three lines so slap two BR inside it, the second line is bigger so mark that with a strong tag, and the smaller text below looks like it should be emphasized. We'll slap a empty span in there that will become our logo image to be placed over the text. <h1> DIAMOND IN THE ROUGH<br /> <strong>RENOVATIONS</strong><br /> <em>"MAKING YOUR HOME A GEM"</em> <span></span> </h1] Code (markup): This way search engines and people browsing with images off have something to look at, you have a common H1 binding all pages together, you aren't wasting a class on formatting it, etc, etc. Fixed width layout so we don't need to double wrap content (still not sure why you have both #copy and #content there) - though I WOULD wrap both columns though to apply faux-columns to it... (actually, I'd apply the faux columns to #container and that bottom-right background-image to the wrapper around the columns) On the footer - there's no need to double wrap the content like that - and ... oh, THAT's where you're assigning that background image... No wonder it's overlapping the content above it. If you're gonna negative position like that (or absolute or what have you) be sure you pad the bottom of the column properly. On to the CSS - well, first if you put each property on it's own line, you might be able to tell what properties are actually set in a clear coherent manner. You might want to consider declaring your line-heights since IE and Opera uses 1.2, Safari seems to use a bit more, and Firefox seems to use whatever the hell it feels like using today (anywhere from 1.1 to 1.3 depending on the ROUNDING ERROR). Also tahoma and verdana are from the same microsoft font pack - the likelyhood of a machine having one and not the other is next to nil, so skip verdana. Pad the body for that top and bottom 'border', slap the images in... Some coherent names on the images might help too... yes, we can all figure out bg is background - but for what? bg_image - A> we know it's an image, which is why you are calling it for a background and it ends in .png, B> it's an image for WHAT exactly? Hmm. This image appears to repeat on the X axis every 13px - so why waste the bytes on having it 85px wide? Chop Chop... It's also so low contrast there's no reason for it to be more than 16 colors, meaning .gif would be more efficient. I'm going to center this layout - so body gets text-align:center for IE 5.x, while #container gets margin:0 auto; It just looks silly flush left to me - but then I'm on a 1600 wide display. A BIG help would be to have your code in there in a SENSIBLE order... right now the order seems willy-nilly, it's usually best to put things in the order they first appear on the page. Of course, you went 800px wide - you do realize that 800px is not 800px friendly, right? (you need to account for browser borders and scrollbar) at which point you may want to have considered doing something with that extra 224px made available to you by targeting 1024x768 So that's #container, on to our h1 (your #header) - the image... is a oversize alpha transparent .png - for no good reason. It's still FREAKING HUGE as a 128 color palettized transparancy at 32k, but 32k beats the pants off 186k any day. Using palettized .png with 'close enough' aliasing eliminates the need for any hacks to work properly in IE. (and people wonder why I laugh at those bemoaning IE's lack of alpha .png - **** em, the filesizes are too big to even be CONSIDERED for a 'real' website) To get the image to 'hang outside' the h1, we'll set the span we are using to do so since it's absolute positioned anyways. So... on to the columns. We'll make a column wrapping DIV to apply that image - to line it up right we'll make that wrapper 10px narrower to clear the border, which should place the image just right every time AS THE BACKGROUND. THEN, we pad the content instead of the container preventing IE5 from screwing up. If we use padding instead of margins we don't have to worry about margin collapsing. Huh, ok - here's why it's breaking on my machine, you are using pt font sizes inside a px width area with px min-heights and so forth. If you are doing something pixel perfect (like a sidebar) use px fonts, otherwise it WILL BREAK on large font/120 dpi machines. To make the columns, this is simple - but I'm going to make BOTH narrower than the available space. This makes our padding for us, eliminates the need to worry about margin issues, AND removes and IE5 worries too. Side menu gets simple padding, font styling, turn off the bullets. We avoid putting styling on the LI to prevent IE7 from having a kiniption fit, instead styling the anchors directly. The 'intro' text is just a font size setting - meaning the only thing left to style is the footer. Since we just used one DIV, we set clear:both JUST IN CASE some browser decides to ignore our float wrapping. We do NOT set a height on this, but instead have our line-height and padding add up to the image height. We'll use px image size because we want it to line up with our background at default zoom on ALL machines. IE goes a bit wierd on the total height (even with height set) because of that image unless you set it to vertical-align:middle - which is ok, that's what we want anyways. We'll also nix the border just to be sure. ... and that's it... and here it is: http://battletech.hopto.org/for_others/Kestral/template.html as with all my examples. the directory: http://battletech.hopto.org/for_others/Kestral is unlocked so you can grab the gooey bits and pieces. Works just fine IE 5, 6 & 7, FF, Opera and Safari. Valid XHTML 1.0 Strict, Valid CSS 2. Seriously, this layout is so simple you don't even need any 'real' hacks. Some comparisons - Your original: HTML: 1,928 bytes CSS: 2,488 bytes Images: 251k My rewrite HTML: 2,245 bytes CSS: 2,161 bytes Images: 48k Mind you, my CSS is likely smaller because it's only for one page - but the HTML really didn't grow much either. The text for the header and more formatting being the two biggest culprits. Though, look at mine CSS off... CSS on with images off, etc, etc - and you'll see why I work the way I do. Hope this helps. Oh, and if the site name is "diamond in the rough"... does it make much sense to have a polished and cut stone in the logo? (these are the types of questions that kept me out of the really good schools)
Gulp! Yikes, I feel like I've just been torn a new one! Thanks for the tough love and very detailed response though! I truly appreciate the time you put into this for me! This sort of critique is the best way for a greenhorn like myself to learn, so I won't take the criticism too personally. The fact that I'm barely aware of a number of things you mentioned makes me very frustrated with how I paid a reputable distance education school a fair sum of money for what now appears to be a very limited knowledge in web design, *sigh*. You're right, this IS a pretty simple layout and design, but, boy did it piss me off! See, it's the first site I've done since I finished my program, so I really am functioning at an elementary level here. I don't think people outside the Web design community appreciate how complicated it is. I know I didn't! Especially since I work on this during my evenings and weekends outside my current career. As for my CSS being "gibberish", I had to chuckle when I read that because I've often wondered my mine looks nothing like the stuff I see on the "big guy" sites out there! How far off am I? Seriously, for an brand-spanking new designer, have I really choked that badly, or am I pretty much par for the course for a guy as green at it as I am? I ask because it feels like I'm so far from the mark that I shouldn't even have the site up! Of course, I am only so serious when I say that, because it WAS done for free, and is basically an 'Internet shingle' hung out there so customers have a site to look at. That said though, my confidence is certainly more than a little shaken if you can't tell! I will defend the logo choice a little though. I don't think anyone is going to look quite that deep into it. It isn't called "A ROUGH CUT Diamond in the Rough" after all , and I think it does look kind of nice on the wood! I have about as much experience in graphic design as I do in web design and I had no direction provided so I think I did OK there! ha! I'm going to pour over your rework of the site to somehow figure out how to get myself there. If you have any resources to suggest on how to get myself some proper training, I'd certainly be open to it! Thanks again for the feedback!
'scuse me as I respond out of order. Let me put it this way: Your site code as it sits now is on par with or ahead of what I was deploying 'professionally' three to four years ago, and is easily head and shoulders above the schlock you usually see from people who attended brick and mortar schools for this subject! - Which stands to reason since brick and mortar schools usually lag five years behind the business sector on EVERY subject, which in a industry that considers three years obsolete leaves the poor kids who put themselves decades into debt basically starting over from scratch the moment they are out the door with their meaningless piece of paper. Frankly, I'm flabberghasted you're a greenhorn given the code presented - kudos to you and the correspondance course. That said, the sad fact is a LOT of things, like cross browser bugs/errors are poorly documented (if at all) and one ends up having to rely heavily on your research skills (aka google-fu) to actually accomplish anything - and as with any other CONSTRUCTIVE art the only real way to learn is by doing - You wrote a page and deployed it, that's a REALLY strong start. Well, it appears you at least learned the basics, which is all ANY course is really going to 'teach' you - no matter how advanced the course. I consider that a GOOD THING. IF it pisses you off, that means you can develop the passion to BE a really good designer AND coder. The people who don't get pissed off at all the quirks and foibles of the various browsers are the people I think we need to weed out of the industry. You'll encounter that attitude a LOT, and the reason for it is simple. There are garbage programs that let anyone slap up a goofy personal page - Dreamweaver, Kompozer, Frontpage, etc, etc... Because people use webpages all the time and are aware of the various WYSIWYG programs, they assume it's easy and can be done in minutes - but the reality is comparing a professionally coded website to something slapped together in a wysiwyg is like comparing bathtub gin to aged congnac. Both will get you fershnickered yet one is far more enjoyable and unlikely to leave you blind. That comment was more meant as comic relief The only 'real' resources I suggest is the actual HTML, XHTML 1.0 and CSS specifications themselves - though I do use pages like the Web Design Groups HMTL 4 reference What I can provide you is some basic advice that will serve you well. Choose or create and then follow a style guide - This makes your code, regardless of programming language, markup language, etc, have consistant formatting. We don't all have to format the exact same way, but the formatting SHOULD make sense at the block level - in particular indenting the content of a block, and de-indenting the close. (some people put the close inline with the indented content - makes no sense to me - just be CONSISTANT). You can have a look over my own style guide here: http://battletech.hopto.org/html_tutorials/styleGuide.txt Property per line in CSS - A LOT of coders have been advocating condensing all CSS properties to single lines, and going nuts with throwing spaces between EVERYTHING. This just makes for a confusing jumble. If you keep it one property per line it's easier to move and copy properties between elements, clearer that you aren't double-declaring values, makes it easier to condense like properties, etc, etc. TEST IN EVERY MAJOR BROWSER AS YOU GO - This is where many new developers /FAIL/ - and is the cornerstone of quality page writing. Right now I test in Opera 9.27, IE7, IE6, IE5.5, Safari 3.1 windows, FF 2.0.0.14. Whenever I code a section like my header, I alt-tab, F5, alt-tab, F5, alt-tab, F5. Find something wrong, try fixing it, then alt-tab F5 ad nauseum to make sure your fix didn't mess up another browser. This of course means your BEST development OS is going to be XP, since it can run IE7 through 5.0 native (see the tredosoft standalones) as well as all the other browsers. If on Linux you can use Wine to 'kind of' test IE, but it sucks and I instead recommend getting something like VMWare to actually run XP. Likewise under OSX I highly recommend running XP under Parallels to actually test the real browsers or rebooting via bootcamp into a native XP install. Vista too is a miserable /FAIL/ because it cannot run anything prior to IE7 native - leaving you to try to use VMWare, M$VPC or Parallels to run XP to use older browsers. You will notice I'm NOT testing IE8 beta, FF3 beta or Opera 9.5 beta yet for the sake of designing pages - because doing so is in fact INCORRECT. BETA versions of browsers are there for finding things that are wrong with the browser, and instead of rewriting your page to work around it being wrong, you are supposed to REPORT that the Beta doesn't work right. If your code is valid, works in the current stable releases of IE7, Opera, Safari and FF just fine but not in one of the new beta's, you do NOT rewrite the page to work in the beta, you REPORT that the beta is WRONG. (otherwise the bugs in the beta will never get fixed). Changing your page to work in the new version of a browser really shouldn't be done until it hits release candidate when the features and functionality are supposed to be complete. Do not use IMG tags for presentational images - Doing so is just wasting code since presentational images are likely shared across pages, putting them in the CSS means their code is shared across pages saving bandwidth. It also means that you can change the page's appearance right down to the images without making a single change to the markup. Text-Image Replacement Techniques - if you are using an image instead of text (like in a header), do not rely on alt text. Search engines tend to ignore it (and all other attributes!), it usually looks like garbage with images off, screen readers will often mis-handle it... You can see an 'image replacement' technique in the H1 of my example. I positioned the span over the H1 text to hide it. PROPER use of header tags - This is often mentioned but not explained very well. Headings are used to mark the start of a section. If you lower the 'priority' of the header, you are indicating that the new section is a SUBSECTION of the one before it. If you are not starting a new subsection, you shouldn't be using a heading tag. You see people do this all the time with <h2>Article Title</h2><h3>Date</h3> - this is WRONG because the date and text following the date is not a subsection of the h2, it's the copy FOR the h2. Think of it like a tree, with the h1 being the trunk, the h2 being the branches, h3 being branches off those branches, etc, etc. In programmers jargon we refer to this via the parent-child-sibling relationship. MOST of the headings on a page are and should be SIBLINGS, while you generally should only have one 'trunk'. This is why on my pages, which usually don't have a heading saying "Home page" or "News Page" my H1 is used for the site title and logo, it's the only thing that is consistant across pages... a common trunk by which all pages are tied together. (Have a look at Dan Schulz' All you need to know about SEO thread for both sides of this particular method as well as a whole boatload of good design advice) Ask yourself 'is this needed?' - This one is the cornerstone of all of my code. I am constantly asking myself 'does this need a div around it?' or 'does this need a class?'... Too often people want to add a simple border or background to something, and slap a div with a class around it to do so when they could either just apply the class/id directly to what's being wrapped. You see this with people doing <div id="navigation"><ul> - SURE, if you are applying a border or background or padding AFTER having already applied such to the UL, THEN you need the extra DIV. MOST of the time, people seem to be slapping that on there for no good reason when the styling could just as easily be put directly on the list. You also see it when people have a series of anchors, paragraphs or other values inside a DIV that has a perfectly good id or class on it, and go and put a class on EVERY SINGLE TAG UNDER IT. There is NO REASON to EVER do: <ul id="mainMenu"> <li class="menuItem"><a href="#" class="menuLink">Home</a></li> <li class="menuItem"><a href="#" class="menuLink">Gallery</a></li> <li class="menuItem"><a href="#" class="menuLink">Links</a></li> <li class="menuItem"><a href="#" class="menuLink">Forums</a></li> <li class="menuItem"><a href="#" class="menuLink">Contact</a></li> </ul> Code (markup): THAT is a total and miserable /FAIL/ - yet you see people doing it all the time. NONE of those sub-classes are needed or even warranted. If they all had DIFFERENT styling, THEN you could put a class on them. If they are all the same, you have a perfectly good ID wrapping them, style the LI as "#mainMenu li" and the anchors as "#mainMenu a" and get rid of all that bloat in the markup. Flash in the pan technologies are usually a bad idea - See flash, there's a reason it's called flash and not substance. the fancier you try to get with things like animations, the more annoying the site is to use, the bigger a pain it is to maintain, the longer it will take to load, the more likely it is to break cross-browser, and to top it off, accessability is reduced to an all time low. IF you do feel the need to use a technology like Flash or Ajax for what normal pages can do without it, lands sake code in an accessable fallback. Both Flash and Ajax are GREAT for things HTML can't do - like video, games and applications. They have NO PLACE being used for normal page elements like banners, navigation, etc without a useable fallback. (especially if the same navigation WITHOUT the goofy animation can be done - flashtards do this all the time) No browser has it 100% right, but you can minimize the hacks - As a rule hacks are BAD, REALLY bad. OMFG someone put a bullet in my head bad. That said, they are a reality we all have to live with and come to our own peace with using if you still want to support IE6/5. That said, with the proper precautions 95% or so of all layouts CAN BE DONE without 'real' hacks and only a handful of 'workaround' hacks. So you're thinking, what's a 'real hack' and a 'workaround'? Haslayout is an EXCELLENT example of a workaround. Using a value that is safe to send to all browsers like width or height, or a browser specific value you can safely send and have ignored like zoom (even though it doesn't validate - CSS rules say unknown properties are IGNORED, so unless they change the rules), you can trip a behavior in IE that 'corrects' certain layout bugs so it behaves like every other browser. Really about 80% of bugs you'll encounter in terms of box model can be corrected with either haslayout, or another 'workaround' called the 'inline float'... The latter being setting display:inline on a float. Floats are inherently block and cannot be switched back to inline by the specification, yet setting display:inline in IE somehow changes the render behavior eliminating a box model bug called 'double margins'... which is in itself fairly self explanatory. In my mind these 'workarounds' being safe by the standard to send to all browsers makes them not be hacks, but more be akin to 'variable initialization'. Machine Language 101 - never assume the value of a register at the start of code execution. REAL hacks on the other hand, involve using things like IE conditional comments to render different stylesheets for different versions of browsers, or exploiting CSS bugs to make CSS that only effects certain browsers. I have a rabid dislike for IE conditionals because they go in the HTML that is sent on every page - AND usually means either inlining your different values in the HMTL or wasting an extra handshake with the server sending another file, AND means more than one CSS file to maintain. Given that the only time I usually need to send different CSS to just one browser, and that said code is rarely more than a hundred bytes I prefer using the "* html" selector hack since it will be cached across pages, is less code, and doesn't waste a handshake. NEITHER method is particularly 'valid' or even more correct than the other, use the one you are most comfortable with. (I just find '* html' easier since it can even go next to the code it's modifying). As a rule real hacks should be avoided at all costs - I suggest only resorting to them to implement 'missing functionality' in IE6/earlier - like adding a behavior file for focus/hover anywhere, using height instead of min-height, using expressions to fake min-width and max-width, etc, etc. IE box model - dodging the bullet - I know above I said avoid excess containing div's, but if you still care about IE5 it is sometimes your only choice because IE5 predates 'standards mode' and only works for the box model like the IE6 'quirks mode'. It isn't THAT hard to work around this though if you follow one simple rule - NEVER declare width at the same time as margin, padding or border. You follow this simple rule, and 99% of IE5.x layout issues can be avoided. Honestly, I usually don't bother thinking about this anymore but have found myself so in the habit of doing so, I keep doing it anyways. Doing this also means that you can mix % widths with having borders and have it come out right, making fluid layouts simpler and tossing in as a bonus doing less math. You don't have to say the width EVERY time - The default behavior of a DIV is to expand to fit the width of it's container minus margins, padding and borders. Because of this, don't state widths on everything, let the natural behavior do the work. Minimize the number of files needed - The more files you send, the slower the page will load due to 'handshaking'. Most browsers are set to be limited to 8 connections at a time. Every connection past that adds roughly 3 times your 'ping time' to the server to your page load time give or take depending on the filesizes. If you are under about 16 files you are probably ok... if you are using 60 odd files then on 'first load' before caching you could be seeing up to 100 seconds extra page load time for dialup users on a bad day, and almost 12 seconds for the average broadband user - and that has nothing to do with actual file SIZES. So HOW do you minimize filesizes? DON'T use conditional comments to combine multiple CSS files... DON'T use frameworks, and where possible combine presentational images down to single files. Have a look at this for an example of the last of those: http://battletech.hopto.org/html_tutorials/eightcorners/template.html That's dynamic width dynamic height styled image borders, using just ONE image. Learning about background, and more importantly background-position is one of the skills I consider to separate the pro from the wannabe. Alpha Transparancies - Why bother? - Many tutorials and designers these days are having a field day using alpha transparent .png files for layouts, ignoring the major shortcomings, the LEAST of which is trying to get them working in IE 6/earlier. Alpha transparent .png files a HUGE, often as large as animated flash files. While they do let you composite your elements client side, too often the filesizes end up so absurd that there's no way you should be using them in a deployment website. They often on things like corners require more markup or positioning tricks to use properly... When you take that into account, their not working in IE without the 'filter' property, which does jack for you if you want to use it as a background-image, makes them undeployable. The trick is to understand positioning, understand color space, and use palettized transparancies. The anti-aliasing over most backgrounds CAN be approximated by an average color, removing those dreaded jaggies... palettized .png or .gif tend to be anywhere from a third to a tenth the file size, and best of all, THEY ARE EASIER TO CREATE AND MANAGE. --- continued next post ---
... continued Frameworks are bad, templates are worse - This flies in the face of a LOT of developers instincts... Let me tell you after three DECADES of programming computers it's Blaise's own truth when it comes to INTERPRETED languages. For all the talk of markup not being a programming language, it is a sequentially parsed realtime interpretation of code. That SOUNDS like an interpreted language to me. Frameworks inherently have code you aren't going to call or aren't using - this means all that extra weight is just wasted bandwidth. We call this 'bloat'. You add in that they tend to dictate things like font sizes, often override the system metric (see that steaming pile known as YUI), and in general result in trying to shoehorn your desired layout into someone else's code. Templates are even worse on the shoehorn factor, especially since most of your free online templates have code that are outright embarrassing at best, a decade out of date at worst. A framework in a compiled language at least means the unused code isn't compiled (in any decent compiler) - in an interpreter, unused code is just dead weight that wastes load time, execution time, and file size. Help other people with their problems - Attempting to fix other people's layouts can be a learning experience for yourself because it is too easy to get comfortable designing pages 'your way'. Your layouts get stale, your habits become fixed... and a lot of times there are layout concepts you'd never even think of trying. Attempting to recode someone else's design yourself - WITHOUT even using their existing code can be a huge learning experience. It's why to keep my skills sharp between jobs I will often do recodes of other people's stuff (like above). Tables are NOT evil or a hack - No matter who says it is. Tables are an orderly division of data into rows and/or columns (american heritage dictionary)... What is a website but an orderly division of data into rows and columns? 90% of the anti-table mafia's rants against tables for layout hold water like a steel sieve, and you can blame their fanatacism on exactly that - fanatacism. There are some things div/css layouts flat out cannot do like cross browser 100% height without hacks, column backgrounds where faux-columns "won't cut it", vertical positioning of dynamic content or inside a dynamic height area, etc, etc. They are RARELY ever more code usually being a wash IF YOU USE CSS TO STYLE THEM. Where tables become a problem is the same problem you see with DIV's - people nesting them 20 deep for a single element when only ONE is 'needed' for the whole page. If you take the time to look at the arguements against tables: DIV's are less code - Uhm, no. Using CSS makes less code, so use CSS on tables. DIV's load faster - if the amount of code is the same or MORE, no, it's not loading faster. DIV's render faster - Uhm... If you use table-layout:fixed tables will start rendering as soon as they get width data and content, so... Nope, /FAIL/ DIV's are simpler - Yeah, negative margin techniques, positioning voodoo and faux columns makes it SO much simpler to deal with than using a tags DEFAULT BEHAVIOR Tables don't work cross browser - Since ****ING WHEN? Sure if you start screwing with margins and paddings without having a clue how to use them in a table you'll hit problems, but the same can be said of floating DIV's. Tables can't do content first for SEO - Yes, yes they can. <TR> empty TD, content TD rowspan=2, right column rowspan=2,</tr><tr> left column TD</tr>. The only arguement I hear that make ANY sense are the notion that you can change column orders without modifying your HTML. What really gets me is the balls a lot of these jokers have calling tables a hack, then throwing a few k of REAL CSS hacks, or conditional comments with entire separate stylesheets at a layout just to not use a table. I'm not saying 'only use tables' - The objective should be to use the best tool for the job - when the solution is a hammer you don't take off your shoe and pretend your name is Nikita. The best tool is the simplest solution that uses the least code to do what you want done... and a LOT of times the answer is DIV's and floats, and a lot of times the answer is in fact a table. Throwing out a perfectly good tool that has been the driving force of web design since it's introduction just because a handful of jackasses suddenly seem to be pushing for some form of social agenda... well... Seriously, when they can do this cross browser back to IE5 without hacks, THEN I'll listen to the anti-table rubbish. http://battletech.hopto.org/html_tutorials/3coltable.html 100% min-height, fluid width, real full height columns (and using border to fake the appearance is a /FAIL/), and not a single hack in sight unless you count tables as a hack... I guarantee you'd be hard pressed to pull that off in less code without a table, in fact I can guarantee it WILL be more code without it - which is when it becomes a STFU situation for the anti-table nutjobs. What we should be against is presentational markup with wasted containers, classes and ID's, NOT a tag that does exactly what we want 100% of the time. ------------------------- Resources - There aren't a lot of GOOD websites out there on working with layouts themselves, but a couple pages DO stand out. Layout Gala http://blog.html.it/layoutgala/ All of the layouts presented there use the EXACT SAME HTML. This is one of the BEST resources for showing what is possible, though the code is starting to show it's age and does have the issue that it is in fact HTML for ALL of the layouts, meaning for many of those layouts there is a bit of extra weight around the midsection. Colors on the Web http://www.colorsontheweb.com/ Starts you down the road of understanding colorspace, which is one of the more important (and oft neglected) aspects of site design. They explain a lot of the terminology, but don't get into much application or math. I personally use the emissive luminance formula from the EGA/VGA/MCGA/8514 specifications with a 75% rule. (Luminance=0.3*R+0.59*G+0.11*B) If the luminance of a background is less than 75% away from the luminance of Just be careful on colors - a LOT of the learning 'designers' get only applies to reflective light and color (aka print), not emissive (LCD/CRT) so a LOT of what's in the 'expert' sources is flawed. Colorsontheweb seems to be one of the few that does not make this mistake. (though it is somewhat 'sparse' on content) WebDevOut's CSS Hacks page http://www.webdevout.net/css-hacks While they favor conditional comments, the page does an excellent job of documenting the more common CSS hacks and their use. Six Ways to Write More Comprehensable Code http://www.ibm.com/developerworks/linux/library/l-clear-code/ While this is a general programming page, a LOT of what it talks about can be applied to HTML/CSS, particularly the bits and pieces about COMMENTING. Too often you see nonsensical or wasteful comments. <!-- start content--><div id="content"> - NO SHIT SHERLOCK. If one takes the time to use meaningful ID and classnames with semantic tags, you usually don't need comments on them. Another example is akin to one in the article: </div><!-- end content --> - end huh? I didn't know that's what </div> means, really I didn't. In HTML this has a second 'issue' that you may have noticed mentioned in my style guide - putting a comment after the close of a DIV can trip two different rendering bugs between floats in IE - double rendering, which is where the content of the div is for some reason rendered in a second spot on the screen for no fathomable reason, and 'dissapearing content' where whole sections of content can up and dissapear. The 'fix'? Put the comment BEFORE the close. <!-- #content --></div> Whatever:hover http://www.xs4all.nl/~peterned/csshover.html This brilliant little gem is a javascript that can be loaded as a 'behavior file' in your CSS JUST for IE6/earlier to implement :hover and :focus on all elements, not just anchors. (even though the website itself sucks donkey on SO many levels) This means you only have to write things like cascading menus ONCE for standard compliance, and have them work in IE. YES, they still won't work if scripting is off, but it beats the tar out of the steaming pile of suckerfish throwing extra classes at the problem, or WORSE the stupid malfing 'conditional table' rubbish which turns a 500 byte menu list into 5-10k of HTML. ------------------------- You might find it helpful to back-read some of my other responses where I did similar rewrites of people's sites. Many of them are much better documented than the one I did of yours. full on recode with line-by-line docs http://forums.digitalpoint.com/showpost.php?p=6848762&postcount=10 Border styling using sliding doors http://forums.digitalpoint.com/showpost.php?p=6909493&postcount=6 Ah heck, just have a look through my for_others directory, you'll see all sorts of recodes I've done for people in there, many of which use techniques that with the knowledge you already have, you might be able to reverse engineeer. http://battletech.hopto.org/for_others Likewise, have a look in my tutorials directory which SOMETIME this century will end up on cutcodedown.com (which is looking to be pushed back to may or june between doctors visits and illness sapping all my work time - I'm on the laptop in bed and find it very hard to get work done away from my workstation) http://battletech.hopto.org/html_tutorials Finally, the MOST IMPORTANT skill a designer can have is the ability to ASK A QUESTION instead of blindly plowing forward. It is VERY unlikely that ANYTHING you do in web design hasn't already been tried mulitple different ways by someone, and if it hasn't been tried before many people are more than willing to take up the challenge giving you multiple answers. Besides, as I keep telling people - the day you think there's nothing new to learn, is the day the world leaves you behind.
This one's huge, though I'd add to it watching other people rewrite others' sites (as above). This forum was where I first saw image replacement techniques (yes it's on the web but if you haven't heard of it you don't go looking), 100% height models, and ways around various browser bugs. I've run into some bugs on other people's pages that, after I figured out what was going on, ended up running into it on a work project. Taking an image or a layout (looking at how someone wants their site to look) and CSSing that really helps you get a brain around CSS positioning, which can be pretty strange at times. Lastly, looking into the crystal ball, we can see that you will redo this site, make a few others, and go back to them a few months later and see all sorts of things you could've done differently, better, or leaner. This is difficult when you're working because a finished product tries to become the never-ending project because you can always make something better. I've got one site from our company uploaded and online where I can't touch it, and I wish I'd done this and that to it...
Absolutely - a good coder is one who keeps learning. I wouldn't give a hoot in hell for a coder that didn't get disgusted with their own code of just a year past. Which is where prioritizing comes into play. You have to ask "Does it work as is in all modern browsers?" and "Did I do the best to my knowledge THEN?" - if the answer is yes, you might be best off leaving it be despite the GLARING PROBLEMS you may see in it once your knowledge expands. Like everything else in web design, it's a balancing act.