MediaWiki talk:Common.js/Archive 20

Archive 15

←

Archive 18

Archive 19

Archive 20

Archive 21

Archive 22

Archive 23

Do not create NavFrame buttons if the new class "mw-collapsible" is used

Currently, the code which provides the Wikipedia:NavFrame functionality has a test like this

function createNavigationBarToggleButton(){
    // ...
    if (hasClass(NavFrame, "NavFrame")) {
        // Create the buttons...
    }
}

But this causes a conflict (example) if we try to moigrate to the (not so new) MediaWiki plugin which uses the class "mw-collapsible" (see previous discussion). Since it was not good idea to just copy the styles of NavFrames to the classes of this new plugin, I think a good way to help in the migration would be to improve the test above like this:

function createNavigationBarToggleButton(){
    // ...
    if (hasClass(NavFrame, "NavFrame") && !hasClass(NavFrame, "mw-collapsible")) {
        // Create the buttons...
    }
}

This way, we could still use the old classes for formatting and the new ones to make things "collapsible". The same idea would apply to the old "collapsible tables" system, where

if ( hasClass( Tables[i], "collapsible" ) ) {

would be replaced by

if ( hasClass( Tables[i], "collapsible" ) && !hasClass(NavFrame, "mw-collapsible") ) {

What do you think? Would that work? Helder 14:04, 5 March 2012 (UTC)

By the way, we could also replace the deprecated hasClass(NavFrame, "NavFrame") by $(NavFrame).hasClass( 'NavFrame' ) (since this is the last script in MediaWiki namespace using this function). Helder 14:14, 5 March 2012 (UTC)

Split MediaWiki:Common.js/edit.js into (default) gadgets

Wouldn't be better to move the individual parts of MediaWiki:Common.js/edit.js to gadgets enabled by default, and restrict it to users with the 'edit' right?

Besides, instead of checking for $.wikiEditor and $.wikiEditor.modules.dialogs, what about using the values of

mw.user.options.get('showtoolbar')
mw.user.options.get('usebetatoolbar')
mw.user.options.get('usebetatoolbar-cgd')

to determine which version of the RefToolbar to load? Helder 10:37, 21 January 2012 (UTC)

I wouldn't split everything into gadgets but mwCustomEditButtons has to go to a separate page because it's useless with default settings (!) and WP:RefToolbar 2.0 definitely has to be a default gadget. With MW 1.19 it doesn't work in IE8 and possibly causes problems for other edit buttons. — AlexSm 18:38, 1 March 2012 (UTC)

mwCustomEditButtons is protected by an if so it doesn't really matter. But I do agree about the default gadget. --Locos epraix 03:03, 5 March 2012 (UTC)

It does matter because it's 3+ KB of code. And it's actually not "protected" and the statement if(mwCustomEditButtons) doesn't make any sense: right now it's always true and the code always runs; if devs remove the object then this code will cause JS error. — AlexSm 04:13, 5 March 2012 (UTC)

Yup I didn't realize that var was always defined. It should be changed to something like if(!mw.user.options.get('usebetatoolbar')). --Locos epraix 23:09, 6 March 2012 (UTC)

I've asked the migration of the edittools into a (default) gadget on its talk page. Helder 20:37, 29 June 2012 (UTC)

MediaWiki:Common.js/edit.js: Opt-out

Hey all,

edit.js claims to have an opt-out method by "adding mwCustomEditButtons = []; to Special:Mypage/common.js". However this is in my opinion not a very wise nor reliable way to opt out.

For one, it will redefine the entire array. So any aliases to it are no longer correct and will be pointing to the old array. And if users have other scripts enabled that add buttons, those would be lost as well.

I'd recommend instead turning the button-part of the script into a Gadget and enable it by default (*[ResourceLoader|default]). Then users can simply opt-out but unchecking in the preferences. That makes it load faster (as it will not be loaded at all (instead of undone after the fact) for those opting out. And also more reliable and user friendly. Krinkle (talk) 00:55, 7 March 2012 (UTC)

Bug 32795 fixed

Tracked in Phabricator
Task T34795

The bug affecting line-height printable mode CSS rule, was recently fixed in Mediawiki 1.19. Please check if the following lines are still required. – Fuzzy – 19:57, 6 March 2012 (UTC)

    // In print IE (7?) does not like line-height
    mw.util.addCSS('@media print { sup, sub, p, .documentDescription { line-height: normal; } }');

Actually, only the margin issue was fixed, the line-height issue is still open i believe. —TheDJ (talk • contribs) 22:51, 6 March 2012 (UTC)

This bugfix enabled the top/bottom margin to be set in print mode (by removing the !important specifier). The line-height fix is a workaround for this issue. – Fuzzy – 09:18, 12 March 2012 (UTC)