Page MenuHomePhabricator

White space at the top of the article
Closed, ResolvedPublic

Description

Author: triatrea

Description:
There is a padding at the top of the article, right above the <h1> tag. It is caused by <code>padding-top: 0.9em;</code> in <code>#siteNotice</code>. This bug was fixed in Monobook a while ago.

See [[19219]] for more information.


Version: 1.16.x
Severity: normal

Details

Reference
bz19567

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:40 PM
bzimport set Reference to bz19567.

triatrea wrote:

A picture of the white space at the top of the article

Attached:

Padding-top_bug.png (191×270 px, 16 KB)

matthew.britton wrote:

In short, "0 .9em" was mis-corrected to "0.9em", when the intention was "0 0.9em"

Didn't check the other skins at the time because the change was to Monobook, but of course Vector has copied some stuff from there.

This is working well now afai can test.

In vector this margin was recently changed from a margin-top to a margin-bottom. But sitenotice is not in sync with monobook at the moment.

(In reply to comment #3)

This is working well now afai can test.

For reference, this was done in r52855.

Still broken, as can be seen on:

http://test.wikipedia.org/w/index.php?title=Main_Page&useskin=vector
after you hide the board notice.

The css adds a maring to the siteNotice div, but this div is almost ALWAYS present on foundation websites due to the perpetual deployment of the centralnotice javascript loader. Even though in many cases this loader produces no content, or hidden content, the loader itself is considered to be content for the siteNotice and THUS the siteNotice introduces an extra margin even though there is no user visible content to be presented.

Basically, this is why the centralNotice implementation sucks :D

Solved, I believe properly, in r53629.

The problem still exists. Now the problem shows when there is a sitenotice, but you have chosen "hide".
Safari 4.

I have "#siteNotice div.expanded table.siteNoticeUser { margin-bottom: 1em; }" deployed on en.wp to "fix" this, but to be honest, i'm not quite sure how it acts when there are local sitenotices active, and how it works for anonymous users...

This issue is still present on all Wikimedia sites (except english wikipedia) that now run the scholarship centralnotice.

For any other Wikis that are now seeing this problem, English wikipedia and Dutch Wikipedia have the following CSS in MediaWiki:Vector.css to correct this problem:

/* Temporary fix until [[bugzilla:19567]] is addressed */
#siteNotice div { margin: 0; }
#siteNotice div.expanded table.siteNoticeUser { margin-bottom: 1em; }

The essential problem here is that there is no consistent way of determining if any content is actually being shown by the centralNotice or not. toggleNotice() switches the centralNotice div to have a class of either "expanded" or "collapsed", but collapsed can mean "hidden completely" or "collapsed to a smaller size notice" depending on how things are defined in the banner/template itself. In one case, we want a margin-bottom; in the other case, we don't. Is the best solution to always leave the margin-setting to the banner/template builder and remove it from the skin and extension css (as has been done with the local hack above)? The down side of this is that it means that you can't just create a simple centralNotice banner with no custom CSS and expect it to look right on the site. Is there a better solution?

This should be fixed now. We now set margins for CentralNotice to 0 by default, and the margin is set on the actual banner div within each centralNotice (the same div that gets set to display:none when you click hide).