Justin wrote:

[I moved the styles from "body" to "body#Dada" in the CSS ] Since the original site design doesn't have a body tag with the id of, "Dada" the margins/default font stuff doesn't get applied

This is exactly right and as far as the element is concerned anyway, the source order of your two stylesheets now makes no difference After all, there is now only one stylesheet (yours) with a rule that applies to the "id-less" body

That's sort of what I'm looking for and was the problem I was having and trying to solve, before

Well, it works in your case, which is good, and it's (arguably) a bit easier to understand and to adjust than it was before Plus, we've now ruled out the possibility that it affects the IE5/Mac positioning bug, so I say it's a keeper Nicely done!

Two details regarding this change, however

Firstly: As of the 2 10 beta 2 release, this change has removed the text styling from "iframed_archive_screen tmpl" (which is actually a "template", and not just a "screen") I believe this affects only wait for it! plain text messages being shown in an iframe on the archive pages (whew), and means that they will, in beta 2, use browser defaults for their text styling

I'll look into it this weekend The best solution over all is probably not to change anything in "iframed_archive_screen tmpl", but rather to add the desired text styling into #archived_message_body (which is waiting, lonely and abandoned, at the bottom of the stylesheet) instead

And secondly: this does not eliminate other possible duplications between Dada Mail's stylesheet and a second, site-specific one There are still many ways that Dada Mail's CSS could undesirably affect non-Dada-Mail content, and also many ways also that a second, non-Dada-Mail stylesheet could undesirably affect /Dada Mail's/ content In the long term, both issues are solvable

Because so few people at the moment choose to "embed" Dada Mail as http://www skazat com/cgi-bin/dada/mail cgi does, and because those that do are undoubtedly already aware of the potenital for stylesheet conflicts and, presumably, know how to resolve them, going any further in this respect before 2 10 0 stable isn't mission-critical But as Justin has mentioned in the recent beta 2 announcement, the CSS changes are a work in progress, and I'd be happy to look at further improvements down the road to make version 2 11 even more "embedding-friendly "