Welcome to WebmasterWorld Guest from 184.108.40.206
Forum Moderators: not2easy
I work in a large govt IT department developing websites. We use CSS for basic stuff like font styling, but still heavily use tables for layout purposes, and is something we take for granted. We are now thinking of making the switch to CSS for page layouts, but the thought of it scares the heck out of me! It would be such a big shift in the way everyone here thinks (and develops). Nobody has much experience of CSS.
After a quick look around the web for advice, one of the first things to hit me was the whole 3-column div issue, with entire websites devoted to the subject - seeing these almost put me off CSS for life! Something like this is so trivial with a table! Another example: we develop a lot of data entry forms (which are essentially 2-column tables); again this is trivial with tables but I can't visualise how it can be done with CSS!
Layouts usually vary from one page to the next, and from one site to the next, so I can't see how practical it would be to create a standard company-wide CSS here without seriously restricting what the developers can do (but maybe that's how I should be tackling the issue: tightening up designs to a smaller, more manageable/standard set).
Just to clarify: we apply a standard "template" to all of our pages (header, footer, menu, etc) to provide a common corporate appearance. I'm not so concerned with this side of things, as the more advanced developers can spend the time getting this written using CSS, and once written is used again and again. While this takes care of the high-level page layout, there is obviously still a degree of layout required on the individual pages that all the other developers churn out day to day (which make use of the above corporate template).
As you can probably tell from the tone of my message, I'm a little worried about the amount of effort, training, etc., that would be involved in moving from tables to CSS layout. Many here are arguing why we should ditch a technique that we can all use without even thinking about it, to something that might mean a ten-fold increase in development time!
I'm sure many of you have gone through the same painful exercise and would be grateful for any tips, advice, resources, etc.
Thanks in advance
Strap yourself in. This is always an entertaining ride.
Here [webmasterworld.com] is an interesting conversation about this very subject, and there are links to other conversations about it as well.
Me, I avoid the Kool-Aid and go for practicality. There are reasons to avoid <table> elements, but none worth starting a crusade over.
Interesting questions which coming from a large dept based dev team should hopefully provoke some interesting answers!
I will try to KISS and hopefully help you not to be scared of CSS. Yes some of the CSS layout techniques out there can be daunting, but mostly the ones that are are cutting edge and are trying to deal with pixel perfection, every possible browser bug and gorgeous design at the same time.
one of the first things to hit me was the whole 3-column div issue
You asked for tips about moving away from tables
biggest tip has got be to be do it bit by bit
e.g. if we take a very rough guess that a standard layout table based on your description is
<table summary="layout" border="1" cellspacing="0" cellpadding="3" width="100%">
Then there is no need for the header and footer parts to be inside a table cell, so you could start by removing them to divs, they are after all logical page divisions
<div id="header" style="border: 2px solid #ccc; padding: 3px;">Header</div>
<table summary="layout" border="1" cellspacing="0" cellpadding="3" width="100%">
<div id="footer" style="border: 2px solid #ccc; padding: 3px;">Footer</div>
if that is all you ever do it's a start which gives you a chance to work with the easy bits :) as I presume these are bits of the page that every day developers would not be tweaking as they would be part of the "corporate template"? Working with CSS on just these bits will give you time to start building the stylesheet without fear of others tweaking and breaking the design.
Another example: we develop a lot of data entry forms (which are essentially 2-column tables);
Moving from tables to CSS does not mean you cannot have a table in the page the <table> element [w3.org] is still a valid, and useful element for its intended purpose of defining data :) IMHO, what there shouldn't be, on a page, are multiple nested tables because that's where the accessibility of the page can come into question. And if you start the entire page laid out in a table you start the nesting from the get go.
If you can, and I think this would be of high importance for a Govt Site, which has to conform to accessibility issues as well, you should get a copy of a screen reader and try to listen to some sites which are built using nested tables (this one for example) then you might realise why it's not just a whim for some entities to minimise their use of tables for layout binding
hopefully more good ideas and tips will follow from others
[edited by: SuzyUK at 12:12 pm (utc) on Jan. 30, 2007]
The only thing I would recommend is to get the CSS training videos from lynda.com, I tried them and I think they are a great resource for beginners
Where we found the biggest advantage to using CSS, besides fonts and colors was for navigation. Some of our earlier sites had text based navigation with DHTML menus. The original code used nested tables and our rendered page size was over 300K!
By using <ul> and <li> for the navigation we have slashed the rendered html size to well under 100K, not as good as I would like but a big improvement.
To get a handle on 3-column layouts learn how to "float" divs. It makes things so easy.
Google "css float tutorial". The first few results are great. Also check out the "Listutorial" on the first result.
We are slowly getting to the point where our "developers" can code the content and our "designers" edit the style independently.
Some of the developers are finally catching on to CSS. I plan to hold some training sessions (Just In Time Training) to show developers the basics of CSS.
biggest tip has got be to be do it bit by bit... what there shouldn't be, on a page, are multiple nested tables
These are key points in making the transition. You can move to one (or two) layout tables per page with most of the styling in CSS quite easily. This can avoid any nasty gotchas when you're pouring thousands of content pages into a template, while still delivering significant benefits (speed, accessibility, ease of maintenance) over old HTML3.2 style pages.
When you and your staff are up-to-speed you can then move to a fully div-based, CSS layout. A full CSS layout allows you to offer extra accessibility features like linearised/zoom layouts, and this is where you should be heading for public sector sites (IMHO).
You may also want to think about defining browser support levels - which browsers your pages are tested on, and the level of support for different browsers.
See Yahoo's Graded Browser Support [developer.yahoo.com] for an example:
Grading the browser ecosystem enables meaningful, targeted, and cost-effective QA testing.
I began by first eliminating nested tables. This, really, is a requirement of accessibility guidelines - so beat this one first.
During this process, begin using a valid document type. This directly has nothing to do with your transition, but using a valid document type will teach you a LOT about CSS, and it will also enable some widgets that are not available in quirks mode. That is, some CSS rules don't work correctly in quirks mode.
Then on the next revisit to the page, explore how you might get rid of the main layout table altogether - by this time you will have more of a grip on how divs work in layouts, and whether it's going to be more difficult to make it tableless than to stick with a bare-bones table framework. This is expecially true if your content varies greatly in size and demand, as in a company CMS.
In the end, you will find that tables are not ready to give up the ghost completely in some situations. Although purists will flame you endlessly for tabling a layout, sometimes you have your reasons. :-) It will still validate and is not the end of the world.
Before having someone taking care of our CSS needs. I wanted first to be sure that I had a sufficient CSS knowledge.
Best way to acquire a basic knowledge consists in starting with a simple “2cols” design and from there develop and develop, actually many CSS books apply that approach, start little and keep adding…
The decision is whether or not to use tables or block elements (usually <div> elements) in your basic page structure.
In a modern page either one has as little presentation as possible, and lets the CSS provide the presentation.
2) There are significant advantages to using block elements for layouts. They are far more flexible than tables, and they can be manipulated by CSS to a pretty amazing degree, which can be done to support older browsers. I do it all the time, and I need to support older browsers, so the myth that "new paradigm" Web design eschews older browsers is just that: a myth. You can also design pages with fairly significant SEO and accessibility advantages.
3) There are significant advantages to using tables as a layout tool. They can stretch to accommodate content that makes block elements cry like babies. They are one of the oldest and most well-supported constructs in the WWWide WWWorld of the WWWeb. If your layout requires a strict, yet content-accommodating layout that will be understood by even ancient browsers, then it's pretty hard to beat a <table>.
4) There are significant disadvantages to using a block element structure. Block elements react to context, not content, so you can easily have things like content overflowing the page layout. Badly done block element-based layout is a terrible thing to see. Kind of like a Picasso painting viewed while on some primo weed. It can also be a real bear to write the CSS involved. Because block element layout is so dependent upon CSS, the onus is on the CSS designer, and you'd damn well better have a good one on hand, because CSS design is non-trivial.
5) There are significant disadvantages to to using a table-based layout. Your page design is fixed, as to what generally goes where. In a block element-based design, you can decide to move the navbar to the right instead of the left, and your CSS designer can do it. Not so, with a table-based design. You need to have the structure coder move the navbar, and the CSS designer will still need to work on it anyway. Also, it is not so simple to make radical layout changes to accommodate different screen sizes (like going to a more vertically-oriented screen might be better served with the navbar on top, not the side). There are reams of materials that explain, in great detail, why a <table> is a tool of The Dark Side.
6) CSS design is NOT EASY. Anyone who tells you differently is selling something. Basic CSS (like basic XHTML, and even basic C++) is not a big deal, and the academic text will show you all kinds of neat tricks in 100 lines of code or less. However, scan through the archives of this very forum, and see how easy CSS is when applied in The Real World™. When you create a page that separates presentation from structure, you are probably going to find that things that used to be easy in "classic" page design are suddenly three times as hard (no exaggeration). This goes for both table-based and block element-based design.
7) Have you ever brought a computer, and the salesman was telling you how "future-proof" it is, and if you buy this one, you can replace the processor in two years, yadda-yadda... You buy the computer at twice the cost of the non-"future proof" one, and two years down the road, you find the memory bus architecture has changed, the backplane is different, you can't get a drive small enough, and the new processors have too many pins in them to fit in the processor slot. Not only that, the cooling array for the graphics card won't let you fit it in the slot that won't support the new cards. Pretty much the same thing happens with Web sites. You'll get sold on this great new design that can allow the entire site to be changed dramatically with CSS. Then, when it comes time for your upgrade, you find that you really want to make a number of structural changes, or that doing it by CSS only will give you a kludge that will take longer to make, longer to test and be less flexible or attractive than a simple structural change. I have NEVER upgraded a site of mine using CSS only. NEVER. Granted, having the CSS separate has helped, but even minor structural changes can mean you need to go right back to the beginning in the CSS design and start over from scratch. I'm doing it right now on one of my sites.
8) Whenever you make a significant change in your workflow, it will be painful. It may very well be for the best, but the first project or two you do in the new manner will very likely be garbage and make you wince when you review the code. If the site in question is critical, then I strongly suggest that you keep this in mind. You will need to develop new habits and priorities, as well as a new reference and knowledge base. Your productivity WILL go straight down the drain for a while as you come up to speed.
This is not a simple choice, and there are barrels of Kool-Aid out from both sides. PhD-laden pundits on both sides rail against each other, and poor mensch like Thee and Mee have to figure out what's best for ourselves. You should lay out a plan that takes the transition of your human assets (not just the code, but the larnin' up as well) into account. If you will suddenly be delegating the lion's share of your presentation to CSS, then you'd darn well better have a good CSS person in mind to do the work, because being a good HTML designer is NOT the same as being a good CSS designer.
How did I do it? Training course. A FREE Macromedia Training Course that was going about at that time where I had to sign up, and a live webcam Macromedia guy took us through loads of slides etc. Sign up with Macromedia and watch out for these. If you use Dreamweaver, make sure you're on version 8, as from what I've heard there are a lot of display discrepancies in earlier versions (on the WSYIWIG screen) for full DIV sites.
The main thing to understand before you dive head-on into CSS site building is this : THE BOX MODEL. Once you've got an understanding of that, and which different spaces on your page will be controlled by which elements - it makes it a hell of a lot easier. It was covered very well in the hour-long course I did.
The next thing is to master the FLOAT function, left and right. I use this on about 80% of my divs to get them to behave correctly and appear where I want them.
After that you can then start to tinker with the more advanced techniques - all things that you discover in time. We're talking conditional comments to load different stylesheets depending on browser, 3-col layouts with borders that stretch for content etc (this technique is actually fairly easy to master).
[edited by: SuzyUK at 3:29 pm (utc) on Jan. 31, 2007]
This can get me seriously down, as I then spend more hours checking layouts in different browsers at different screen resolutions - all of which seem to behave themselves. I agree that making the changeover from nested tables to css should be a slow process but if you have got time, then as mentioned previously, put up a basic style sheet with divs to replace header and footer tables, then start testing with columns.
I did try a three column setup a while ago, but reverted back to two as I couldn't get it right with the basic knowledge I had. Floating still gives me headaches as they never seem to want to float where I put them! I think I'll seek out that macromedia course too - it sounds just what I need.
All the same, today I use tables for a most basic page layout skeleton - nothing more. You need three columns that will always remain as long as its longest column, and you don't need "middle column content first for the SE's"? - use a table, it's easiest. If you <i>do</i> need the SE to see that middle content first, div's are better. It all depends on need.
I would suggest that you think out your page layout ahead of time, and think "horizontal lines" - the most difficult thing to align with independant div's - when considering your need for tables or not. Most pages have two horizontal lines that stretch from the extreme left of the page unbroken to the right: one between the header/content, and the second between the content/footer. Of course one could make three expanding full-page width div's and nest the content div's within... in short, tables are the simplest solution for the most basic layout elements that need to expand with content. Yet those willing to work more may opt for div's. It's a question of purpose against perseverence.