MediaWiki talk:Common.js/Archive 11

Printable version messed up

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

Can you be any more specific? What browser are you using? —Remember the dot ^(talk) 02:45, 1 October 2007 (UTC)

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)

What browser are you using? —Remember the dot ^(talk) 04:09, 1 October 2007 (UTC)

FF 2.0.0.6 —Ruud 13:47, 1 October 2007 (UTC)

Are you saying that you don't want those messages to print? —Remember the dot ^(talk) 16:12, 1 October 2007 (UTC)

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)

Problem with importStylesheet in IE?

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)

You need to specify a fully qualified URL, not a wikilink as you are trying to do. Try this instead:

importStylesheet("http://wiki.riteme.site/w/index.php?title=User:Shardsofmetal/monobook.css&action=raw&ctype=text/css");

— Edokter • Talk • 11:54, 3 October 2007 (UTC)

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)

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)

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)

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"

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)

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)

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)

IPA style for IE

{{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)

Are you sure this cannot be done in common.css using condtional (#.IPA) declarations? — Edokter • Talk • 10:14, 6 October 2007 (UTC)

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)

'#' 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)

Done. Cheers. --MZMcBride 19:17, 9 October 2007 (UTC)

Function to invert checkboxes

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)

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)

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)

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 :) Gracenotes^T § 21:57, 12 October 2007 (UTC)

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)

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)

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)

Sysop.js is already imported, so moving it to Sysop.js should be no problem. — Edokter • Talk • 10:13, 13 October 2007 (UTC)

Moved. GDonato (talk) 15:21, 13 October 2007 (UTC)

Thanks! —DerHexer (Talk) 09:58, 14 October 2007 (UTC)

CSS hidden NavFrame

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)

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)

Update ta[] tooltips

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:

• 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)

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)

 Done [1] It would appear so. GDonato (talk) 21:31, 12 October 2007 (UTC)

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)

Done (except for asking a user with oversight permissions). —Ruud 12:41, 15 October 2007 (UTC)

MediaWiki:IEFixes.js

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

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)

Azatoth's edit (import sysop.js)

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)

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)

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)

wgUserGroups is an Array, and Array.indexOf is JS 1.6. _→AzaToth 19:28, 14 October 2007 (UTC)

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)

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)

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)

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)

(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)

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)

Oh come on... for..in and break are both basic JS 1.0 statements. — Edokter • Talk • 19:19, 15 October 2007 (UTC)

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)

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)

I'll add it. _→AzaToth 19:33, 15 October 2007 (UTC)

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)

Is that absolutely true? Then where is 'autoconfirmed'? — Edokter • Talk • 19:21, 15 October 2007 (UTC)

think bcrats has sysop in slot 1; _→AzaToth 19:33, 15 October 2007 (UTC)

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)

It was just an idea. — Edokter • Talk • 19:06, 15 October 2007 (UTC)

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)

Resolved

I made an enclosing in an addOnloadHook, that would take care of the problem. _→AzaToth 16:54, 17 October 2007 (UTC)

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)

PNG fix disabled

We've disabled the IE 6 PNG workaround for the moment after spending a couple hours looking into a squid bug which turned upload.wikimedia.org into mud for a while this afternoon.

We're not 100% sure yet what's up with it, but for now I'd recommend at least keeping that .GIF out until we know it's not going to break again under maximum load. --brion 19:29, 9 October 2007 (UTC)

See [2] --brion 19:36, 9 October 2007 (UTC)

Any transparency fix which doesn't involve sending 1000 requests per second for some small image file should be fine. But the 1-pixel GIFs are definitely out for now. -- Tim Starling 19:38, 9 October 2007 (UTC)

I'm pretty sure i't snot the 1PX (42 bytes) image. It's called upon a lot becuase it is loeaded with every other, and much larger PNG/SVG images; that makes it stick out in the HTTP logs, but it surely can't be the cause of the problem. Why would it only occur on the florida squid if it were?

If, however remote, it is related to the 1px image, is there an alternative location where this file can be stored statically? — Edokter • Talk • 19:52, 9 October 2007 (UTC)

