wysi-not-wyg
No matter how carefully your templates are constructed, no matter how meticulous your css is planned, once a wysiwyg (what you see is what you get) editor enters the game you're pretty much fucked. With the rise of the CMS the wysiwyg editor tagged along and became a commodity in web-design, royally screwing up user-generated content on a website near you. There aren't too many good alternatives though, so we'll just have to try and live with it for the time being.
you don't get what you see
There is nothing particularly wrong with the concept of wysiwyg, in fact it helps clients to make the content they are entering into the system less abstract. They can see the impact of what they are writing in real-time which is a big advantage to them. The problem though is that concept and reality are often miles apart from each other, pretty much nullifying the advantages wysiwyg is supposed to bring them.
The best way to incorporate a wysiwyg editor is as an in-page editor. By giving the component a subtle yet recognizable look you'll be able to mimic the actual appearance of the content. Important is to make sure the width of the wysiwyg is equal to the actual content area and to transfer all the appropriate content styles (fe line-height, font size and color, ...). If the actual content area is just a few pixels wider than the wysiwyg editor it could already mess up some carefully constructed content. Mostly though wysiwyg editors are used for back-end editing. This makes it a lot harder to display the editor at the appropriate size with all the correct styles applied to the content, let alone imagine the content in its actual context.
All of that is just about what you can see on screen. What you get is actually a lot worse. The wysiwyg editors generate their own html in the background. In theory a good thing as it generates headings, paragraphs and list items (semantics!) but the reality is not as nice as they'll make it out to be. Especially when removing content the editors often leave behind empty tags and crappy html poo, sometimes even invalidating your html code. Depending on the css you've written, this could become problematic.
cuff your clients
Those in charge of sales love wysiwyg because of its many possibilities and features. Clients can change the font, color and styling of the text. They can insert images, lists and headings, they can even build their own content table. And best of all, it's not you who has to do all the hard work, the client can do so himself. Many forget that by working like this you're effectively turning the client into a web master, a job often not suitable for them.
The more possibilities you give a client, the more ways he will find to screw things up. You can talk hours about company styles and guidelines, but give them the option to mess around with fonts and colors and before you know your carefully constructed site is filled with bold, italic purple text in some or other exotic font. And that's only if you're lucky, Comic Sans is probably a more realistic example.
Leaving options like changing colors and fonts in is usually not a good idea. Most wysiwyg editors allow you to tweak its capabilities one by one but only rarely is an editor tweaked to leave just the necessary tools. It still doesn't guarantee that clients won't find other ways to mess things up (they are quite inventive when they need be), but at least it closes down some very obvious doors.
so what can we do
As much as you'd like to prevent the problem rather than curing it, you'll find yourself more than once confronted with issues originating from wysiwyg content. There isn't a whole lot you can do about them (apart from entering the back-end and manually editing the content yourself), but there are a few tricks you can learn.
mark wysiwyg content sections
Be it through the use of an extra class or by adding a structural element, just make sure that you can safely identify wysiwyg content. It will come in handy when applying specific css fixes and it can also be used to remove leftover or unwanted html elements with javascript (think font or center tags). Trust me, it's worth the trouble of adding the extra html element.
countering the br element
br {display:block; height:1px;} This can be a little dangerous, depending on the nature of your client. The br element is often used to create fake paragraphs, by applying the above style it will be much harder to do so while at the same time preserving the original function of the br, namely starting a new line without starting a new paragraph of text. Just make sure you don't end up with 24 consecutive br elements simply to create a 24px gap between the text.
It's a shame nothing similar exists to counter consecutive entities, but those are a part of the content itself. If you must though, I guess a little javascript could do the trick here.
removing empty elements
p:empty (,..) {display:none; visibility:hidden;} Another little trick is to use the :empty pseudo-class to hide empty elements from view. Any tags left by the wysiwyg editor will be completely hidden, making sure that none of the css on these elements will mess up your layout (padding is a notorious annoyance in this case). This won't work in older browsers but at least you're doing something for the others.
Alternatively you can use javascript again to filter out these elements as a fall-back for the less capable browsers. This could cause the layout to jump a little though (depending on the css which is applied) so I still prefer the css option as a standard.
be creative
And that's about all I've got so far. If you have any more tips or tricks, please do share. For a long time I've ignored the issues of wysiwyg content but I think it's about time to get rid of the most glaring issues. Other alternatives (like wyisywym - mean) are simply not as user-friendly or advanced as the current wysiwyg editors, so I'm sure we'll just have to deal with them for now.
With the pointers above though I'm sure you'll be able to counter the most common issues, or at least have a solid base to start countering them.