Wikipedia

MediaWiki talk:Common.js/Archive 11

< MediaWiki talk:Common.js
This is an old revision of this page, as edited by Shadowbot3 (talk | contribs) at 00:03, 19 November 2007 (Automated archival of 1 sections from MediaWiki talk:Common.js). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Latest comment: 17 years ago by Alex Smotrov in topic Azatoth's edit (import sysop.js)
Learn more about this page

Printable version messed up

Latest comment: 17 years ago7 comments4 people in discussion

The printable versions of pages are messed up for anonymous users. —Ruud 19:25, 30 September 2007 (UTC)Reply

Can you be any more specific? What browser are you using? —Remember the dot (talk) 02:45, 1 October 2007 (UTC)Reply
Something about donating money and 10 thing I'm not supposed to know about Wikipedia. 83.83.37.71 03:19, 1 October 2007 (UTC)Reply
What browser are you using? —Remember the dot (talk) 04:09, 1 October 2007 (UTC)Reply
FF 2.0.0.6 —Ruud 13:47, 1 October 2007 (UTC)Reply
Are you saying that you don't want those messages to print? —Remember the dot (talk) 16:12, 1 October 2007 (UTC)Reply
They probably shouldn't thow up on the print version. They aren't useful on paper, and the footer should cover the donation notice stuff. --Gmaxwell 17:45, 1 October 2007 (UTC)Reply

Problem with importStylesheet in IE?

Latest comment: 17 years ago5 comments3 people in discussion

Is anyone else having an problem with importStylesheet in Internet Explorer? I am using Internet Explorer 6, and it's giving me a JS error. The error information I get from IE is the following:

  • Line: 58
  • Char: 6
  • Error: Unexpected call to method or property access.
  • Code: 0
  • URL: (Whatever the address in your browser is)