Yes, the problem was the 42-byte image. We are absolutely sure of this. We think it only occurred on the Florida squids because the cached javascript expired there first. The 1px file already is stored statically. You could probably work around the problem by spreading the load over a large number (say 100) of 1px images. But you wouldn't want to try this without sysadmin involvement on #wikimedia-tech. -- Tim Starling 20:24, 9 October 2007 (UTC)

But is it also the root of the problem? The comments on wikitech-l indicate something else may be the problem. The list is pretty quiet now. Is it still being looked into? — Edokter • Talk • 23:26, 9 October 2007 (UTC)

Can we go back to [3], then, for the time being? This was the version of the fix that did not use the 1px transparent image (which, incidentally, does not have to be GIF, it could also be an indexed PNG). Anyway, the older version was a bit slower, but perhaps in the end it causes less problems. —Remember the dot ^(talk) 20:20, 9 October 2007 (UTC)

Why is it slower? Does it load the image twice? -- Tim Starling 20:27, 9 October 2007 (UTC)

No, it involves reconstructing the DOM for each PNG img element, instead of just tweaking the img element. The result was much more processing power was expended on the users' end for pages with large numbers of PNG images (of which there are few). This was done on the last version of the code for images that had borders and so simple tweaking wasn't good enough. Blame IE's quirkiness. —Remember the dot ^(talk) 20:30, 9 October 2007 (UTC)

I'll disable the 1px part of the code then. BTW, I don't think using a 1px PNG would have made any difference. If there is a way to distribute the load for the 1px file, I'm all ears, because the majority of images don't have a border and using the 1px image really speeds up rendering. — Edokter • Talk • 20:46, 9 October 2007 (UTC)

On second thought, I think it's best to leave the script disabled alltogether for the time being, at least until there is a satisfactory solution to the squid problem. I'm also not reverting to the earlier version, because that one excludes imagemaps. Combined with the speed problem this script causes, I find that totally unsatisfactory. It is not worth all the trouble to have a few, but not all PNGs with transparency. For those who really want it, they can put the script in their monobook.js file. That way users can make their own choice (something that was taken away as well, as the script could not be overridden). I hope everyone can agree with this. It was a nice experiment and a good learning experience. It would have been nicer if it worked 100% though. — Edokter • Talk • 21:52, 10 October 2007 (UTC)

It is very upsetting to find admins who, as soon as they receive the admin bit, begin acting unilaterally, without consensus.

What you are essentially saying is that it's better to have no transparent PNGs work than to have the majority of them work.

While you may blame my code for breaking the edit toolbar again, you may have noticed that the code I requested be put back, found at [4], is not identical to the block of code you enabled in the version that made the squid servers turn to mud. It includes additional checks to make sure that it won't break things like bordered images the edit toolbar and image maps.

