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)