MediaWiki talk:Common.js/Archive Nov 2007

message: The printable versions of pages are messed up for anonymous users. —Ruud 19:25, 30 September 2007 (UTC)
replies: text: Can you be any more specific? What browser are you using? —Remember the dot (talk) 02:45, 1 October 2007 (UTC)
replies: text:  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)
replies: text: What browser are you using? —Remember the dot (talk) 04:09, 1 October 2007 (UTC)
replies: text:  FF 2.0.0.6 —Ruud 13:47, 1 October 2007 (UTC)
replies: text: Are you saying that you don't want those messages to print? —Remember the dot (talk) 16:12, 1 October 2007 (UTC)
replies: text: 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)
thread_title:  Printable version messed up 

message: 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:
# The script no longer depends on the .thumbborder (or any other) class.
# 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)
replies: text: 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)
replies: text: 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)
thread_title:  PNG transparency fix "V1.1" 

message: 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)
replies: text: Are you sure this cannot be done in common.css using condtional (#.IPA) declarations?  — Edokter • Talk •  10:14, 6 October 2007 (UTC)
replies: text: 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)
replies: text: '#' 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)
replies: text:  Done. Cheers. --MZMcBride 19:17, 9 October 2007 (UTC)
thread_title:  IPA style for IE 

message: Latest addition. Come on ...
# Consensus?
# Shift-clicking (see MediaWiki:Watchlistedit-normal-explain) is not good enough?
# MediaWiki:Sysop.js ?
∴ Alex Smotrov 21:18, 12 October 2007 (UTC)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: Sysop.js is already imported, so moving it to Sysop.js should be no problem.  — Edokter • Talk •  10:13, 13 October 2007 (UTC)
replies: text: Moved. GDonato (talk) 15:21, 13 October 2007 (UTC)

text: Thanks! —DerHexer (Talk) 09:58, 14 October 2007 (UTC)
thread_title:  Function to invert checkboxes 

message: It seems the new code of createNavigationBarToggleButton() encourage users to use . 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:  or . Any support for this? ∴ Alex Smotrov 14:27, 12 October 2007 (UTC)
replies: text: 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)
thread_title:  CSS hidden NavFrame 

message: The ta[] definitions at the top of the page need to be updated. Introductory explanations: ta[] object is used by function akeytt() in [/skins-1.5/common/wikibits.js 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:
* Delete ta["t-print"] and ta["t-permalink"] because Mediawiki:tooltip-t-print Mediawiki:tooltip-t-permalink say the same thing
* Delete ta["n-help"] ta["n-sitesupport"] ta["ca-nstab-project"] : Mediawiki:tooltip-n-help, Mediawiki:tooltip-n-sitesupport, Mediawiki:tooltip-ca-nstab-project and Mediawiki:accesskey-ca-nstab-project simply need to be changed
* Delete ta["n-mainpage"] : it simply doesn't change anything because of the current Mediawiki:Sidebar
* Keep ta["n-contact"] ta["n-Contents"] ta["n-Featured-content"] ta["n-Main-page"] since they are non-standard (no Mediawiki tooltips)
* Add ta["n-About-Wikipedia"] and ta["t-log"] («Logs»), these links on the left currently have no tooltips
* I'm not sure where ta["t-cite"] is used, maybe related to Mediawiki:cite_article_link?
* And personally I would also delete ta["ca-hiderevision"] = new Array("h","Hide this revision") because 26 users with oversight permission can probably live without it 
∴ Alex Smotrov 14:27, 12 October 2007 (UTC)
replies: text: 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)
replies: text:   It would appear so. GDonato (talk) 21:31, 12 October 2007 (UTC)
replies: text: 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)
replies: text:  Done (except for asking a user with oversight permissions). —Ruud 12:41, 15 October 2007 (UTC)
thread_title:  Update ta[] tooltips 

message: Maybe create MediaWiki:IEFixes.js, so we only have to check for IE once? —Ruud 12:18, 15 October 2007 (UTC)
replies: text: 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)
thread_title:  [[MediaWiki:IEFixes.js]] 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: wgUserGroups is an Array, and Array.indexOf is JS 1.6. →AzaToth 19:28, 14 October 2007 (UTC)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: Oh come on... for..in and break are both basic JS 1.0 statements.  — Edokter • Talk •  19:19, 15 October 2007 (UTC)