Removing the script entirely, as you have done, would eventually place us back where we were before, with users demanding that we keep duplicate specially-created raster renderings of images to compensate for IE6's quirky behavior. Putting in a PNG hack saves us a whole bunch of time and trouble trying to maintain at least 2 copies of each alpha-transparent image. You complain that you think it's too slow, but the added slowness (which is less than a second's delay on nearly every page, and virtually nonexistant on up-to-date browsers) is more than worth the time we save not having to worry about maintaining duplicate images. —Remember the dot ^(talk) 00:32, 11 October 2007 (UTC)

Incidentally, I also heartily disagree with your statement "That way users can make their own choice (something that was taken away as well, as the script could not be overridden)." Users have always had the choice, have always been asked to make the choice, to update to IE7 or to use a different browser such as Opera or Firefox. You made your own personal choice to stick with IE6 despite knowing the problems inherent in this browser. This does not mean that others do not have that choice.

I know you will say "But what about users editing from work, school or a public computer, who do not have power to update their computers?" Well, for these people we will accommodate IE6 as best we can, but not at the expense of the majority of users who do not use IE<=6. —Remember the dot ^(talk) 00:42, 11 October 2007 (UTC)

"Users editing from..." Editing? Pshaw. Editors make up only a tiny fraction of the people who visit Wikipedia and editors can put things in their own user JS. I think it would be a mistake to make editors your first priority in a decision related to this. I can't comment on this fix, because I don't fully understand it but in general a change that makes transparent PNGs work right for IE6 users is a good thing and once the issues are worked out it should probably be submitted for an inclusion as a standard part of MediaWiki. --Gmaxwell 00:52, 11 October 2007 (UTC)

Sorry. That was a poor choice of words. I meant everyone who uses Wikipedia, not just those who edit.

I'm of the opinion that the fix is too much of a hack to be bundled for mainstream use, but once we stop bickering about it for a decent period of time, I'd be OK with bundling it if the developers think it's OK. —Remember the dot ^(talk) 00:57, 11 October 2007 (UTC)

I simply cannot comprihend your train of thought here... First you offer a script that will 'enhance' PNG display for IE6 user, but at a cost of speed. Users cannot opt out, and if they don't like it, they should just upgrade? What are you trying to accomplish? I want people to have the choice to not use this script, but that is not the choice you are giving them. Instead, you are practically forcing them to upgrade by impeding IE6 performance. I simply cannot accept that. — Edokter • Talk • 01:34, 11 October 2007 (UTC)

Is some version of this fix going to be enabled, or should I begin restoring the IE6-compatible images that were replaced with SVGs? —David Levy 01:10, 11 October 2007 (UTC)

{{editprotected}}

As soon as an administrator does what I originally requested and restores the PngFix code found at [5] (rather than enabling other code from a different revision, which was not what I requested), IE6 users will have their transparency back. —Remember the dot ^(talk) 01:14, 11 October 2007 (UTC)

In case we cannot agree on acceptable PNGfix code, here's a partial solution: wrap important problem images (those that were replaced by GIFs before, see David's question above) with <span class=pngalpha>, and let the script fix only them ∴ Alex Smotrov 14:02, 11 October 2007 (UTC)

Section break

Putting in a PNG hack saves us a whole bunch of time and trouble trying to maintain at least 2 copies of each alpha-transparent image. What? What point is there in maintaining two version of an image when only one can be linked/displayed? I'm sorry, but you completely lost me here.

I admit, I am an IE6 user, and as such, I experience the effects of this script first hand, including the speed impact. Of course the slowdown on 'up to date' is "virtually nonexistant"; they don't touch the script. And I don't blame you anything; It was brion who disabled the script; I partially re-enabled it, forgetting to exclude the imagmaps. When I realized my mistake, I started to weigh the options: I never liked the old script; the slowdown on certain pages was unacceptable to me, and there was no way to turn the script off, safe turning off javascript alltogether. That's why I was so desperate to fix it. When this final version was made live, I finally felt we had a solution. Now that that code apparently caused a squid to fall over, we are indeed back to square one, and I'm kind of relieved too, because while looks are one thing, usability in terms of speed has higher priority in my mind. And since IE6 is found on mostly older systems (below 1 HGz), I feel the speed issue potentially impacts users more then I'm willing to accept.

In any event, until the squid problem actually solved, I no longer see this script fit for use in Common.js. Instead, I see it much better suited for users to put it in their own monobook.js. For one, it gives the users a choice, and would have way less impact on the squid servers; I expect not that many users will actually install the script.

And please do not imply that I'm on some sort of power trip here. I'm a user just like you, but I have added responsabilities to other users as well. Having first hand experience with the script in all permutation does give me insight as to what impact it has on other users. That is what I act on! Any ohter admin is free to take me to task if they feel I stepped out of bound, and will abide by whatever consensus will come out any discussion following my actions. — Edokter • Talk • 01:21, 11 October 2007 (UTC)

The primary purpose of this script was to avoid the problem that you can see at Image:Mergefrom.gif and other places throughout Wikipedia. Both a GIF (or an indexed PNG) as well as the SVG had to be maintained because of the desire to have it work well for IE6 users and the desire to maintain flexibility. The script saves us the trouble of creating special copies of SVG images or converting PNGs to be indexed, which is not always ideal. As you can image, the amount of time expended creating and maintaining duplicate copies of images is considerable.

