Protect enclosing HTML from Trac CSS rules

[andy@…]

At the moment it's hard to embed Trac naturally in a parent website, because Trac's CSS rules aren't restricted to only apply to Trac-specific page elements, and they use very generic id attributes such as "header", which easily clash with similar elements in the parent page wrapper.

It would be an improvement if Trac's header.cs and footer.cs were used to enclose all Trac page elements in e.g. <div id="trac">...</div> and then all Trac CSS rules could be prefixed with #trac . (It would save me from having to do this by hand every time a new version comes out!)

[Emmanuel Blot]

I think you can easily do that (<div id="trac">) if you define your own site_header.cs and site_footer.cs template files - see TracInterfaceCustomization#SiteHeaderFooter

I'm not sure it is worth overloading the default CSS files with an extra cascading level, a simple sed or awk script can do the work.

Leaving the ticket opens though, as some other people might prefer the opposite way.

[andy@…]

Adding the extra div is very easy, yes, either in the main templates or via site headers. I run a system with a lot of auto-generated Trac environments, so I put it in the main header template.

The CSS is much more complex, though. IMO, the simple script isn't actually all that simple: you have to be aware of when the start of a line is in the body of a CSS definition, which eliminates sed from the running. And then there are lots of cases where multiple CSS selectors apply to one style rule via a comma-separated selectors list: just replacing "," with ", #trac", would almost work, but there are collisions like font definitions, which also include commas. Or maybe I'm just being dumb: I just can't see a nice way to do simple search and replace and still get valid CSS on the other side.

I'm not sure that adding another layer of CSS has any detrimental effect (e.g. on browser rendering speed), and it's certainly necessary if you're going to use a custom header and you want to avoid collisions with the Trac styles. (While I'm here, I'll just mention that generic id names like #header can also cause problems for external headers! #trac-header would be a lot more robust.)

If it's felt that this would be a good thing, I'm happy to help: I have to do this anyway, so it would be no problem to feed the changes back upstream.

[andy@…]

I've had some user complaints about our system using Trac, because when they go from a static page to a Trac page of their Web area, some div spacings and the like change, which gives a slightly inconsistent UI experience. This is a consequence of the unprotected Trac CSS affecting non-Trac page elements.

This is easily fixed, but I'm reluctant to change the CSS and templates, since that will just need to be re-done next time we update Trac. If I were to supply my "protected" versions of the templates and CSS upstream, would they be accepted? I don't think adding one more layer of nesting is a high price to pay for the increased robustness and embed-ability that results… what's the "official" Trac opinion?

[Emmanuel Blot]

This issue could be addressed with #5997, as the same issue is reported with the new templating system.