Page MenuHomePhabricator

Change CSS so tab spacing is 'before edit' instead of 'after talk'.
Open, LowPublicFeature

Description

Author: zach+bugs

Description:
patch to do what is described in the description

I am requesting a small change to the file skins/monobook/main.css. Please change the following:

Make a space between talk and edit tabs by adding a margin to the edit tab, not the talk tab.

Then, any custom tabs added between the talk and edit tabs will be grouped with talk.


Version: 1.12.x
Severity: trivial

attachment margin-main.css.diff ignored as obsolete

Details

Reference
bz11571

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:01 PM
bzimport set Reference to bz11571.
bzimport added a subscriber: Unknown Object (MLST).

zach+bugs wrote:

Updated patch

This also adds a margin to #ca-viewsource, which sometimes replaces #ca-edit in the event the visitor can't edit.

Attached:

This is a bad idea. Most extra tabs will be action tabs, rather than new pages, and so should be grouped with the edit/delete/move/etc. tabs.

If this is an issue specific to your own wiki, fix it by editing MediaWiki:Monobook.css.

If you think this is something that needs 'fixing' in MediaWiki, then this is not a good solution. A better solution would be to include separator items in the array of content-actions at the point where the space should be, so new actions can be added on whichever side is most appropriate. The monobook skin should use this entry to create the space (probably using in-line CSS) and other skins should ignore it.

There are two distinct groups of tabs: the article / talk set, and the action set. Each of the two groups may have an active/selected tab. It's all kind of funky. :)

Possibly there should be a grouping around each section, rather than trying to attach spacing to the individual tabs.

This could be fixed in 1.18 by using content_navigation instead of content actions (well perhaps with a helper to strip out tabs marked redundant), as long as we don't mind the extra markup (ie: It would no longer be one list, it would be separate lists like in Vector).

Do people really care now that we have vector?

(In reply to comment #4)

Do people really care now that we have vector?

If you mean 'would there be a massive public outcry if Monobook was removed altogether?', then the answer is clearly 'yes'.

If you mean 'should we still try and improve monobook?' then, by extension, the answer must still be 'yes'.

(In reply to comment #5)

(In reply to comment #4)

Do people really care now that we have vector?

If you mean 'should we still try and improve monobook?' then, by extension, the
answer must still be 'yes'.

Well we have to balance that out with the fact that fixing this will change the markup used in tabs on MonoBook. So just to fix a little margin bug we could potentially break plenty of site customizations of MonoBook related to the tabs.

sumanah wrote:

I'm adding the "reviewed" keyword since commenters have reviewed the patch author's approach. Thank you for the patch, Zachary. If you have time to revise and resubmit, please come into MediaWiki-General on freenode IRC and talk with us about how to fix this better! Thanks again.

TheDJ set Security to None.
TheDJ removed a subscriber: wikibugs-l-list.
Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 5 2022, 2:35 PM