You are still making the false claim that users do not have the choice to use a different browser. But if it would make you happy, we can add an extra switch into the PNG fix code to allow individual users to turn it off. There's also the option of modifying your user-agent string, which may be a slightly better recourse than disabling JavaScript. —Remember the dot ^(talk) 01:35, 11 October 2007 (UTC)

I still don't follow. Are you saying Wikipedia has some sort of mechanism in place that serves the GIF images to IE6 user while serving the SVG's to other borwser? If not, there should be no point in maintaining two versions in the first place. In fact, Wikipedia has always advocated the use of SVG versions, for the sake of scalability (not transparency).

and I'm not making a false claim; of course they have a choice to upgrade. However, this script should not be a major reason to do so; that is a seriously undue incentive. And how would you implement this switch? A user's monobook.js is out, as common.js is already done executing before monobook.js is even started. User-agent modification is a hack I do not even consider to be feasable; that would break other functionality on Wikipedia, not to mention other sites. — Edokter • Talk • 01:51, 11 October 2007 (UTC)

In the end only the GIFs were used for the merge icons because of IE6's limitations. Separate SVGs had to be maintained for other uses. And the PngFix function itself does not execute until after a user's monobook.js, so the if statement for user preference would be in the PngFix function. —Remember the dot ^(talk) 01:58, 11 October 2007 (UTC)

Wrong! Order of execution prevents the user's monobook.js from interfering with common.js. — Edokter • Talk • 02:12, 11 October 2007 (UTC)

Except that the PngFix code adds a new hook after the page has finished loading (all other scripts will have been executed by then). —Remember the dot ^(talk) 02:26, 11 October 2007 (UTC)

Is this what you wanted?

Code

function PngFix()
{
   if (document.body.filters && !window.PngFixDisabled)
   {
       var documentImages = document.images
       for (var i = 0; i < documentImages.length;)
       {
          var img = documentImages[i]
          var imgSrc = img.src
          if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && !img.useMap && !img.onclick)
          {
             var outerSpan = document.createElement("span")
             var innerSpan = document.createElement("span")
             var outerSpanStyle = outerSpan.style
             var innerSpanStyle = innerSpan.style
 
             outerSpan.id = img.id
             outerSpan.className = img.className
             outerSpan.title = img.title
             outerSpanStyle.cssText = img.style.cssText
             outerSpanStyle.display = "inline-block"
             outerSpanStyle.fontSize = "0"
             outerSpanStyle.verticalAlign = "middle"
             if (img.parentElement.href) outerSpanStyle.cursor = "hand"
 
             innerSpanStyle.width = img.width + "px"
             innerSpanStyle.height = img.height + "px"
             innerSpanStyle.display = "inline-block"
             innerSpanStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + encodeURI(imgSrc) + "')"
 
             outerSpan.appendChild(innerSpan)
             img.parentNode.replaceChild(outerSpan, img)
          }
          else
          {
             i++
          }
       }
   }
}

if (navigator.appName == "Microsoft Internet Explorer")
{
    var version = navigator.appVersion.substr(22, 3)
    if (version == "6.0" || version == "5.5")
        window.attachEvent("onload", PngFix)

}

In this code, a user has only to add "PngFixEnabled = false" to their monobook.js and the code will be disabled. But I really do not see why a user would want to do this rather than just use a different, more advanced browser and avoid the problem entirely. —Remember the dot ^(talk) 02:53, 11 October 2007 (UTC)

• I still don't feel comfortable imposing this script on all IE6 users.
• Is the PngFixEnabled flag guaranteed to work?
• There is still the problem of collapsed tables to be solved. Images in collapsed tables don't show. Somehow, img.width and img.height (thus innerSpan width and height) are set to zero, but I don't know what's causing this. This is a showstopper. — Edokter • Talk • 13:33, 11 October 2007 (UTC)