text: 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)
replies: text: 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)
replies: text: I'll add it. →AzaToth 19:33, 15 October 2007 (UTC)

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

text: 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)
replies: text: It was just an idea.  — Edokter • Talk •  19:06, 15 October 2007 (UTC)

text: I made an enclosing in an addOnloadHook, that would take care of the problem. →AzaToth 16:54, 17 October 2007 (UTC)
replies: text: 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)
thread_title:  Azatoth's edit (import sysop.js) 

message: 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)
replies: text: It was just an idea.  — Edokter • Talk •  19:06, 15 October 2007 (UTC)
thread_title: Redo

message: 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)
replies: text: I made an enclosing in an addOnloadHook, that would take care of the problem. →AzaToth 16:54, 17 October 2007 (UTC)
replies: text: 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)
thread_title: window.disableSysopJS

message: (deindent) Wow... 6 seconds traversing the DOM on Wikipedia:Route diagram template/Catalog of pictograms (400 PNGs!) with the optimizations! that used to be 30... The PngFixDisabled flag works as well.  — Edokter • Talk •  22:14, 12 October 2007 (UTC)
replies: text: I can add outerSpanStyle.backgroundImage = imgStyle.backgroundImage for checkered background support... Thoughts?  — Edokter • Talk •  22:18, 12 October 2007 (UTC)
replies: text: Let's go the whole way and flatten all CSS information, now that you've showed me how to do that:
Since this new code doesn't add any costly DOM lookups, it will in all likelihood still go very fast. I noticed no slowdown on :Commons:Category:Icons for railway descriptions. Of course, when the squid servers are fixed then we should integrate this code back into the 1px transparent image code to increase speed. —Remember the dot (talk) 23:22, 12 October 2007 (UTC)

text: Hmm, 13 seconds... but IE crashes on my pngtest page. The method works, but each element is now filled up with properties that weren't originally there; all default properties and values are assigned. I have to test what makes it crash.  — Edokter • Talk •  23:50, 12 October 2007 (UTC)

text: Nope sorry, it crashes on any image with a border. Simply copying all CSS apparently cause some properties to conflict. We're better off handpicking only those we need.  — Edokter • Talk •  23:53, 12 October 2007 (UTC)
replies: text: That's odd. :Commons:User:Edokter/pngtest works flawlessly. Is the problem just on the English Wikipedia? What is the exact text of the error you are receiving? —Remember the dot (talk) 00:54, 13 October 2007 (UTC)
replies: text: Just the standard "Internet Explorer has caused a probem and must be closed down. Do you want to send an error roport to Microsoft?" I'll test the code on Commons later at home.  — Edokter • Talk •  08:11, 13 October 2007 (UTC)

text: No crash on Commons, though I'm seeing considerable jumps with bordered images again. I think this idea is out. I say we simply add backgroundImage.  — Edokter • Talk •  14:18, 13 October 2007 (UTC)
thread_title: PngFix live again

message: A user using IE5.5 has problems seeing images only as a thin vertical line, so setting width and height to 1px probably wasn't the best solution. We could max() the width and height again, but that probably wouldn't solve his problem in collapsible tables. Tested with max(), but that takes a serious performance hit. I recommend to just disable the script for IE5.5.  — Edokter • Talk •  14:53, 13 October 2007 (UTC)
replies: text: Fine. Disabled for IE 5.5, and picks and chooses CSS properties to flatten. Let's use this until we can find something better.
As a side note, I hope you can see why asking users to upgrade will give them a better experience than using endless workarounds. This problem can only be truly resolved by upgrading, so it's best to get users to upgrade. —Remember the dot (talk) 20:16, 13 October 2007 (UTC)

text: . Yes upgrade is the best, but if we're going to hack around, we better do it right :) Only addition I may have for the future is imagemaps. See my monobook.js. It relies on the 1px gif, but as imagemaps are not nearly as numerous as normal images, it shouldn't cause an overload. I asked Brion if this would be OK.  — Edokter • Talk •  20:53, 13 October 2007 (UTC)

