Last modified: 2013-07-10 00:07:55 UTC
Clearly much of this can also be solved by having unique id's and class names for each piece of each banner. I've tried to do this a lot more recently but having the ability to reuse large parts of code (and just change images, text, settings etc) can help to both keep the code more consistent as well as help make it easier to show other uses how to create banners so that we are not reliant on an extremely limited amount of people. I've planned on creating empty templates for the common banner setups (with documentation on what to change to set them up) and this would also make that much easier since I would not have to tell them to change the id's.
A slightly different but related example is the similar overlap of css/js when you are working on the central notice interface while other banners are running. Even when you have banners set not to display (for example though your personal css) the scripts load and will overwrite what you are working on if they share class names/id's.
There isn't any way to fix this other than removing the ability to have arbitrary CSS in banner code. Theoretically, I could create a complicated user interface for defining each css rule and it would always scope the selectors correctly, but as long as people can define their own css selectors, they can also define them poorly.
The only other solution would be to use iframes, but this would require us to define standard sizes for banners (which would also solve the page bumping problem).
Once it picks up browser support, using <style scoped> in the banners could be a solution for the css at least.
We now do previews in inline frames -- though that has it's own issues namely:
1) Sometimes they collapse too soon (especially for hiding banners)
2) It makes the pages slow to load
Still -- marking this as fixed.