Note: this flag will work, but the same thing could be implemented with just if (document.body.filters && !window.PngFixDisabled) ∴ Alex Smotrov 14:02, 11 October 2007 (UTC)

Where is window.PngFixDisabled defined? — Edokter • Talk • 14:14, 11 October 2007 (UTC)

It's a javascript thing: all variables are also defines as properties of the window object, and using "window.x" will not result in an error if the variable hasn't been declared. This approach simply makes the code a bit shorter since you don't have to declare "x", it's already used in Mediawiki:Common.js: look for !window.disableSysopJS ∴ Alex Smotrov 14:49, 11 October 2007 (UTC)

OK, I like that. However, the collapsable tables remain a problem. If someone could have a look in collapseTable to see what is causing the images/spans to have zero size, then I can live with the old script being re-enabled. — Edokter • Talk • 15:19, 11 October 2007 (UTC)

If you could provide an example page maybe I will try to take a look. (There are no collapsible tables at User:Edokter/pngtest :) Also, please change the 3rd line into if (!document.body.filters || window.PngFixDisabled) return and then remove indentations a little... ∴ Alex Smotrov 19:17, 11 October 2007 (UTC)

Section break 2

Examples of collapsed tables: Wikipedia:Route diagram template (scroll down), User:VanTucky (userboxes, as many users employ them). PS. Why change the trird line? You're just reversing all boolean operators with exactly the same outcome. — Edokter • Talk • 21:27, 11 October 2007 (UTC)

Outcome is the same, but the function would be easier to read, 2 lines shorter and with less indent from the left. But of course, from my point of view the whole Common.js file needs cleanup, so ... never mind ∴ Alex Smotrov 14:27, 12 October 2007 (UTC)

Here. I believe I've resolved the collapsible table issues:

Code

function PngFix()
{
    if (document.body.filters && !window.PngFixDisabled)
    {
        var documentImages = document.images
        var documentCreateElement = document.createElement
        var funcEncodeURI = encodeURI
        
        for (var i = 0; i < documentImages.length;)
        {
            var img = documentImages[i]
            var imgSrc = img.src
            
            if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && !img.useMap && !img.onclick)
            {
                var outerSpan = documentCreateElement("span")
                var innerSpan = documentCreateElement("span")
                var outerSpanStyle = outerSpan.style
                var innerSpanStyle = innerSpan.style
                var imgCurrentStyle = img.currentStyle
                
                outerSpan.id = img.id
                outerSpan.className = img.className
                outerSpan.title = img.title
                outerSpanStyle.borderWidth = imgCurrentStyle.borderWidth
                outerSpanStyle.borderStyle = imgCurrentStyle.borderStyle
                outerSpanStyle.borderColor = imgCurrentStyle.borderColor
                outerSpanStyle.display = "inline-block"
                outerSpanStyle.fontSize = "0"
                outerSpanStyle.verticalAlign = "middle"
                if (img.parentElement.href) outerSpanStyle.cursor = "hand"
                
                innerSpanStyle.width = "1px"
                innerSpanStyle.height = "1px"
                innerSpanStyle.display = "inline-block"
                innerSpanStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + funcEncodeURI(imgSrc) + "')"
                
                outerSpan.appendChild(innerSpan)
                img.parentNode.replaceChild(outerSpan, img)
            }
            else
            {
                i++
            }
        }
    }
}

if (navigator.appName == "Microsoft Internet Explorer")
{
    var version = navigator.appVersion.substr(22, 3)
    if (version == "6.0" || version == "5.5")
    {
        window.attachEvent("onload", PngFix)
    }
}

The problem was more IE quirkiness. IE refuses to say what the image's width and height are when the image is set to display:none. After reading [6], I experimented a bit more and decided to force the image width to 1px if it is 0px. IE is so quirky that having width:1px and height:0px makes it display the image.