text: I asked myself the same thing, but no, there are no endless loops or hangups. I actually tried adding i++ but then it skipped half the images. So yeah, there must be some perfectly explainable magic; but I don't know what is is...  — Edokter • Talk •  21:00, 13 October 2007 (UTC)
replies: text: I think I figured it out; i isn't actually incremented. However, when replaceChild replaces the original image with the span, the original image is removed form the DOM, causing the rest of the images to move up one place in the list.  — Edokter • Talk •  21:10, 13 October 2007 (UTC)

text: documentImages.length decreases by 1 every time you change an img element to a span element because that img element is removed from the list. —Remember the dot (talk) 21:09, 13 October 2007 (UTC)
thread_title: "1px"

message: Brion has given his OK to use the "1px hack" (as he calls it) for image maps only. That would make the code complete. If the squid should turn into a puddle of mud again, he'll disable it. I'll put the code in. I will use :Image:Transparent.gif instead, as that image is now protected on Commons.  — Edokter • Talk •  14:49, 18 October 2007 (UTC)
replies: text: Yes, but would IE be able to understand it? Other browsers, sure, but we're dealing with IE here. —Remember the dot (talk) 06:26, 21 October 2007 (UTC)
replies: text:  After a little bit of online research... no, I don't think it would work.  :-\  --Iamunknown 16:18, 23 October 2007 (UTC)
replies: text: Would have been nice... I actually experimented with a local resource; it worked with a resource GIF image, but IE doesn't have a blank iamge embedded (and wouldn't work in IE6 SP2 anyway). Anyway, server load is greatly reduced as imagemaps are not nearly as widespread. The squid is still up after five days.  — Edokter • Talk •  16:42, 23 October 2007 (UTC)
thread_title: Image maps

message: I realize the scrolling fundraising banner that was just added is hard-coded, so the admins here can't do much about it. But could someone please consider adding a small link to the side of it that temporarily removes the scrolling part? I don't think people mind the notice so much as the ticker, and we should have a way to opt out of this "feature". – Minh Nguyễn (talk, contribs) 23:19, 22 October 2007 (UTC)
replies: text: Probably a silly question as I'm not familiar with anything "higher up" than Wikipedia itself, but why was it hard-coded? I could tell within ten seconds of looking at it that a lot of people would find it extremely irritating, and that it would therefore probably end up counter-productive in terms of encouraging donations. Surely someone "up there" noticed that, too? Loganberry (Talk) 23:27, 22 October 2007 (UTC)
replies: text: No idea. I've searched at Wikipedia, Meta, and the mailing lists and haven't found any explanation... I don't see why we couldn't just make the ticker into a tag like in previous fundraisers. – Minh Nguyễn (talk, contribs) 00:12, 23 October 2007 (UTC)
replies: text: Or at least something less unprofessional and annoying, like an infinite popup cascade. —Cryptic 01:31, 23 October 2007 (UTC)
thread_title:  Option to collapse fundraising banner 

message: Could we move the [dismiss] tag to the right of the banner rather than below it.
No need to push the body text down even more than it already is.  Dragons flight 02:05, 23 October 2007 (UTC)
replies: text: That's a bit of a PITA to do .. but lemme give er a shot ... AmiDaniel (talk) 02:25, 23 October 2007 (UTC)
replies: text: Done. AmiDaniel (talk) 02:33, 23 October 2007 (UTC)
thread_title:  Dismiss button location 

message: After a brief panic related to the hacked dismiss button that was added I thought I should leave a note here: Anyone who puts in site JS code that sets cookies for anons will win a free visit from me and a personal stabbing. That is all. ;) (if cookies are set for a substantial number of anons the site will be hard-down for a fair amount of time). --Gmaxwell 02:15, 23 October 2007 (UTC)
replies: text: Hehe. But crashing the site is fun :) AmiDaniel (talk) 02:20, 23 October 2007 (UTC)

text: A way of turning it off completely would be really nice, if you have the time. At the moment I am using the following hack in my monobook.js for those interested. Conrad.Irwin 17:43, 23 October 2007 (UTC)
replies: text: Adding #siteNotice { display:none; } to your monobook.css will probably work better :) AmiDaniel (talk) 18:56, 23 October 2007 (UTC)
replies: text: Thanks! I had yet to play with custom CSS - but now the hours I can waste :) Conrad.Irwin 19:15, 23 October 2007 (UTC)
thread_title:  A note.