Page MenuHomePhabricator

remove subtitle divs from editing interface
Closed, ResolvedPublic

Description

The siteSub and contentSub divs serve no purpose on the editing pages and just add lots of extra space above the editing box. I've proposed overriding the CSS for them on the English Wikipedia, but the real solution would be to remove them at the code level.


Version: unspecified
Severity: enhancement

Details

Reference
bz27669

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:31 PM
bzimport set Reference to bz27669.
bzimport added a subscriber: Unknown Object (MLST).

I tried overriding the edit page CSS on MediaWiki:Common.js/edit.js:
mw.util.addCSS( '#siteSub, #contentSub { display:none; }' );

Unfortunately this causes the divs to disappear after they have been displayed, causing an annoying page jump, so I reverted the change.

Actually, leaving contentSub might be OK since it adds a little bit of padding between the header and WikiEditor, but having the site subtitle there doesn't make sense and is just a waste of screen real estate. The site subtitle is purely for the benefit of readers, and doesn't make sense in the context of the edit page. The header on the edit page isn't even a title, it's a description of what you're doing.

Created attachment 8260
Patch to show subtitle div only on article pages

Attached:

I've attached a patch which causes MediaWiki to only show the subtitle div on 'article' pages. MediaWiki's definition of an article also includes user pages, talk pages, main page, MediaWiki pages, etc. Basically everything except Special pages and edit pages.

Interestingly, it looks like most wikis don't even use the subtitle functionality, so this would mainly just affect the English Wikipedia.

(In reply to comment #1)

I tried overriding the edit page CSS on MediaWiki:Common.js/edit.js:
mw.util.addCSS( '#siteSub, #contentSub { display:none; }' );

Unfortunately this causes the divs to disappear after they have been displayed,
causing an annoying page jump, so I reverted the change.

CSS shouldn't be added with JavaScript, that will always make a delay. It should be done in CSS.

Although I get that edit pages cannot be identified (yet) from a CSS selector in-core, the best solution imho is to add a class to <html> at the top of MediaWiki:Common.js (not in a domready wrap):

if ( $.inArray(wgAction,['edit','submit']) != -1 ) { document.getElementsByTagName('html')[0].className += ' action-edit'; }

And in MediaWiki:Common.css:

.action-edit #siteSub, .action-edit #contentSub { display: none; }

That will make it slighty faster than adding a <style>-element to the <head> in a script that is loaded after later ( MediaWiki:Common.js/edit )

See also bug 4438, which requests to add this in-core with no dependancy on client-side scripting.

(In reply to comment #5)

Interestingly, it looks like most wikis don't even use the subtitle
functionality, so this would mainly just affect the English Wikipedia.

What about non-WMF wikis ?

As far as I know the site subtitle is hidden by default in MediaWiki.

@Krinkle: I think your suggestion matches my original intentions perfectly. However, after talking about the issue with Trevor, I've changed my thinking on it, and I think implementing the attached patch would be better. Specifically, I think we should leave contentSub as it is and remove siteSub on all non-article pages. The main idea behind the site subtitle is to provide a sort of site branding for articles (especially when mirrored, e.g. http://www.enotes.com/topic/Algebra), which isn't necessary on utility-type pages (and in most cases seems a bit silly). If someone is editing a page or using a Special Page, they probably know what Wikipedia is. I looked through some non-WMF wikis today to see how other sites use the feature, but I wasn't able to find any actually using it.

(In reply to comment #7)

As far as I know the site subtitle is hidden by default in MediaWiki.

Indeed. It's been display:none in Monobook atleast since 2004 and in Vector from the beginning.

@kaldari: Sounds good to me. Just wanted to make sure, but haven't found any uses of it myself on other wikis either.