To recreate the error, open IE and edit your skin css file javascript file (fixed by Alex Smotrov). At the bottom of the file put the line importStylesheet( "User:Shardsofmetal/monobook.css" );, then preview the page. When it loads the next page, see if there is an exclaimation icon on the left side of the status bar. If so, double-click it. I had 2 errors, but I know the one related to this is the one I posted. My guess is also that the line number might differ depending on what other javascript has been loaded. I normally use Firefox, I actually only used IE to test this function at my local wiki, to load a custom skin for IE users (since the normal custom skin doesn't look good in IE). However, if I can't get the css file to load, then it was a waste of my time. I don't know javascript, only the basics I've figured out from looking at code, so I can't figure out what the problem is, but I assume that someone who knows javascript can fix the problem. Also, shouldn't the line + '&action=raw&ctype=text/css";' contain a semicolon at the end, to end the declaration of the variable? Anyway, I hope someone can take a look at this.  Shardsofmetal  03:04, 3 October 2007 (UTC)Reply

You need to specify a fully qualified URL, not a wikilink as you are trying to do. Try this instead:
importStylesheet("http://en.wikipedia.org/w/index.php?title=User:Shardsofmetal/monobook.css&action=raw&ctype=text/css");
— Edokter • Talk • 11:54, 3 October 2007 (UTC)Reply
No you don't. The function begins:
 function importStylesheet( page ) {
     var sheet = '@import "'
               + wgScriptPath
               + '/index.php?title='
               + encodeURIComponent( page.replace( / /g, '_' ) )
               + '&action=raw&ctype=text/css";'
Therefore, it requests the url /w/index.php?title=THE_PAGE_YOU_REQUESTED&action=raw&ctype=text/css. The function works fine in Firefox, and it looks fine to me, so I don't know why it doesn't work in IE.  Shardsofmetal  12:55, 3 October 2007 (UTC)Reply
Right, I missed that. Anyway, I tried the test above, and I didn't get the error. — Edokter • Talk • 13:31, 3 October 2007 (UTC)Reply

Yes, it's a known problem, importStylesheet doesn't work in IE. When I looked into it some time ago, looks like in IE you're not supposed to add a text node as a child of a style element but instead use styleElem.styleSheet.cssText. But even after that it seems IE (at least IE6) simply doesn't like @import in the added text. On the other hand, something like this below seems to work in IE6/Firefox 1.5/Opera 9 ∴ Alex Smotrov 19:20, 3 October 2007 (UTC)Reply 

function importStylesheet(page) {
 var styleEl = document.createElement('link')
 styleEl.type = 'text/css'
 styleEl.rel = 'stylesheet'
 styleEl.href = wgScript + '?title=' 
  + encodeURIComponent(page.replace(/ /g, '_')) + '&action=raw&ctype=text/css'
 document.getElementsByTagName('head')[0].appendChild(styleEl)
}

PNG transparency fix "V1.1"

Latest comment: 17 years ago3 comments2 people in discussion

I have updated the PngFix script. While neither Remember the dot and I could make the "fast" code to work, (see here we did come up with a way to increase the speed by not turning images without border to spans. Further improvements are:

  1. The script no longer depends on the .thumbborder (or any other) class.
  2. Support all PNG images, including imagemaps.

I'll post a message on the Village Pump to be on the lookup for bugs. Please report any problems there. — Edokter • Talk • 09:03, 5 October 2007 (UTC)Reply

Well, that's not entirely true. Only the CSS border information is copied out of the .thumbborder class, so if .thumbborder is limited to img elements in your skin and there is any other CSS in there, that CSS is discarded. This is what happens in the default skin, only there isn't any other CSS in ther at present. —Remember the dot (talk) 16:59, 5 October 2007 (UTC)Reply
What I meant was is that the code no longer has to rely on seperately decraled classes like .thumbborder. If need be, other CSS properties can be added to the code. But I don't expect we'll ever need to (maaaybe margin). Images hardly have any other properties then border anyway, but anyone is welcome to prove me wrong... — Edokter • Talk • 19:59, 5 October 2007 (UTC)Reply

IPA style for IE

Latest comment: 17 years ago5 comments3 people in discussion

{{editprotected}}

The current IPA hack doesn't work in IE 7 (see Template talk:IPA#Solution for IE6/7 problem for details). The following code will load the required CSS rule form script and thus avoid ugly CSS hacks: 

if(navigator.userAgent.indexOf("MSIE") != -1 && document.createStyleSheet) {
   document.createStyleSheet().addRule('.IPA', 'font-family: "Doulos SIL", "Charis SIL", Gentium, "DejaVu Sans", Code2000, "TITUS Cyberbit Basic", "Arial Unicode MS", "Lucida Sans Unicode", "Chrysanthi Unicode";');
}

This also makes the .IPA style in Common.css unneccessary, after it has worked it's way through the cache. (Excpet for IE users with and javascript turned off, but they will have so many troubles they won't even notice the IPA scripts not working :-) --Tgr 21:24, 4 October 2007 (UTC)Reply

Are you sure this cannot be done in common.css using condtional (#.IPA) declarations? — Edokter • Talk • 10:14, 6 October 2007 (UTC)Reply
You mean, some sort of CSS hack? That's the way it has been until now (with the star html hack), but most hacks don't work with IE7. The only one I know to work (lang attribute hack) is semantically incorrect, and the others didn't like that. I have thought of conditional comments, too, but most skins don't have those. --Tgr 16:40, 6 October 2007 (UTC)Reply
'#' isn't really a 'hack'; as far as I know, # makes CSS rules IE6(7?) only. Don't know if IE7 has it's own conditional character. Forget my comment, I'm still not versed enough in CSS to know what I'm talking about. — Edokter • Talk • 17:39, 6 October 2007 (UTC)Reply
  Done. Cheers. --MZMcBride 19:17, 9 October 2007 (UTC)Reply

Function to invert checkboxes

Latest comment: 17 years ago10 comments6 people in discussion

Latest addition. Come on ...

  1. Consensus?
  2. Shift-clicking (see MediaWiki:Watchlistedit-normal-explain) is not good enough?
  3. MediaWiki:Sysop.js ?

∴ Alex Smotrov 21:18, 12 October 2007 (UTC)Reply

This is better than shift-clicking as it makes restoring all but a couple revisions easier, as for MediaWiki:Sysop.js, I personally was unaware of it. Consensus? This does not really require community consensus as it only affects administrators. GDonato (talk) 21:23, 12 October 2007 (UTC)Reply
The size of the file affects everybody. The unnecessary changes to the file affect everybody. By "consensus" I also mean "just let other users know first", and then maybe somebody will propose a better way. P.S. Clicking the first checkbox and then shift-clicking the last seem as easy to me ∴ Alex Smotrov 21:33, 12 October 2007 (UTC)Reply
Downloading the code isn't too much of a problem, since I cache it. However, I don't exactly appreciate caching code that is completely inapplicable to me. Having code that is applicable specifically to me is, in fact, what user scripts are for :) GracenotesT § 21:57, 12 October 2007 (UTC)Reply
Write the (import) code and make a list of the sections that need to be moved and I'd be happy to oblige. --MZMcBride 21:59, 12 October 2007 (UTC)Reply
Look at the diff at the top of this section and simply move that into MediaWiki:Sysop.js. Although I expected the admin who did the change to correct it. Or maybe I expected him to agree that shift-clicking (it's even mentioned in MediaWiki:Undeleteextrahelp) can achieve the same thing without the extra code ∴ Alex Smotrov 05:03, 13 October 2007 (UTC)Reply
It works fine, is useful/easier and we use it at de:wp, too. But if there is no consensus I'll remove it. Regards, —DerHexer (Talk) 09:06, 13 October 2007 (UTC)Reply
Sysop.js is already imported, so moving it to Sysop.js should be no problem. — Edokter • Talk • 10:13, 13 October 2007 (UTC)Reply
Moved. GDonato (talk) 15:21, 13 October 2007 (UTC)Reply
Thanks! —DerHexer (Talk) 09:58, 14 October 2007 (UTC)Reply

CSS hidden NavFrame

Latest comment: 17 years ago2 comments2 people in discussion

It seems the new code of createNavigationBarToggleButton() encourage users to use <div class=NavFrame style=display:none>. I don't think it's a good idea, what about users with JavaScript disabled? If something can be made visible only with JavaScript then it should be hidden only with JavaScript. In other words, the system should work more like collapsible tables: <div class="NavFrame autocollapse"> or <div class="NavFrame collapsed">. Any support for this? ∴ Alex Smotrov 14:27, 12 October 2007 (UTC)Reply

As the collapsible table code has been fixed to support nested tables, is there any reason not to deprecate the support for NavFrame? Is there an easy way to genreate a list of the most used templates which still use it? —Ruud 12:23, 15 October 2007 (UTC)Reply

Update ta[] tooltips

Latest comment: 17 years ago5 comments3 people in discussion

The ta[] definitions at the top of the page need to be updated. Introductory explanations: ta[] object is used by function akeytt() in wikibits.js to assign missing access keys and tooltips to Mediawiki interface. Due to the way the function is written, it cannot properly change the existing tooltip if you don't specify accesskey (in IE of Firefox place your mouse over «Help» link on the left, then over its bullet). To research which ta[] are not needed, you could use: browser with JavaScript temporarily disabled, HTML page source, Special:Allmessages, Mediawiki:Sidebar. My proposal:

∴ Alex Smotrov 14:27, 12 October 2007 (UTC)Reply

Update: looks like you can add new messages and Mediawiki accepts them, so if someone could test it by creating e.g. Mediawiki:Tooltip-n-About-Wikipedia and then visit any Wikipedia page with Javascript disabled, maybe the whole ta[] can be removed altogether ∴ Alex Smotrov 19:10, 12 October 2007 (UTC)Reply
  Done [1] It would appear so. GDonato (talk) 21:31, 12 October 2007 (UTC)Reply
So, anybody up to finish the task? Change the above-mentioned messages, plus create MediaWiki:Tooltip-n-contact, MediaWiki:Tooltip-n-Contents, MediaWiki:Tooltip-n-Featured-content, MediaWiki:Tooltip-n-Main-page, MediaWiki:Tooltip-t-log (this would be something like "View the list of actions of this user in logs"), MediaWiki:Tooltip-t-cite (finally found it), then disable JavaScript, refresh the page and make sure all the tooltips work. Then also create MediaWiki:Tooltip-ca-hiderevision, find any user with oversight permission to test it. Then all ta[] can be finally removed ∴ Alex Smotrov 05:03, 13 October 2007 (UTC)Reply
Done (except for asking a user with oversight permissions). —Ruud 12:41, 15 October 2007 (UTC)Reply

MediaWiki:IEFixes.js

Latest comment: 17 years ago2 comments2 people in discussion

Maybe create MediaWiki:IEFixes.js, so we only have to check for IE once? —Ruud 12:18, 15 October 2007 (UTC)Reply

There already is an IEFixes.js, which is not editable though. But if you mean en IE specific file, we shouldn't call it 'Fixes'. How about MediaWiki:IECommon.js? — Edokter • Talk • 13:37, 15 October 2007 (UTC)Reply

Azatoth's edit (import sysop.js)

Latest comment: 17 years ago22 comments4 people in discussion

I just found out that Azatoth's edit to the sysop.js import script broke the entire common.js with the error: "Object does not support this property or method". I have reverted. If you're going to optimize code, Please test in your monobook.js first! Thank you. — Edokter • Talk • 18:03, 14 October 2007 (UTC)Reply

I did test it, and I though there was no browser left out there that doesn't support Array.indexOf() (Javascript 1.6), but perhaps some are still using old browsers. But Array.indexOf is used in other codes in the Common.js. →AzaToth 18:31, 14 October 2007 (UTC)Reply
Well, IE6 and 7 (comparable to JavaScript 1.5) reject it; I don't know what type object wgUserGroups is, but it doesn's support indexOf. — Edokter • Talk • 19:02, 14 October 2007 (UTC)Reply
wgUserGroups is an Array, and Array.indexOf is JS 1.6. →AzaToth 19:28, 14 October 2007 (UTC)Reply
1) The browsers don't just "end their lifespan", people still use them. Devs still try to support even IE for Mac which was a very bad browser with practically no market share by now. 2) "Test" doesn't mean "test in my favorite browser only". The code doesn't work e.g. in Internet Explorer and Opera. 3) Array.indexOf is not used in Common.js ∴ Alex Smotrov 22:20, 14 October 2007 (UTC)Reply
Yea, I saw that, only other special arrays is used with indexOf. perhaps we should include JSL in Common,js? →AzaToth 16:34, 15 October 2007 (UTC)Reply
What is "JSL"? The indexOf you see being used are basic (JS 1.0) Text.indexOf. Nothing special about them. — Edokter • Talk • 16:55, 15 October 2007 (UTC)Reply
True, I mixed them up, uo untill JS 1.5 only strings have indexOf, but as of JS 1.6 Arrays do have it. JSL stands for "Javascript Standard Library", and contains code to fix many of such problems that some browsers lack functions. In User:AzaToth/morebits.js the top 1000 lines contains JSL. →AzaToth 18:56, 15 October 2007 (UTC)Reply

(deindent) I don't quite understand the last edit though... 'in' works on any object or array, and wgUsergroups is a valid array. Personally, I would do it like this: 

if ( wgUserGroups && !window.disableSysopJS ) {
  for ( var g in wgUserGroups ) {
    if ( wgUserGroups[g] == "sysop" ) {
      importScript( "MediaWiki:Sysop.js" )
      break
    }
  }
}

...making the loop stop once "sysop" is found. — Edokter • Talk • 19:06, 15 October 2007 (UTC)Reply

Was thinking of adding a break statement (think you really dont want a return there :)), but I dont know if older browsers can handle such advance code. →AzaToth 19:14, 15 October 2007 (UTC)Reply
Oh come on... for..in and break are both basic JS 1.0 statements. — Edokter • Talk • 19:19, 15 October 2007 (UTC)Reply
It's true that "in" works on any object, but for most browsers, "in" will do more than wanted, as it will iterate over all properties, and not only the values in an array. It's a common problem that people are using for( i in array ), and wont notice it directly until some property is added to the Array class, or another person with an other browser is checking it in. (Liker when opera dudes are getting Array.toString as a post in the array etc...) →AzaToth 19:12, 15 October 2007 (UTC)Reply
OK, the Mozilla docs discourages using for..in on arrays. I'd still like to see the break statement in though. — Edokter • Talk • 19:28, 15 October 2007 (UTC)Reply
I'll add it. →AzaToth 19:33, 15 October 2007 (UTC)Reply

Let me say it again: there is no need for the loop at all, since 'sysop' is always wgUserGroups[0] ∴ Alex Smotrov 19:18, 15 October 2007 (UTC)Reply

Is that absolutely true? Then where is 'autoconfirmed'? — Edokter • Talk • 19:21, 15 October 2007 (UTC)Reply
think bcrats has sysop in slot 1; →AzaToth 19:33, 15 October 2007 (UTC)Reply

Redo

How about adapting the import script to automatically import the usergroup's specific js file? 

/** Usergroup Javascript *******************************************************
  *
  *  Description: Allows for usergroup-specific Javascript (ie. MediaWiki:sysop.js).
  *  Created by: User:^demon
  */
if ( wgUserGroups && !window.disableUsergroupJS ) {
  for ( var g in wgUserGroups ) {
    importScript( "MediaWiki:" + wgUserGroups[g] + ".js" )
  }
}
Premature. There's only one function in Mediawiki:Sysop.js at the moment, and the typical user is in many groups which are unlikely ever to need specific javascript. (For example, I'm in ["sysop", "*", "user", "autoconfirmed", "emailconfirmed"].) Maybe - maybe - groups import, checkuser, or oversight might make use of specific javascript, but these groups are rare enough that it's not worth making everyone have to load two to four extra empty js pages. —Cryptic 18:37, 15 October 2007 (UTC)Reply
It was just an idea. — Edokter • Talk • 19:06, 15 October 2007 (UTC)Reply

window.disableSysopJS

Someone pointed out that the if (!window.disableSysopJS) is useless here, as the users' monobook is loaded after common.js, so sysop.js is imported anyway. The check should preferably be moved to sysop.js itself. Or more ideally, each function is sysop.js should have it's own check; that way admins can disable what they don't like. — Edokter • Talk • 15:21, 17 October 2007 (UTC)Reply

  Resolved
I made an enclosing in an addOnloadHook, that would take care of the problem. →AzaToth 16:54, 17 October 2007 (UTC)Reply
This is not a "fix" unless you mention the consequences: all the scripts inside Sysop.js now should start immediately (without addOnloadHook), and I'm not even sure that will work in all browsers ∴ AlexSm 17:25, 17 October 2007 (UTC)Reply
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js/Archive_11&oldid=172382587"