Now, if IE will display the image OK with width:1px and height:0px, why not use these static values for all images and gain a bit of speed? Well, I'm trying to avoid altering the DOM beyond what is neccessary. While the filter forces the element to display at the correct size, the element's area is still 0x1 (try setting background-color and you'll see what I mean). Fancy CSS like background-color could be broken unless the original width and height are preserved.

On the plus side, I noticed that a lookup for document.createElement was being performed twice for every image. By caching this function pointer (see [7] "Cache Function Pointers at all costs"), the speed increased significantly. —Remember the dot ^(talk) 06:32, 12 October 2007 (UTC)

That seems to work! Further more, everything still works by just assigneing "1px" to width and heigh... so no need for even img.widht/height or the max function. Please test to make sure my clunky machine box at work does not deceive me (edit: seems to work fine at home as well). Because I still feel it needs to be class independent, I've removed img.style.cssText. I found no difference in speed doing so. — Edokter • Talk • 11:09, 12 October 2007 (UTC)

You might want to read the second paragraph of explanation "Now, if IE...", where I explained why just using "1px" for width/height is a bad idea. It actually changes the behavior of the element a bit, which is something I'm really trying to avoid. And removing all styling except border information is likewise a bad idea. Surely there is a way to cleanly flatten all style information.

Also, when bugzilla:11549 is fixed then there will be no need to flatten style information at all. There's really no reason why .thumbborder has to be limited to img elements. —Remember the dot ^(talk) 16:33, 12 October 2007 (UTC)

I did read your 2nd paragraph; Now read this: style is applied to the outer span, remember? Changing the background color (or any other style) of the outerspan does work. So yes, there is absolutely no problem just using "1px". Test it. As for cssText, what if another image class is defined in the future? Are you going to file a bug report again? I stated before that this script should be completely independent of any CSS classes. And yes, I did try to find a way to copy all style info (currentStyle.cssText does not work). I am getting a bit tired of this... I have compromised a lot, but you keep rejecting other people's input. — Edokter • Talk • 17:05, 12 October 2007 (UTC)

I just wanted to point out that behaivior is changed in any case: context (right-click) menu on a "fixed" image looks different. Also ... I found this really old thread: MediaWiki talk:Common.js/Archive_1#IE alpha transparency ∴ Alex Smotrov 19:10, 12 October 2007 (UTC)

Interesting thread :) BTW. Yes, the context menu is different, that was to be expected, as you're actually looking at SPANs, not IMGs. — Edokter • Talk • 19:24, 12 October 2007 (UTC)

I stand corrected. 1x1px will be fine.

I thought that there would be some way to iterate through the defined properties of img.currentStyle (which would allow full flattening), but there does not seem to be any way to get a list of the defined properties. I'm willing to compromise with just flattening the border information. —Remember the dot ^(talk) 20:19, 12 October 2007 (UTC)

One could use for (i in imgCurrentStye) outerSpanStyle[i] = imgCurrensStyle[i], but that would defenitely slow the script to a crawl. outerSpanStyle = imgCurrentStyle (not tested yet) could theoretically work, but that just references the original object, not copy it. However, since the original img object is discarded anyway, we could give it a shot.

In the mean time, I'm glad you turned around. Sorry to jump out of my socks. I will make the edit. — Edokter • Talk • 21:30, 12 October 2007 (UTC)

PngFix live again

(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)

I can add outerSpanStyle.backgroundImage = imgStyle.backgroundImage for checkered background support... Thoughts? — Edokter • Talk • 22:18, 12 October 2007 (UTC)

Let's go the whole way and flatten all CSS information, now that you've showed me how to do that:

Code

