MediaWiki talk:Common.js/Archive 10
"Navframe" boxes no longer collapsing
I'm not sure what changes were made, but boxes no longer collapse automatically if there are more than two on a page - and there is no longer any spacing between them. Please see the bottom of the Paris article for an example. I'm using Safari on Mac os X 10.4.10 (intel). Cheers. THEPROMENADER 07:58, 27 August 2007 (UTC)
- I am semi-responsible for this, but, those need to be {{navbox}}es. I'll try to convert them. shudder! ←BenB4 18:32, 31 August 2007 (UTC)
code on diff pages
See this diff. Why isn't the code at the bottom properly handled, causing the message to appear at the top of the page? —Ruud 16:39, 28 August 2007 (UTC)
- No idea, but it's only on diffs on MediaWiki:Common.js. —METS501 (talk) 16:41, 28 August 2007 (UTC)
- Because on diffs the content for .js/.css pages is not made "safe". This particular case could be fixed e.g. by using
document.writeln('<'+'div style="position:absolute'…
. Btw, I would really recommend nice and easy-on-the-server option "Don't show page content below diffs" ∴ Alex Smotrov 17:06, 28 August 2007 (UTC)- Yeah, but the <code> tags are handeled correctly, and if you look at the source of the page you'll see that MediaWiki closes the <pre> tag. Why handle the these cases differently? —Ruud 17:14, 28 August 2007 (UTC)
- Let me put it this way: if you take the content of MediaWiki:Common.js and save it on some other (not .js/css) page, then you'll see the same mess on top, because the
<div style="position:absolute'
is interpreted as wikitext. Yes, another way to avoid this would be using <pre> Mediawiki tag (which is not the same as HTML <pre> tag). I'm not sure what you mean about <code> tags ∴ Alex Smotrov 17:45, 28 August 2007 (UTC)- Appart from <div>-tags Common.js also contains <code>-tags. Those are just outputted as preformatted text on the diff pages, not unescaped HTML like the <div>-tags are. Apparently some developer went to the trouble of handling the two differently, I however, fail to see why. —Ruud 21:41, 28 August 2007 (UTC)
- Let me put it this way: if you take the content of MediaWiki:Common.js and save it on some other (not .js/css) page, then you'll see the same mess on top, because the
- Yeah, but the <code> tags are handeled correctly, and if you look at the source of the page you'll see that MediaWiki closes the <pre> tag. Why handle the these cases differently? —Ruud 17:14, 28 August 2007 (UTC)
- Because on diffs the content for .js/.css pages is not made "safe". This particular case could be fixed e.g. by using
- This is a bug, insofar as any display hacks normally used on .js/.css pages should certainly be applied to diffs as well. Please file a report on bugzilla. —Ilmari Karonen (talk) 17:43, 3 September 2007 (UTC)
Add code to automatically set collabsible table's show/hide button color
{{editprotected}}
This code will fix a problem in many navigation boxes where the header color is dark and the font color is light. The show/hide button always is dark blue, which means that with the dark background it cannot be read. This line will modify the color of the link if and only if a different header text color is specified in the table header. If the color is not changed, then the link will remain blue.
Add this line:
ButtonLink.style.color = Tables[i].getElementsByTagName( "tr" )[0].getElementsByTagName( "th" )[0].style.color;
Directly BEFORE these lines in function createCollapseButtons():
ButtonLink.setAttribute( "id", "collapseButton" + tableIndex ); ButtonLink.setAttribute( "href", "javascript:XcollapseTable(" + tableIndex + ");" ); ButtonLink.appendChild( ButtonText );
Thanks, --CapitalR 02:36, 3 September 2007 (UTC)
Done. Cheers. --MZMcBride 02:42, 3 September 2007 (UTC)
Bug
The anonnotice still isn't working correctly. I just opened Safari to see what it looked like, and three of them showed up at once, with two directly on top of each other. Don't know what the issue is, but I uploaded a screenshot (see here). --MZMcBride 20:33, 3 September 2007 (UTC)
- Thats due to caching. It's expected and unavoidable when we change anon-notice methods. It will go away on its own.. or you can purge the page. This is explained several times on MediaWiki talk:Anonnotice--Gmaxwell 22:33, 3 September 2007 (UTC)
- Yeah, that seems to have fixed it. Cheers. --MZMcBride 23:12, 3 September 2007 (UTC)
Helping make the Internet suck
So thanks for all the cheese that's falling off my screen, and the fact that it's a new piece of cheese with every link I click. It would be nice if someone would turn down the cheese factor by at least three orders of magnitude. Did noone notice that <blink>blinking</blink> popups went out of fashion last century because of how distracting they are? Clearly not round here, they didn't. Then, if you're going to write your advert all over my screen, would you at least please have the consideration not to make it collide with article titles like Department for Business, Enterprise and Regulatory Reform? This fun-and-games with live Mediawiki pages is all well and good for logged-in users, but actually does affect people who are logged out. Like me, almost all the time I use Wikipedia, for example. Yes, yes, I know the pit of financial doom that the Foundation stares into all the time, but for the love of $deity, would someone come up with a scheme that is well thought-out, doesn't use up ever more real-estate with advertising, doesn't mess up formatting, doesn't require 30-odd edits to a super-important page to get right, doesn't distract me from reading articles and isn't instituted on the whim of a random admin. Oh, and would said random passing admins please test their new ideas somewhere else than on possibly the most-used page on the entire site? Thanks and appreciation in advance, Splash - tk 12:18, 3 September 2007 (UTC)
- Worse, it was showing a markup mistake (&bull with no semicolon) visible directly on the screen in Internet Explorer 6 for three hours (Firefox fixed the invalid markup to the correct markup automatically). I fixed that as soon as I logged on (and it was just chance that I happened to be using IE then, because I normally use Firefox), but 3 hours for a typo in anonnotice (which is almost as visible as sitenotice) is somewhat extreme. --ais523 14:02, 3 September 2007 (UTC)
- Yes, it's somewhat extreme, and I will take full responsibility for it. You can castigate me if you'd like, but please don't blame others who did nothing wrong for my mistake. I'm sorry if the display was quite screwed up for a while, and hope that everything is now working correctly. —METS501 (talk) 19:26, 3 September 2007 (UTC)
Splash, your tone could be more constructive here. Your complaint about Department for Business, Enterprise and Regulatory Reform was addressed over at MediaWiki_talk:Anonnotice#Clashes_with_not-unreasonably_long_titles as far as I can tell. Although perhaps I'm wrong because instead of following up about it there you're simply spreading your complaints all over in ForestFire fashion. Mets' minor errors here have been unfortunate, but he's going to be changing his process in the future. What important is that they were minor errors and that they've been resolved. It's good that Mets' took the time to take action to move us forward... bad that a little more care wasn't taken, but these are mistakes we can all learn from. There is no need to be rude about it. --Gmaxwell 22:42, 3 September 2007 (UTC)
- Very well said. I agree 100%. —METS501 (talk) 00:05, 4 September 2007 (UTC)
- No, the problem with long article titles is not adequately addressed. Try logging out. The advertising still collides with long titles. I brought it up here because here is where the problem is, it having moved here from elsewhere. One additional mistake we can learn from is not to cover the screen in spam. Appeals for donations now appear 3 - count them - times on every page and are accompanied by other intrusive advertising besides. (Here is also the source of the spam, now, so mentioning that elsewhere would seem odd at best). Splash - tk 09:03, 4 September 2007 (UTC)
- I agree, I just logged out and it was pretty bad, with long article names or narrow windows. Can we move that variable link down to the "From Wikipedia, the free encyclopedia" line, which appears to be free, unlike where it is now? ←BenB4 09:36, 4 September 2007 (UTC)
{{editprotected}} Specifically, please change:
position:absolute; z-index:100; right:100px; top:0px;
to:
position:absolute; z-index:100; right:100px; top:50px;
This will keep the collisions from occurring. Thank you. ←BenB4 09:49, 4 September 2007 (UTC)
- Oh, crap, that's where we're putting coordinates. Make the title area (but not the font) five pixels taller in CSS? ←BenB4 09:54, 4 September 2007 (UTC)
Coincidentally, has anyone tried to obtain a diff between two previous versions of any page whilst logged out lately? There being nothing in this week's signpost indicating related changes, and the intermediate radio buttons disappearing at the same time as the spam randomises itself, I'm feeling a little suspicious. It could be another .js page altogether, of course. Splash - tk 10:38, 4 September 2007 (UTC)
- Indeed, the radio buttons are not updating when selected. That's not in this file, though. I think it's diffcheck() in http://en.wikipedia.org/skins-1.5/common/wikibits.js?97 and I have no idea why logging out would make any difference. Someone should post this on WP:VPT. I
guess I willjust did. ←BenB4 11:23, 4 September 2007 (UTC)
- This was caused by the innerHTML rewriting code that mets put in with one of his changes. It looks like rewriting innerHTML causes pre-existing handles to dom objects inside to get invalidated. I confirmed that was the cause, and it's been removed. The message should be installed without rewriting the bodycontent div entirely. Until a fixed version has been tested the rotating lower notice should stay out. (upper notice isn't an issue) --Gmaxwell 14:03, 4 September 2007 (UTC)
- Much less sucky, and much improved article appearance. Constructive suggestion: instead of re-instating the (imo unimportant) spam on top of the article title, merge those messages into the rotating ones about funding. I suppose there is a desire somewhere to have more money messages than non-money messages, so wrap the random number selection up inside another one. The outer selection can be weighted as desired to indicate from which subset the message should be chosen; the message itself is selected from that subset by the existing random selection. Splash - tk 15:12, 4 September 2007 (UTC)
- To be clear, the article-title spam has been re-instated since I last got a cached page (there was no anonnotice spam briefly) which is mistaken and bad, and the Internet now sucks the more for it. At least it no longer stomps all over the actual content, though. Splash - tk 15:17, 4 September 2007 (UTC)
- This was caused by the innerHTML rewriting code that mets put in with one of his changes. It looks like rewriting innerHTML causes pre-existing handles to dom objects inside to get invalidated. I confirmed that was the cause, and it's been removed. The message should be installed without rewriting the bodycontent div entirely. Until a fixed version has been tested the rotating lower notice should stay out. (upper notice isn't an issue) --Gmaxwell 14:03, 4 September 2007 (UTC)
- On the subject of your 'constructive suggestions' ... if we were playing scrabble you would currently be suffering from a tremendous deficit of the letter s, p, a, and m. :) You can only call something crap that others think is a good idea so many times before your opinion starts to lose its weight. We are already abundantly aware that you think things like that donation notice are "spam", "advertisements", and any number of other nasty sounding things which are, no doubt, just the first step to completely selling out to Google or something like that.... It stopped being constructive about the 4th time you said it in the last two days. --Gmaxwell 15:34, 4 September 2007 (UTC)
- ...and the *notice.js probably stopped being effective after the 4th time that the readers came across them for similar reasons. Though, I am at a loss to explain how you extrapolated to selling out to Google. Splash - tk 15:49, 4 September 2007 (UTC)
- On the subject of your 'constructive suggestions' ... if we were playing scrabble you would currently be suffering from a tremendous deficit of the letter s, p, a, and m. :) You can only call something crap that others think is a good idea so many times before your opinion starts to lose its weight. We are already abundantly aware that you think things like that donation notice are "spam", "advertisements", and any number of other nasty sounding things which are, no doubt, just the first step to completely selling out to Google or something like that.... It stopped being constructive about the 4th time you said it in the last two days. --Gmaxwell 15:34, 4 September 2007 (UTC)
- I evaluated setting a cookie when a user sees or clicks a notice to prevent them from seeing another notice for a span of time, but we can't currently do this because even if the site itself will do nothing with the cookie as soon as it is set our squids will no longer cache the pages. If this happened with anons the site would instantly go hard-down. Once we can figure out how to do persistent client side storage that doesn't defeat caching we'll make these a little more smart.
- The donation notices do, however, have a huge impact on our income. ... and the Wikipedia educational material is important because there is constant misunderstanding of Wikipedia, the press is never going to get it right, and if we don't take some action we and the public will continue to suffer because of it.
- As far as the extrapolation goes, I was being a little mean.. Sorry. But it really isn't nice or fair to call the notices "spam", "advertisements", or "making the Internet suck".
- Your commentary on the technical points, and raising the issue of the anonnotice hitting the title after it was removed from the commonjs the first time has been very helpful and I'm sure it is appreciated by all. But to me it seems your approach with the philosophical issue of reader targeted messages is very negative and largely built on loaded language rather than things we can discuss and come to agreement on. --Gmaxwell 16:54, 4 September 2007 (UTC)
Well the diff buttons are fixed, but why would rewrting innerHTML invalidate logged-out users' handles but not logged in users'? ←BenB4 18:35, 4 September 2007 (UTC)
- The code in question only runs for logged out users, so nothing happens when you're logged in. Tra (Talk) 18:59, 4 September 2007 (UTC)
The reinstatement of this still clashed with article titles. It is to my mind completely unacceptable that it do so. The main difference between [1] and [2] appears to be the top:3px and font-size:100%, and so I've changed them to be the same as in mediawiki:anonnotice ie top:0px and font-size:80%. This has the effect of making the text look rather small, not sure why. But at least it no longer disrupts the title line(s).
Incidentally, why must there be so much formatting in these messages? There black, blue, grey, bold, italics, bullets and punctuation. dewiki just uses plain text and a link. Is that not enough? Splash - tk 12:27, 5 September 2007 (UTC)
- Everyone knows that Germans are staid and colorless. Celebrate the color of the English language!!!1! ←BenB4 22:16, 5 September 2007 (UTC)