Agreed, except for the two declarations that Ralph mentioned, all of your other declarations should be inherited from the table automatically. As long as you keep the style rules for the table and the th / td elements in close proximity (and it’s a good idea anyway) this is a more robust way to program it and will still be semantically clear how everything is styled.
As for the cross-browser incompatibility, I have only one procedure for that. Validate the page and correct any errors; that corrects virtually all incompatibility issues. If the compatibility issue remains, start commenting out style rules or sections of the stylesheet until the display is the same in all browsers. Then start boring down into the problem section until you can tell exactly which declaration or combination of declarations is the problem. It sounds like this is a problem with the table display so more than likely - though in CSS its not always that easy - a problem in the table section, so I’d start there.
That’s really common. I can offer a couple tips that work very well for me, though they don’t work for everyone; it depends on your style.
I design in stages. My first page design is just building the XHTML; you don’t have to have the content, but you do have to have the framework (ie there’s a news section with links to news articles, there’s a navbar, there’s a main content section, there’s a secondary content section, there’s a testimonials section, etc. It can be just Lorem Ipsum, but you want all the tags in place.) Wireframes and XHTML prototyping work very effectively with this technique. My second just works on the positioning in CSS-P, no floats, no styling, nothing else. Then I paint everything in colors. Then I give the design some texture and apply some first blush placeholder images. Then typography. And last finalizing the images.
I copy all the files (the webpage and CSS files) and rename them at the end of each stage so that each stage is preserved. This allows you delete any file in the current stage if it becomes unsalvageable and start over by copying the version from the previous stage. It also gives you “save points” where you can easily go back to an earlier point in the design and start from there rather than starting from scratch. (I build all my Photoshop files in layers to give me the same flexibility; as long as they’re willing to pay for the extra work, I’m happy to let a client change their mind, but I still don’t want to redo any more work than I have to. It’s a waste of my time and their money.)
Once I’m done with that process, I then build the production files from scratch, because your final files from the design process are an “overgrown bush”… ALWAYS. I’ll copy over bits and pieces from my final design testing which I know I need, but it’s always amazing how much crap was in there from testing. There’ve actually been cases where I had to go through this step a second time, because there was so much garbage to weed out.
Doing these things have helped to give me the freedom to experiment in the design without being afraid that I’m going to waste a lot of time. It also allows me to build a completely “overgrown bush” and I don’t have to care. It’s never going to see the light of production. It’s just testing. (and I’m religious about using that verbiage with clients, “Here’s your completed test site. If you like it I can have the production site up and running in X days.”
- a problem in the table section, so I’d start there.