function PngFix()
{
    if (document.body.filters && !window.PngFixDisabled)
    {
        var documentImages = document.images
        var documentCreateElement = document.createElement
        var funcEncodeURI = encodeURI
        
        for (var i = 0; i < documentImages.length;)
        {
            var img = documentImages[i]
            var imgSrc = img.src
            
            if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && !img.useMap && !img.onclick)
            {
                var outerSpan = documentCreateElement("span")
                var innerSpan = documentCreateElement("span")
                var outerSpanStyle = outerSpan.style
                var innerSpanStyle = innerSpan.style
                var imgCurrentStyle = img.currentStyle
                
                outerSpan.id = img.id
                outerSpan.title = img.title
                for (var property in imgCurrentStyle)
                {
                    outerSpanStyle[property] = imgCurrentStyle[property]
                }
                outerSpanStyle.display = "inline-block"
                outerSpanStyle.fontSize = "0"
                outerSpanStyle.verticalAlign = "middle"
                if (img.parentElement.href) outerSpanStyle.cursor = "hand"
                
                innerSpanStyle.width = "1px"
                innerSpanStyle.height = "1px"
                innerSpanStyle.display = "inline-block"
                innerSpanStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + funcEncodeURI(imgSrc) + "')"
                
                outerSpan.appendChild(innerSpan)
                img.parentNode.replaceChild(outerSpan, img)
            }
            else
            {
                i++
            }
        }
    }
}

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)

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)

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)

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)

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)

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)

"1px"

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)

Fine. Disabled for IE 5.5, and picks and chooses CSS properties to flatten. Let's use this until we can find something better.

Code

function PngFix()
{
    if (document.body.filters && !window.PngFixDisabled)
    {
        var documentImages = document.images
        var documentCreateElement = document.createElement
        var funcEncodeURI = encodeURI
        
        for (var i = 0; i < documentImages.length;)
        {
            var img = documentImages[i]
            var imgSrc = img.src
            
            if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && !img.useMap && !img.onclick)
            {
                var outerSpan = documentCreateElement("span")
                var innerSpan = documentCreateElement("span")
                var outerSpanStyle = outerSpan.style
                var innerSpanStyle = innerSpan.style
                var imgCurrentStyle = img.currentStyle
                
                outerSpan.id = img.id
                outerSpan.className = img.className
                outerSpan.title = img.title
                outerSpanStyle.borderWidth = imgCurrentStyle.borderWidth
                outerSpanStyle.borderStyle = imgCurrentStyle.borderStyle
                outerSpanStyle.borderColor = imgCurrentStyle.borderColor
                outerSpanStyle.backgroundImage = imgCurrentStyle.backgroundImage
                outerSpanStyle.display = "inline-block"
                outerSpanStyle.fontSize = "0"
                outerSpanStyle.verticalAlign = "middle"
                if (img.parentElement.href) outerSpanStyle.cursor = "hand"
                
                innerSpanStyle.width = "1px"
                innerSpanStyle.height = "1px"
                innerSpanStyle.display = "inline-block"
                innerSpanStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + funcEncodeURI(imgSrc) + "')"
                
                outerSpan.appendChild(innerSpan)
                img.parentNode.replaceChild(outerSpan, img)
            }
            else
            {
                i++
            }
        }
    }
}

if (navigator.appName == "Microsoft Internet Explorer")
{
    var version = navigator.appVersion.substr(22, 3)
    if (version == "6.0")
    {
        window.attachEvent("onload", PngFix)
    }
}

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)

 Done. 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)

Wont that code result in an endless loop? as i is only incremented in the else statement? or is there some magic here? _→AzaToth 20:56, 13 October 2007 (UTC)

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)

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)

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)

Optimize further

As long as we're axing support for IE 5.5, let's simplify the code a bit:

Code

/** 
  * Correctly handle PNG transparency in Internet Explorer 6
  * http://homepage.ntlworld.com/bobosola. Updated 18-Jan-2006.
  * 
  * Adapted for Wikipedia by Remember_the_dot and Edokter
  * 
  * http://homepage.ntlworld.com/bobosola/pnginfo.htm states "This page contains more information for
  * the curious or those who wish to amend the script for special needs", which I take as permission to
  * modify or adapt this script freely. I release my changes into the public domain.
  */

