Last modified: 2013-07-10 00:07:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 26646 - "sandbox" banners being displayed in Special:CentralNotice campaigns and Special:NoticeTemplate because of overlapping css and js when multiple banners displayed.
"sandbox" banners being displayed in Special:CentralNotice campaigns and Spec...
Product: MediaWiki extensions
Classification: Unclassified
CentralNotice (Other open bugs)
All All
: Normal minor (vote)
: ---
Assigned To: Adam Wight
: fundraising
Depends on:
  Show dependency treegraph
Reported: 2011-01-10 00:08 UTC by James Alexander
Modified: 2013-07-10 00:07 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description James Alexander 2011-01-10 00:08:59 UTC
Currently banners frequently do not look or act how they are supposed too (and set up too) when displayed alongside other banners (generally in CentralNotice campaigns or on Special:NoticeTemplate) This is because the style sheets of each banner overlap with each other. When pieces of the banners share the same class or id name (for example when one was copied to start the othe) they can override each others settings making the only real way to view hem by looking directly 1 banner at a time (go to the edit banner page) or by using the ?banner= force code on a wiki. The biggest examples of this is when links won't go to the right spot (because the JavaScript from one banner is writing a link on other banners) and banners not showing the right picture or text positioning.

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.
Comment 1 Ryan Kaldari 2011-03-15 18:06:57 UTC
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).
Comment 2 the wub 2012-11-15 01:01:05 UTC
Once it picks up browser support, using <style scoped> in the banners could be a solution for the css at least.
Comment 3 Matt Walker 2013-07-10 00:07:55 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.