function PngFix()
{
    if (document.body.filters && !window.PngFixDisabled)
    {
        var documentImages = document.images
        var documentCreateElement = document.createElement
        var funcEncodeURI = encodeURI
        
        for (var i = 0; i < documentImages.length;)
        {
            var img = documentImages[i]
            var imgSrc = img.src
            
            if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && !img.useMap && !img.onclick)
            {
                var outerSpan = documentCreateElement("span")
                var innerSpan = documentCreateElement("span")
                var outerSpanStyle = outerSpan.style
                var innerSpanStyle = innerSpan.style
                var imgCurrentStyle = img.currentStyle
                
                outerSpan.id = img.id
                outerSpan.title = img.title
                outerSpan.className = img.className
                outerSpanStyle.backgroundImage = imgCurrentStyle.backgroundImage
                outerSpanStyle.borderWidth = imgCurrentStyle.borderWidth
                outerSpanStyle.borderStyle = imgCurrentStyle.borderStyle
                outerSpanStyle.borderColor = imgCurrentStyle.borderColor
                outerSpanStyle.display = "inline-block"
                outerSpanStyle.fontSize = "0"
                outerSpanStyle.verticalAlign = "middle"
                if (img.parentElement.href) outerSpanStyle.cursor = "hand"
                
                innerSpanStyle.width = "1px"
                innerSpanStyle.height = "1px"
                innerSpanStyle.display = "inline-block"
                innerSpanStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + funcEncodeURI(imgSrc) + "')"
                
                outerSpan.appendChild(innerSpan)
                img.parentNode.replaceChild(outerSpan, img)
            }
            else
            {
                i++
            }
        }
    }
}

if (navigator.appName == "Microsoft Internet Explorer")
{
    if (navigator.appVersion.substr(22, 1) == "6")
    {
        window.attachEvent("onload", PngFix)
    }
}

The major change here is that the unnecessary variable var version is no longer made, and only 1 character of the appVersion is compared (against "6"), instead of 3 (against "5.5" or "6.0"). This will probably only save a couple milliseconds, but it also simplifies the code, so I'd say it's still worth it. The documentation at the top is also updated. —Remember the dot ^(talk) 22:23, 13 October 2007 (UTC)

Might as well make it one statment (if javascript is smart enough not to evaluate the second part if the first part is false):

if (navigator.appName == "Microsoft Internet Explorer" && navigator.appVersion.substr(22, 1) == "6")
{
    window.attachEvent("onload", PngFix)
}

— Edokter • Talk • 22:52, 13 October 2007 (UTC)

That looks fine. —Remember the dot ^(talk) 01:20, 14 October 2007 (UTC)

Image maps

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)

Maybe this has been discussed before, or maybe I'm missing something ... would an base64 encoded version of the 1-px gif included in the JavaScript eliminate the server load issue? --Iamunknown 06:05, 21 October 2007 (UTC)

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)

After a little bit of online research... no, I don't think it would work.  :-\ --Iamunknown 16:18, 23 October 2007 (UTC)

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)

Option to collapse fundraising banner

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)

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)

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)

Or at least something less unprofessional and annoying, like an infinite popup cascade. —Cryptic 01:31, 23 October 2007 (UTC)

Dismiss button location

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)

That's a bit of a PITA to do .. but lemme give er a shot ... AmiDaniel (talk) 02:25, 23 October 2007 (UTC)

Done. AmiDaniel (talk) 02:33, 23 October 2007 (UTC)

A note.

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)

Hehe. But crashing the site is fun :) AmiDaniel (talk) 02:20, 23 October 2007 (UTC)

I moved the collapsing option to built-in instead of the common.js hack, so it'll be available on all sites once fully live. Collapsed version now shows just the slim progress meter, which might be a little nicer to look at, and gives you the option of re-showing it should you... for some reason... want to. :) --brion —Preceding comment was added at 03:34, 23 October 2007 (UTC)

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)

addOnloadHook(function() { document.getElementById('siteNotice').innerHTML="";});

Adding #siteNotice { display:none; } to your monobook.css will probably work better :) AmiDaniel (talk) 18:56, 23 October 2007 (UTC)

Thanks! I had yet to play with custom CSS - but now the hours I can waste :) Conrad.Irwin 19:15, 23 October 2007 (UTC)