Jump to content

Module talk:WikiProject banner/Archive 6

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is the current revision of this page, as edited by A smart kitten (talk | contribs) at 01:07, 4 January 2024 (mark category=no to prevent this page getting sorted into the wpbs duplicate banner maintenance category). The present address (URL) is a permanent link to this version.

(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)
Archive 1Archive 4Archive 5Archive 6Archive 7Archive 8Archive 10

Update directions & need help at Template:WPFOOD

When you added the default flag for importance, in both the main & B ck-list areas, and when you enabled the TF6-10 prompts for creating categories, are we supposed to have a yes/no for each TF 6-10 and have that default flag in the code on our WP templates? Do the instructions need to be updated on the /doc page? Reason for asking - don't know how to get {{WPFOOD}} to prompt for the missing Herbs & Spices categories. Thanks! --Funandtrvl (talk) 15:33, 11 May 2009 (UTC)

The TF_6-10 checks are only a tool for the convenience of editors constructing complicated banners. They don't actually work. They will prompt for the missing categories on the template page, but then they need to be "hooked". You won't get prompts on {{WPFOOD}} because they are using a custom mask. However I have created a version on Template:WikiProject Food and drink/sandbox which is prompting for them now. — Martin (MSGJ · talk) 15:47, 11 May 2009 (UTC)
Terrific, thank you for the help and explanation! --Funandtrvl (talk) 16:13, 11 May 2009 (UTC)

B checklist

On {{WPBeatles}}, the B checklist is implemented, but an article can still be assessed as B-Class even if b1–b6 are set to "no".

Is this a bug in that banner (in which case, how do I fix it?), or is it due to a recent change in WPBannerMeta (in which case the documentation should be updated)? Dendodge T\C 16:17, 18 May 2009 (UTC)

Yes, this is a Happy-melon error on your custom mask. Easily fixed though. — Martin (MSGJ · talk) 16:56, 18 May 2009 (UTC)
How do I fix it? Dendodge T\C 17:10, 18 May 2009 (UTC)
I fixed it. Also on WPGermany; I'm going to go through and check the others. :S Happymelon 18:04, 18 May 2009 (UTC)
Looks like we've all done it!! Even Martin, although that was to a sandbox, so it only counts as half... :D Happymelon 18:20, 18 May 2009 (UTC)
Umm, hope you didn't "fix" any others in this way! (Extra =) — Martin (MSGJ · talk) 19:35, 19 May 2009 (UTC)
I don't know what you're talking about... :S Happymelon 20:44, 19 May 2009 (UTC)

Questions

I've done a lot of work today to bring {{WikiProject Mississippi}} up to standards, including creating many sub pages this template required. Happy-melon converted it to WPBannerMeta on April 3rd, but many of the parameters weren't implemented during that conversion, hence my work today. Most of what I've done is via reading documentation and looking at other project templats. I do have some questions however and would appreciate any help..

It's all confusing to me but I think I've done a good job bringing the template from what it was to what it is now. Any further help fine tuning it would be most appreciated. - ALLSTRecho wuz here @ 02:20, 19 May 2009 (UTC)

It's looking good! I've made a few suggestions, feel free to revert them.
  • NA-Class articles will be in Category:NA-Class Mississippi articles, although as you have full quality scale enabled only those pages which don't come under any other class will be in here.
  • I don't understand. What subcategories do you want to use? I don't see any specifc coding relating to the attention category ...
— Martin (MSGJ · talk) 07:09, 19 May 2009 (UTC)
Excellent. I wasn't aware of Category:NA-Class Mississippi articles. I do my best to keep this project running. I wished I knew of way to know when new project related pages were created such as this one. I kept wondering why in the world Category:Non-article Mississippi pages kept getting deleted and showing as red link in the template's assessment documentation and I didn't know what to replace it with. lol I changed the images back in the template due to past discussion a wiki-lifetime ago (I think it was 2 years, maybe just under). But as I think about it, I don't guess it would matter now since all those that were a part of the discussion have seemingly disappeared. I of course find the Mississippi state flag offensive but that's another discussion for another place.
As for those subcats, I was just noticing like on Category:Nevada articles needing attention, they have no individual articles listed there.. just all subcats, whereas Category:Mississippi articles needing attention has the subcats and some stray individual articles.
Thanks for your help and looking at the template. - ALLSTRecho wuz here @ 07:24, 19 May 2009 (UTC)

The banner has the following parameter set:

|attention={{{attention|}}}

Since no category is defined, I assume the meta feeds Category:Foo articles needing attention by default, though this is not mentioned in the documentation. Happy Melon or Martin will know better than me, though. PC78 (talk) 09:49, 19 May 2009 (UTC)

Not mentioned? What's this then: "By default, they are categorised into Category:PROJECT articles needing attention." Navada articles needing attention will go into that category - it just so happens that there are none at the moment. — Martin (MSGJ · talk) 13:27, 19 May 2009 (UTC)
Ahh ok, Thanks Martin. - ALLSTRecho wuz here @ 20:14, 19 May 2009 (UTC)
Ah, well. Clearly I can't read then. :) PC78 (talk) 22:37, 19 May 2009 (UTC)

Another question

Would someone take a look at {{WikiProject Mississippi}} and fix whatever is causing it to call for {{WikiProject Mississippi/class}}. I only noticed this because when you're in edit mode for the template and scroll all the way down to the bottom of the page here it shows all templates being called for, it was red. Thanks. - ALLSTRecho wuz here @ 04:24, 21 May 2009 (UTC)

This is not an error, and happens on every banner. It's because the meta checks that page in case there is a custom class mask in place. — Martin (MSGJ · talk) 07:20, 21 May 2009 (UTC)
OK, thank you for explaining it to me. - ALLSTRecho wuz here @ 07:26, 21 May 2009 (UTC)

Hmn, we could fix this by adding the surrounding #ifexist check, as we do on the main banner. How close to the limit did you say you were with the category checks, Martin? Happymelon 15:00, 21 May 2009 (UTC)

Some feedback would be appreciated. Headbomb {ταλκκοντριβς – WP Physics} 07:43, 23 May 2009 (UTC)

Hide importance row on non-articles

Another request born of MSGJ's and my efforts to convert {{WikiProject Anime and manga}} to use WPBM; currently WP:ANIME's banner does not display the importance row on non-articles (where importance is automatically set equal to NA), whereas WPBM does. Once again, MSGJ has said he agrees with how WP:ANIME's banner does it, and suggested I raise the issue here. Thoughts? ダイノガイ?!」(Dinoguy1000) 19:08, 12 May 2009 (UTC)

Ha, you've got your work cut out trying to persuade that lot to convert :) I agree that it's a bit pointless displaying an NA-importance, athough we should to continue categorising in those categories. — Martin (MSGJ · talk) 14:00, 13 May 2009 (UTC)
But if a page was manually rated with an importance rating (even if it were NA), then that should be displayed. Essentially you want to hide the importance scale (but still categorise) if the importance rating is "unspecified". That's much trickier than just hiding it in certain namespaces(which is trivial). Happymelon 14:34, 13 May 2009 (UTC)
Hmm, I was thinking about hiding it whenever the importance was NA ... (I don't think whether NA is actually specified should make any difference?). This would have to be checked on /importancescale itself, after the importance is passed through the mask. — Martin (MSGJ · talk) 15:53, 13 May 2009 (UTC)
Actually, I was talking specifically about hiding in certain namespaces (everything but article talk), but showing in those namespaces if (for whatever reason) the importance has been specified. ダイノガイ?!」(Dinoguy1000) 20:15, 13 May 2009 (UTC)
Isn't that the same as what I said? (Unless you put NA importance on an article, which is silly ...) — Martin (MSGJ · talk) 20:24, 13 May 2009 (UTC)
Cough redirects cough. :D Happymelon 21:14, 13 May 2009 (UTC)
And disambiguation pages... Headbomb {ταλκκοντριβς – WP Physics} 04:49, 21 May 2009 (UTC)
Sure, well these are all non-articles anyway. — Martin (MSGJ · talk) 07:22, 21 May 2009 (UTC)

Well I propose we trial it for a while, and continue to seek comments on it. I don't expect it to be controversial because it is just hiding a row of information which is basically irrelevant anyway. There is some proposed code in the sandbox awaiting a check. — Martin (MSGJ · talk) 10:02, 21 May 2009 (UTC)

I think we can do it like this, setting /importance to return "NA" when the rating is explicitly set to NA, and "nA" when it's set by default. Then we can make the distinction I wanted, and only hide importance ratings when they're not explicitly set. I've had a look through the hooks; I think the only place where it'll have an effect is /hooks/qualimpintersect, where I've already armoured the parameters against the change. We'll need to use ucfirst: in the same way for displaying the importance rating in the header, above; that's no big deal. Thoughts? Happymelon 14:54, 21 May 2009 (UTC)
Well the physics projects sets its importance rating to NA-class manually/by bot. This is sort of a paranoid protection against people who might be tempted to assess templates, categories, etc... That being said, there is nothing lost by not displaying the "NA", IMO. Headbomb {ταλκκοντριβς – WP Physics} 15:09, 21 May 2009 (UTC)
I really can't see why we would want to distinguish between automatic NA and imposed NA. — Martin (MSGJ · talk) 15:11, 21 May 2009 (UTC)

I have implemented the simplified version. Yes, there are thousands of category talk pages which are bot-created with class=NA/Cat, importance=NA, and the reason for this I suppose, is that the previous version of the banners did not automatically classify as NA. Therefore I see no reason to treat these any differently. — Martin (MSGJ · talk) 13:02, 26 May 2009 (UTC)

Meh :D It's not exactly an earth-shattering change... Happymelon 14:07, 26 May 2009 (UTC)

New hook for custom importance scales

There were more and more projects wanting to use weird and wonderful importance ratings, so I have built a hook /customimportance for this purpose. Just to let you all know. — Martin (MSGJ · talk) 12:31, 26 May 2009 (UTC)

Many thanks for that ! SyG (talk) 09:02, 28 May 2009 (UTC)

Can one of you guys have a look at this banner? The "to-do" list is not collapsing on article talk pages (see Talk:2011 World Amateur Boxing Championships), which I'm guessing is something to do with the recent changes to NOTES & C_NOTES. Cheers! PC78 (talk) 11:09, 29 May 2009 (UTC)

I think it was an error on their todo list Template:WPB Announcements. A table was opened but not closed. I've removed the table entirely from that page, should be fixed. — Martin (MSGJ · talk) 11:30, 29 May 2009 (UTC)
You sure? I'm still seeing the uncollapsed list on the talk page I linked above. PC78 (talk) 11:49, 29 May 2009 (UTC)
Try purging? — Martin (MSGJ · talk) 11:58, 29 May 2009 (UTC)
Interesting. This looks fine on Mozilla, but does not collapse on IE. — Martin (MSGJ · talk) 12:00, 29 May 2009 (UTC)

This seems to affect all transclusions of the to-do hook in which the class parameter is not defined. Specifying the class seems to fix it! Otherwise the [show] button doesn't even appear. Hmm. — Martin (MSGJ · talk) 12:09, 29 May 2009 (UTC)

Funnily enough the code for the new collapsed section contains a comment "TO FIX IE", which suggests that H-M was expecting something to go wrong here. I'll leave it for him to work out. There's nothing wrong with the todo hook as far I can see. — Martin (MSGJ · talk) 12:23, 29 May 2009 (UTC)
and there also seems to be an extra td in the same line. — Martin (MSGJ · talk) 12:31, 29 May 2009 (UTC)
Do you mean whenever |TODO_STLE= is not set? Happymelon 13:37, 29 May 2009 (UTC)
No! I mean this one on the core. — Martin (MSGJ · talk) 14:16, 29 May 2009 (UTC)
Anyway, that didn't fix the issue. We've still got banners
  • with sections which should be collapsed but no show/hide button appearing
  • with collapsed sections which are uncollapsed by default (and showing the "hide" button)
Please install internet explorer, then you can see it! — Martin (MSGJ · talk) 14:22, 29 May 2009 (UTC)
I was referring to your 12:09 post, "in which the class paramter is not defined"; seems very bizzarre otherwise. Although I see where you're coming from; the presence of the |class= parameter does affect the structure of the header row.
Although I do tend to forget, I do still have IE... do remind me of that fact from time to time :D I see the issue on WPKorea, although I have no idea off the top of my head what's going on there... I'll have a poke. Happymelon 14:53, 29 May 2009 (UTC)
Sorry for not being clear. I was talking about the class parameter of the template. Setting it causes the table to collapse as normal on IE. — Martin (MSGJ · talk) 15:00, 29 May 2009 (UTC)
 Fixed. Stupid piece of crap that calls itself a browser... :D Happymelon 16:23, 29 May 2009 (UTC)
Don't think it is ... This is still a mess on IE. — Martin (MSGJ · talk) 17:43, 29 May 2009 (UTC)
 Fixed ??? Happymelon 11:05, 31 May 2009 (UTC)

The show/hide on the Korea banner seems to be broken again. PC78 (talk) 13:29, 29 May 2009 (UTC)

Broken how? Doesn't collapse in IE? Or is it a different issue? Happymelon 13:37, 29 May 2009 (UTC)
All related to the same problem I think. — Martin (MSGJ · talk) 14:22, 29 May 2009 (UTC)
Well this one's not fixed, so perhaps not? Happymelon 16:23, 29 May 2009 (UTC)
It collapses correctly when I copy the content to Special:ExpandTemplates. That's just taking the piss :D Happymelon 16:30, 29 May 2009 (UTC)

Well done chaps, it all looks good to me in both IE and FF. :) PC78 (talk) 12:27, 30 May 2009 (UTC)

Martin's example above is still broken for me on IE7/Vista. Is it for you? Happymelon 10:42, 31 May 2009 (UTC)
Ok, I think I might have fixed it; but I have no faith in it to stay fixed any more, so do let me know if you spot anything else not collapsing when it should... Happymelon 11:05, 31 May 2009 (UTC)
Just to confirm that it's all looking good now, and any explanation you can offer as to how you fixed it and what causes this error would be helpful, just in case you are not around next time it happens! Also, do we know why it only happened with unassessed articles? — Martin (MSGJ · talk) 18:41, 31 May 2009 (UTC)

I'm not entirely convinced that it's fixed, what with the ongoing discusison at TT:WikiProjectBannerShell, but that seems to be tangentially connected.

Ok, whistlestop tour of WPBM header structure... The challenge in redesigning the header was to get a reliable 50% division in the header row, whilst still having the show/hide button float correctly to the right. The show/hide JavaScript adds the button to the first <th> cell it encounters, so splitting the header row up into multiple cells would normally result in the button appearing midway across the row. There's also the need to have more than one cell in the row, or the 100% width declaration in the mbox-text class doesn't properly push the box out to its maximum allowed width. Our infamous width issue is a myserious bug whereby this feature also doesn't work when the cell with mbox-text class has colspan=3, but that's another issue :D

The very first implementation just had the project link, taskforces and assessment all together as freeflowing text in one th cell, with a {{td}} providing the second cell (the outer table of WPBM actually only has two rows; all the contents of the banner proper are inside a second nested table). However this was pretty hideous, and I had for a long time on the todo list "fix header alignment/linewrapping/general awfulness"... The second generation still had all the content in one cell, but everything other than the collapse button was inside another nested table. However, this was a pain because the nested table couldn't be given 100% width (or it linewrapped to underneath the show/hide button), which meant trying to specify fixed widths to the cells inside failed horribly on several browsers; this was the Safari and Chrome bug we had a while back.

The third and most recent implementation throws all of that out the window. I was looking at the code and realised that all this time, the show/hide button hadn't been applying to the first cell in the row; the whole way through we'd had a {{td}} to get the mbox magic. But because the cell generated by that template is a <td> and not a <th>, it was being ignored by the JavaScript. So this generation applies that principle to the header. Now there are two full-width cells in the header row (plus a tiny {{td}}), but the first one (which contains the project link and taskforces) is not a th, it's a td with font-weight:bold. Only the second one (with the assessment rating) is a th. That's the case if quality assessments are used by the banner, anyway; otherwise the header is still one th with colspan=2.

Now to the bug. With the way we show assessments in the collapsed banner (ie not showing "(Rated ???-Class)") the th in the header row is empty if |class= is not set. The CollapsibleTables JavaScript coughs and dies on IE when it's asked to add a show/hide button to an empty th, for some unknown reason. We realised this over at Common.js, and the fix is to ensure that the empty th is made not empty, by adding a hidden span or something. I killed two birds with one stone here on WPBM by filling the hidden span with useful machine-readable metadata, with which one can do interesting things with JavaScript. But I realised a few days ago (when one of said scripts broke) that the position meant that the metadata was only being included if the project used a quality scale! So I moved it such that it would always be available. Which of course left the cell empty again (serves me right for removing the "this fixes IE" comment), and in came the bug reports above :D I recognised the bug symptoms and reinserted the fix, but with a crucial difference: the span I added had no actual content other than an HTML comment. And as I've found through experimentation today... Tidy eats empty spans, so it wasn't making it into the final output. I'm not sure why the problem went away on the testcases I checked after adding the empty span, but that was my over-optimistic 16:23 post above. Adding an nbsp into the span forces it to display in all its invisible glory, and fixes the problem properly.

Happymelon 19:24, 31 May 2009 (UTC)

Wow, thanks. This may take some digesting ... — Martin (MSGJ · talk) 21:00, 31 May 2009 (UTC)
So empty table cells are always problematic? Or just ones in the header with the show/hide button? — Martin (MSGJ · talk) 21:01, 31 May 2009 (UTC)
Only when the CollapsibleTables JS tries to stick a show/hide button in them. Happymelon 08:50, 1 June 2009 (UTC)

Bad assignment to unassessed

Changes over the last day (or so) are now meaning that numbers of our projects (WP:Novels) articles are being assigned to Unassessed see "Category:Unassessed Fantasy fiction articles" as an example. all of these are assessed, at least as far as the "class" is concerned. This should not be happening. Please fix urgently. :: Kevinalewis : (Talk Page)/(Desk) 13:31, 31 May 2009 (UTC)

In {{WPBannerMeta/hooks/taskforces/core}}, the QUALITY parameter is wrong and class is not been passed through for tf 3 & tf 4. -- WOSlinker (talk) 13:57, 31 May 2009 (UTC)
So is anyone able to sort this out for us then as I don't understand this new template code and I am not an admin and have now access anyway. :: Kevinalewis : (Talk Page)/(Desk) 15:02, 31 May 2009 (UTC)
I've put in an {{editprotected}} request on Template talk:WPBannerMeta/hooks/taskforces/core -- WOSlinker (talk) 15:16, 31 May 2009 (UTC)

 Fixed now. Sorry about this; I'm really not sure how that crept in. — Martin (MSGJ · talk) 16:31, 31 May 2009 (UTC)

Partly because I assumed they were carbon-copies and only checked that the numbers were incremented correctly; I completely missed that error, so my apologies too. Happymelon 18:32, 31 May 2009 (UTC)

I wanted to know if the following is possible?

I was thinking, instead of having a photo for the dermatology icon (as it is hard to find a great derm photo that scales down nicely) could we have that space read something like "DERM" inside a colored box? Similar to how the class and importance scale information is displayed?

Is this functionality available, and, if not, could someone add it? ---kilbad (talk) 20:50, 31 May 2009 (UTC)

You would have to make an image of the text, if that makes sense. — Martin (MSGJ · talk) 20:59, 31 May 2009 (UTC)
Like it? File:DERM.gif No, well, probably not. But there are some nice tools out there ... — Martin (MSGJ · talk) 21:46, 31 May 2009 (UTC)
Cleaning up the image inclusion syntax is on the todo list; I'm looking at {{image}}, which has nice features we could use. You could use that to include text instead of images, but only if the text is linked (ie, the first character is "["). That's better than nothing, though. Happymelon 09:13, 1 June 2009 (UTC)

Requesting a sanity-check on applying this diff to Template:WPBannerMeta/importancescale. Thanks, — Martin (MSGJ · talk) 20:50, 7 May 2009 (UTC)

That looks sane to me. Mind you... :D Happymelon 21:50, 7 May 2009 (UTC)
Ha ha.  Done. — Martin (MSGJ · talk) 21:56, 7 May 2009 (UTC)

Requesting check for applying this diff to Template:WPBannerMeta. As {{WPBannerMeta/importance}} interprets ¬ the same as blank, this shouldn't have any effect at this stage. My idea eventually is to deprecate IMPORTANCE_SCALE. But before that can happen, we need to track which banners pass importance but don't use importance. Thanks, — Martin (MSGJ · talk) 21:38, 10 May 2009 (UTC)

Yes, that should be ok. Happymelon 22:58, 10 May 2009 (UTC)
I think I'm about ready to replace {{#if:{{{IMPORTANCE_SCALE|}}}| with {{#ifeq:{{{importance|}}}|¬||. The job queue seems to have been lightening fast recently (I populated category of 2000 in less than 2 mins a couple of days ago) so I'm reasonably sure that there are no more banners which pass importance and don't use the importance scale. I might look at doing something similar with taskforces and hooks later. (Think I've finally got the hang of ¬, woohoo!) — Martin (MSGJ · talk) 13:55, 13 May 2009 (UTC)
 Done, seems to be working. — Martin (MSGJ · talk) 21:08, 13 May 2009 (UTC)

I think we're ready to roll this out to the 5 main taskforces as well now. Does anyone have any concerns about this? In a nutshell, the switch for the importance scale will be whether or not an importance parameter is passed or not, and the IMPORTANCE_SCALE parameter becomes redundant. — Martin (MSGJ · talk) 10:04, 15 May 2009 (UTC)

As long as we're happy that there aren't any parameters being passed when they shouldn't be, and so we're not going to accidentally activate any importance scales. Happymelon 10:18, 15 May 2009 (UTC)
Yes, I'm happy ;) — Martin (MSGJ · talk) 11:40, 15 May 2009 (UTC)
��Done, now for the taskforce hook ... — Martin (MSGJ · talk) 12:26, 18 May 2009 (UTC)

Request for a code-check on Template:WPBannerMeta/hooks/taskforces/sandbox please. Main changes/benefits are:

  • Removal of duplication of code for live and templatepage versions.
  • Avoidance of calling {{WPBannerMeta/class}} 10 times through the use of a core.
  • Deprecation of the IMPORTANCE parameters, as per the main template.

Thanks, — Martin (MSGJ · talk) 17:46, 29 May 2009 (UTC)

Looks good to me, my edit was just code layout tweaks. I'm sure it could be simplified/optimised further (the double parsers in the core look like a ripe target), but it'll only make the code less readable. Happymelon 18:05, 29 May 2009 (UTC)
Forgot to say that it's implemented on Template:ChristianityWikiProject/sandbox, and I can't see any problems either. I thought for a long time about how to do this efficiently, but if you can do it more simply then great. — Martin (MSGJ · talk) 18:17, 29 May 2009 (UTC)
I didn't say I could do it more simply: if I were forced to optimise it further, I'd probably do something wierd like move the yesno templates in the main hook to the parameter names, thereby recovering the defined/undefined nature of the trigger parameters; and use that to remove the double parsers in the core. But that's just stupid :D Happymelon 18:44, 29 May 2009 (UTC)

 Done, and error fixed thanks to WOS. I think we can now remove the calls to the importance mask from Template:WPBannerMeta/taskforce now as importance is pre-normalised. — Martin (MSGJ · talk) 17:16, 31 May 2009 (UTC)

Yeah, /core and /hooks/taskforces are the only valid entry points; anything else that breaks is because someone's not doing it properly. Happymelon 08:49, 1 June 2009 (UTC)
 Done. Fixed a couple of small errors as well: a switch that looked as though it should be an ifeq, and a | missing in the MAIN_CAT conditional. — Martin (MSGJ · talk) 14:22, 1 June 2009 (UTC)
That #switch looks like it's (or should be) a class test; is there any reason we can't switch based on class rather than namespace? And avoid "this article..." on redirects, dabs, etc? Happymelon 14:51, 1 June 2009 (UTC)
I've been thinking about making a template to show something more descriptive here. Such as file, disambiguation page, etc. — Martin (MSGJ · talk) 10:27, 3 June 2009 (UTC)

WPBannerMeta/taskforce

The last edit to WPBannerMeta/taskforce added an extra | into the #if for MAIN_CAT, so now the taskforce MAIN_CATs are only shown if category=no. Can it be fixed. Thanks -- WOSlinker (talk) 12:27, 3 June 2009 (UTC)

Oops, what was I thinking?  Fixed — Martin (MSGJ · talk) 13:01, 3 June 2009 (UTC)

Standard or not?

Is it recommended to use WPBannerMeta in project templates isntead of the own project code? Starting this thread due to this discussion. SkyBonTalk\Contributions 14:56, 4 June 2009 (UTC)

There's certainly no mad axeman waiting outside to butcher a project that doesn't use it, but I certainly would recommend it (you're probably in the wrong place if you were expecting a different answer :D). I can usually come along and write a list of at least ten things that are 'wrong' with any particular banner coding-wise, and people usually now have a hell of a time to find something that WPBM can't do (or can't be made to do, as long as the thing actually makes sense in the first place). Happymelon 15:28, 4 June 2009 (UTC)

Alternate B-Class checklist display

WP:ANIME's banner, which uses the B-Class checklist, currently has it display in a collapsible brown box in the same cell as the quality assessment description (the actual code for the box can be found here, and there's a sandbox here, if anyone feels like playing with it). This is quite different from WPBM's current display method of creating another row specifically for the checklist, and results in a much more compact presentation. MSGJ has stated that he would probably support the addition of similar functionality to WPBM if the color was changed, but I don't have much of a head for color issues. =) Thoughts? ダイノガイ?!」(Dinoguy1000) 19:05, 12 May 2009 (UTC)

Style-wise, that looks absolutely vile, and I think I prefer the separate rows; it's clearer and I like the separate icon and B-class colour. I think WPBM's style draws better attention to the checklist, which can be an easy source of confusion ("Oi, I said B-Class, stupid banner! Why does it still say C-Class? Mummeee!!!..."). The Anime version is too easily overlooked, which is IMO a Bad Thing. Happymelon 14:38, 13 May 2009 (UTC)
I agree that it's not perfect currently. But there is one advantage: the checklist is actually next to the class rather than interrupted by the importance rating. That does seem more logical. — Martin (MSGJ · talk) 15:55, 13 May 2009 (UTC)
Yes, that's true, and it would make the two cells blend together more when the article is B-Class. We could do that trivially though, just moving things around in WPBM/core. Happymelon 17:12, 13 May 2009 (UTC)
As I said originally, you're free to play with the styles if you'd like. Actually, I'd be interested in seeing what you might come up with for it. =) I think separate rows or a subbox is a matter of personal taste, and I'm probably biased towards the latter myself simply because I'm so used to it. ダイノガイ?!」(Dinoguy1000) 20:17, 13 May 2009 (UTC)

 Done I've moved it up underneath the class rating. Happymelon 14:11, 26 May 2009 (UTC)

I think we could experiment with having it in the same row. — Martin (MSGJ · talk) 21:02, 31 May 2009 (UTC)
But then what would we do with your beautiful B-Checklist icon!?! :D Happymelon 08:46, 1 June 2009 (UTC)
I know! It would be a tragedy if we didn't use it ... — Martin (MSGJ · talk) 10:25, 3 June 2009 (UTC)

Ow, yuck. The checklist looks really rubbish on Google Chrome. See File:Bchecklist on Google Chrome.jpg. Look where the show/hide buttons are on Germany and Poland. Can we do something about this please? — Martin (MSGJ · talk) 09:05, 4 June 2009 (UTC)

WTF? After so many appearances, the "oh look the mbox magic isn't working and pushing the tables out to maximum width" bug doesn't surprise me any more. But that's actually linewrapping instead of pushing out!!! Can you take another with #bodyContent * {border:1px solid red!important;} in your CSS? I wonder whether the issue is actually the {{td}}, which is on the right in the bchecklist for some reason, is actually expanding rather than the table shrinking. Either way, it's a pain, and nasty as you say. Happymelon 15:38, 4 June 2009 (UTC)
File:Bchecklist on Google Chrome with red lines.jpg. This is Talk:Judaism by the way. — Martin (MSGJ · talk) 12:47, 5 June 2009 (UTC)
File:Short main text on Chrome.jpg

And another one for you. This is Template:WikiProject Anatomy/sandbox on Chrome! — Martin (MSGJ · talk) 08:33, 12 June 2009 (UTC)

So basically, Chrome is totally screwed... :P Happymelon 09:23, 12 June 2009 (UTC)
Are they any better now? I've added explicit width declarations to the inner tables; might be the same issue we had with the second generation of the header... Happymelon 10:12, 12 June 2009 (UTC)
Yes, both  Fixed on Chrome, thanks. — Martin (MSGJ · talk) 15:09, 12 June 2009 (UTC)

Displaying B-checklist on Start-Class articles

Would there be any opposition to displaying the B-checklist when the class is Start, even when none of the parameters are defined? The reason is that a few banners using a custom mask, will classify as Start unless a certain number of criteria are checked. Therefore you could have the situation where class is defined as B or C, but it comes out as Start without any explanation. — Martin (MSGJ · talk) 13:25, 18 May 2009 (UTC)

You can just pass one or more of the b-checklist parameters as |b1={{{b1|?}}}:
Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details.
WikiProject iconCountries Start‑class
WikiProject iconThis article is within the scope of WikiProject Countries, a collaborative effort to improve the coverage of countries on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
StartThis article has been rated as Start-class on Wikipedia's content assessment scale.
WikiProject Countries to-do list:

Here are some tasks awaiting attention:
Only problem with that is that the "please fill in the checklist" prompt no longer appears. But better to fix that, IMO. Happymelon 14:56, 18 May 2009 (UTC)

I think the problem is really with those banners which use criterion marking for C-class: either the meta-banner allows for that, or the projects should be reminded of the problems that their current system causes. I would propose the opposite solution to that which Martin suggests: that the B-checklist should only be displayed if the article has been rated above C-class or if at least one of the parameters has been checked. At the moment, we are claiming that "This article has been checked against the following criteria" when, in most cases, it hasn't been formally checked at all (all the criteria are marked as "?"). Physchim62 (talk) 15:04, 18 May 2009 (UTC)

I don't fully understand what you're saying here; "criterion marking"?? The banner says, if no parameters have been checked the banner says "has not yet been checked":
Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details.
WikiProject iconCountries C‑class
WikiProject iconThis article is within the scope of WikiProject Countries, a collaborative effort to improve the coverage of countries on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
CThis article has been rated as C-class on Wikipedia's content assessment scale.
WikiProject Countries to-do list:

Here are some tasks awaiting attention:
The difference in the banner above is another thing that needs to be tweaked; both are a result of too-late normalisation. Is there any reason why we can't normalise the B-Checklist parameters in WPBM proper? Does this cover all bases?
{{#switch: {{lc:{{{b1|¬}}}}}
  |yes|y|1|pass = y
  |no|n|0|fail  = n
  |na|n/a       = x
  |¬            = ¬
  |<yes/no>
  |yes/no
  |             = <!--NULL-->
  |?|#default   = ?
}}
We can use ¬ and just get projects to not pass |b6= to only use the 5-point scale, deprecating the |b6=unused option. How widely are the "not applicable" and "invalid parameter" options used (is it used?)?? With some proper normalisation in place, we can make these things consistent. But there's still the distinction between "not yet set", which gives the null string, and "not yet assessed", which gives "?". Thoughts? Happymelon 16:01, 18 May 2009 (UTC)
  • Support using b6=¬ instead of b6=unused.
  • Also would support b1!=¬ instead of B_CHECKLIST=yes.
  • I think the n/a option and invalid warning are useful; they probably should be documented somewhere though ...
  • No I don't think there is any benefit in normalising them on WPBM because the class mask would have to normalise again anyway for the use of hooks.
— Martin (MSGJ · talk) 17:17, 18 May 2009 (UTC)
That's a good point about the hooks/ I guess it needs to be a deeper check... I still think it could do with being normalised somewhere though. Also support deprecating B_CHECKLIST... although that might cause a few tantrums with the people who fought to get it passed to the custom masks!! Happymelon 18:23, 18 May 2009 (UTC)

I'm not sure about your proposed solution. Changing b1={{{b1|}}} to b1={{{b1|?}}} would then permanently display the checklist on all stubs as well, and I don't think this is desired. Do you feel that displaying it on all start-class articles is not a good idea? — Martin (MSGJ · talk) 12:55, 26 May 2009 (UTC)

It would at the moment, you're right. I think people should have the option, but I don't think it's a good idea to make it the default. And there's generally a lot of cleanup we can do here. Perhaps what we need is criteria like this:
  • FA/A/GA - never
  • B/C - always
  • Start - if any criteria are set
  • Stub - if more than X criteria are set
Where X is a number more than 1. Then projects could do what I said to trigger it for Start-Class, or set them all to the ? default to get it for Stub-Class as well if they really want. Thoughts? Happymelon 14:06, 26 May 2009 (UTC)
lens Review Ok, I have just such a setup in the sandbox. Have a look/play and tell me what you think. Happymelon 17:53, 29 May 2009 (UTC)
Comments:
  1. It seems to achieve what you want, and I like the solution whereby if any parameter is filled then it will be displayed on Start-Class. However I might argue that you have significantly complicated the template for the very slim possibility that a project will want the checklist displayed on stubs. By all means, if a project comes and asks for it, then we can do it, but until that unlikely day, maybe you can consider leaving this out? (Sorry if that means the fantastic logic tests will not be as impressive!)
  2. <yes/no> seems to be treated as "yes", although this seems to be the case currently as well! Maybe we can subtemplate the mask for these parameters?
  3. /criterion will need to be edited to accept "x" and "?".
  4. The method for opting out of b6 doesn't seem to work. Not sure why. See Template:WikiProject Former countries/testcases.  Fixed
— Martin (MSGJ · talk) 10:57, 30 May 2009 (UTC)
Thanks for the review.
  1. I don't actually think that removing the check on Stub-Class will actually simplify the logic very much; am I missing something? It seems to me that it just means moving Stub in with FA/A/GA at the top. When Brion finally scaps again (we're 2500 code revisions out of date now :( we will finally get native string functions (Rob Rohde added them to ParserFunctions in r50997, yay for Rob!), which will make the second part a simple switch too (I didn't want to use our own evil {{str len}} cos it's evil as we all know). Do you have a suggestion for how it can be simplified by removing Stub?
  2. Are you sure? It looks like it's treated as "" to me.
  3.  Done Actually it only needed "x"; but I added "¬" for completeness too (not that it should ever be exposed to them).
Happymelon 10:40, 31 May 2009 (UTC)
  1. Well maybe it wouldn't simplify it much. I just think you are implementing something which is never likely to be wanted. If you think it might really be useful for a project then go ahead.
  2. My mistake due to strange normalisation on Template:WikiProject Former countries/class.
  3. On /core, shouldn't "?" be treated as "yes/no" rather than the default which triggers the parameter error.
— Martin (MSGJ · talk) 11:00, 31 May 2009 (UTC)
1) I can see it being useful; although it's one of those things that as you say is probably going to be used never to rarely. But I honestly don't see how we can regain simplicity simply by not including it, so we might as well.
3) I don't think the orange checkmark is actually reachable any more; |b1=cheesecake is normalised to |b1=? now. Is that a problem?
Happymelon 11:22, 31 May 2009 (UTC)
Hmmm. Well, either we have a separate value for "errors", or we count yes/no towards the trigger for displaying the checklist ... — Martin (MSGJ · talk) 21:04, 31 May 2009 (UTC)
That is, the only value that should not count towards displaying the checklist is ""? I can see the logic in that. Happymelon 21:11, 31 May 2009 (UTC)
Not only yes/no, but any defined value (even blank) should count towards the trigger, otherwise the checklist may disappear! (See below) Of course this wouldn't be possible without changing all banners to pass {{{b1|¬}}} etc. — Martin (MSGJ · talk) 06:15, 1 June 2009 (UTC)

Scenario

  1. Current proposal is implemented
  2. WikiProject decides to display b-checklist on start-class articles
  3. Editor sees checklist on a start-class article and defines blank parameters b1-6 in preparation for improving the article to b-class
  4. "?" is no longer passed from project banner to WPBM
  5. B-checklist disappears
  6. Editor confused

— Martin (MSGJ · talk) 06:13, 1 June 2009 (UTC)

This is a good point, but the implementation is a bit trickier. Because you remember we wanted |b6=¬ to signify "unused"?!? And potentially, of course, we could do the same with the other b parameters and deprecate B_CHECKLIST. So we can't use ¬ to signify "used by the banner but not set on instance" in this case, because we wanted it to mean "not passed by the banner". We could pick another character, of course, but that might be confusing. I'm not sure how best to proceed. Happymelon 08:45, 1 June 2009 (UTC)
Temporary solution while we continue to discuss this: a simple trick which will un-break AVIATION and not affect any others (I think). Display the B-checklist on start-class articles if and only if the following returns "Start". — Martin (MSGJ · talk) 08:58, 1 June 2009 (UTC)
{{WPBannerMeta/class|class=B|BCHK=yes|b1=no|b2=no|b3=no|b4=no|b5=no|b6=no}}
Er... maybe I'm misreading this, but won't that just return "B" if the project isn't using a B-Class checklist (unreachable since /bchecklist won't be called in that case) and "Start" if it is? Ergo, checklist will always display on Start-Class articles? Am I missing a trick? Happymelon 09:09, 1 June 2009 (UTC)
Most class masks that use the checklist will return C. There is only aviation and (if they ever convert) Anime which will auto-demote to Start-class. And these are the ones which need the checklist displayed on start-class. — Martin (MSGJ · talk) 09:12, 1 June 2009 (UTC)
I must be getting old... :D WPAviation is the exception, not the rule. I'm going to have to go go live in a desert at this rate... :D
Actually, that's quite nice; it also cleans up the scenario I've just thought of where a project uses the B-checklist but not C-Class (a-la Milhist), which exhibits the same behaviour. Happymelon 18:44, 1 June 2009 (UTC)
I did put some code in the /sandbox yesterday which you might have missed. It may or may not achieve what we want ... we need to decide what kinds of parameter input should count towards the display trigger. — Martin (MSGJ · talk) 21:51, 2 June 2009 (UTC)
I like the edit summary :D What that snippet does is switch us from "we always display the checklist on C-Class" to "we always display the checklist on the class(es) articles are downgraded to", which could include start in several situations. That resolves the original issue, but not the scenario that's the title of this subsection. I guess the question is, are we treating this as a redesign for its own sake, or as a fix for a specific bug? Happymelon 23:00, 2 June 2009 (UTC)

Well, I am trying to fix my original issue (and I fix this does fix the scenario above as well) as well as incorporating any other improvements along the way (such as b6!=¬ instead of b6=unused). — Martin (MSGJ · talk) 10:24, 3 June 2009 (UTC)

I've implemented this small fix for now. — Martin (MSGJ · talk) 13:05, 8 June 2009 (UTC)
Ok, where are we with this? I see your {{WPBannerMeta/bchecklist/b}}; is that in use? Happymelon 11:12, 12 June 2009 (UTC)
I just made the fix for my original issue, which is working quite nicely I think. The b mask is not in use yet. And we haven't changed the implementation of the 5 point checklist yet. — Martin (MSGJ · talk) 15:12, 12 June 2009 (UTC)

Displaying the importance in the collapsed version...

Having to "uncollapse" the banners to see the importance ratings is very annoying. Placing (A-Class, High-Imp) instead of only (A-Class) would fix this. Likewise, when unassessed, the collapsed version could be displaying (???-Class, ???-Imp) instead of nothing. Headbomb {ταλκκοντριβς – WP Physics} 13:14, 12 May 2009 (UTC)

Sorry, can you tell us which template or page you are referring to? Thanks, — Martin (MSGJ · talk) 13:22, 12 May 2009 (UTC)
All banners, I think; this has come across from Template talk:WikiProjectBannerShell, which is also on my watchlist :D
I'm not fundamentally against this change; the way the banners are currently set up, the left side (with the project link and any taskforces) fills up a lot quicker than the right (with only the class assessment); but it's by no means a trivial change. There is also the question of how to handle projects that use "priority" rather than "importance" scales. Happymelon 13:32, 12 May 2009 (UTC)
This might be worth thinking about, but I would oppose displaying ??? for its ugliness. — Martin (MSGJ · talk) 13:56, 13 May 2009 (UTC)
In the same way that we don't display "(Rated -Class)" for unassessed articles, yes, definitely. Happymelon 14:31, 13 May 2009 (UTC)
I disagree that it shouldn't be displayed. This distinguishes the banners from things that simply tag the page. If the project doesn't use the assessment or importance ratings, then ??? shouldn't be displayed, agreed. But otherwise you'll want to indicate that something is missing, IMO. It is possible that I am a minority opinion here.Headbomb {ταλκκοντριβς – WP Physics} 11:58, 15 May 2009 (UTC)
By the way,
  1. Why is the division line between the project name and class in the middle? Normally the left side will be fuller, as you say.
  2. There seems to be quite a big border on the left of a collapsed banner which is unused. See my example underneath.
  3. Is there any simpler way to get Biography and Milhist to line up with WPBM banners? It looks a bit ugly when there is a mixture of styles. — Martin (MSGJ · talk) 16:04, 13 May 2009 (UTC)
It's been a complete pig to get the centrelines to line up at all; you know how many obscure browser bugs we found trying to get a system that worked! The reason for the large left padding is that there's a transparent span the same size and shape as the show/hide button, to balance the remaining space (otherwise the centreline would be left of centre). We might be able to get rid of that with the most recent incarnation of the header structure; I'll have a looksee. Despite the imbalance, I think it looks nicest when it is centred: the Australia banner you give is of course an extreme example; I haven't seen any article in more than a couple of taskforces. And I'm not sure how easy it would be to persuade all browsers to set the midline consistently at anywhere other than the centre. Although it might work. Milhist and WPBio could be given the same structure as the WPBM fairly easily. And since they're likely to be some of the last banners to be converted (WPBio because of the listas thing, Milhist just because they're so well supported themselves), it might be a good idea to do so. Happymelon 17:11, 13 May 2009 (UTC)
I dunno, I think Oregon might be the last to be persuaded, although maths and us roads will give them some competition. — Martin (MSGJ · talk) 17:31, 13 May 2009 (UTC)
In terms of needing to be "persuaded", I think Tropical cyclones can give all the others a run for their money; at least Oregon raises legitimate concerns, even if they do take every little thing as an excuse to revert. I was thinking more in terms of actual technical difficulty in adapting banners to WPBM form; WPBio is a nonstarter if listas doesn't work, and MilHist is so well-developed that getting WPBM to match its unique features is going to be a nightmare. But at least both those projects are, IMO, amenable to listening to suggestions for improvement; Kirill over at Milhist in particular is very good at keeping their banner bang up to date: it was the first banner after WPBM to implement the new nesting code, for instance. Happymelon 19:38, 13 May 2009 (UTC)
The example above was slightly extreme, but for a ridiculous example have a look at Christianity which I have just finished converting. Lol, I thought 36 had to be the record but then I counted Australia's. — Martin (MSGJ · talk) 20:00, 13 May 2009 (UTC)

Anyway back to business. I would have thought a split of 3/4 and 1/4 would have been almost as easy and would also look good. But I'll take your word if you say it's hard. — Martin (MSGJ · talk) 20:00, 13 May 2009 (UTC)

I've stuck something in the sandbox that removes the huge left margin; it only actually saves two lines. Iff that new incarnation of the structure doesn't crash and burn in browser X, we can see if we can play with the position of the centreline; it might actually be possible. How does the monster testcase look in people's browsers? Happymelon 20:41, 13 May 2009 (UTC)
In FF3 Vista, it does this. Dendodge T\C 20:49, 13 May 2009 (UTC)
Internet explorer 7 on Vista — Martin (MSGJ · talk) 20:55, 13 May 2009 (UTC)
Not on my FF3 in Vista. — Martin (MSGJ · talk) 20:57, 13 May 2009 (UTC)
Sorry, it is happening on mine in FF and IE. I never tried the "show" button! — Martin (MSGJ · talk) 21:16, 13 May 2009 (UTC)
That's a column inbalance, very wierd. Try purging, null editing, etc? Happymelon 21:13, 13 May 2009 (UTC)
I don't feel like an idiot, honest :D How about now? Happymelon 21:28, 13 May 2009 (UTC)
Deployed. Hopefully nothing will fall apart this time... :S Happymelon 10:26, 15 May 2009 (UTC)
Lol, fix one thing and break another. Our width issue is back. — Martin (MSGJ · talk) 14:48, 15 May 2009 (UTC)
Grrr... :D  Fixed Happymelon 16:27, 15 May 2009 (UTC)

Section break (collapsed importance)

Ok, so it looks like there's nothing jaw-droppingly wrong with the new header structure. What do people think about actually implementing this proposal? How do you think we should format it? All in the same bracket, or in separate brackets? Happymelon 20:46, 19 May 2009 (UTC)

I would go with a bold ( A-Class, Top-Importance ), dropping the "rated" to save space. Headbomb {ταλκκοντριβς – WP Physics} 21:19, 19 May 2009 (UTC)
Also as a style issue, I would make place each project name with their slashes in a {{nowrap}}, so lines either end with slashes or with the final project. (I see New South Wales on two lines, and it's rather ugly). Headbomb {ταλκκοντριβς – WP Physics} 21:22, 19 May 2009 (UTC)
I'm persuadable, but at the moment I'm going with weak oppose. I think it's fair to say that as the importance is project-specific (well the quality is as well, but that's another discussion ...) and so it's probably of interest only to that project and so doesn't need to be displayed in the collapsed version. There is no more reason to display importance than another parameter. In fact you might make a stronger case for displaying a message when attention=yes. Obviously we can't display all information - collapsing is supposing to be supressing additional information - and I'm not persuaded that importance should be an exception. — Martin (MSGJ · talk) 15:20, 21 May 2009 (UTC)
Agree with Martin here. The project importance scales are defined so as to be specific to that particular project. The resulting metadata is useful outside of the project, of course, but it is hardly vital. Michael Jackson (an FA) is obviously rated of Top-Importance for WikiProject Michael Jackson, but only of Low-Importance for WikiProject Christianity (or WikiProject Janet Jackson, for that matter). Such differences are normal, and arise only because of the way that WikiProjects are organised. If there's a serious difference in the quality assessment between projects, on the other hand, that probably means that the article needs improving in some way. Physchim62 (talk) 15:44, 21 May 2009 (UTC)
Well for instance, it greatly simplifies the task of people who wants to review the ratings. Which is what triggered this request. Displaying the taskforce-specific ratings would be overkill, I agree, but there is space to display the project ratings, so why not use it? While we're on the topic, I'm not opposed to display things like |attention=yes either, but there simple icons such as could be used (if indeed people want them). Which leads me to perhaps overhauling the class/imp display to color coded boxes. Something like "WikiProject Physics | [GA-class][Top-Imp]" (in their usual colours). I'll build an example of what I mean. Headbomb {ταλκκοντριβς – WP Physics} 15:50, 21 May 2009 (UTC)
Hey, we might even have a use for all those class icons now. — Martin (MSGJ · talk) 16:03, 21 May 2009 (UTC)
Alright, see User:Headbomb/Sandbox/Banner (its crude, but you'll get the idea).Headbomb {ταλκκοντριβς – WP Physics} 16:17, 21 May 2009 (UTC)
Interesting! I think I will need some time to decide if I like it or not ... — Martin (MSGJ · talk) 18:05, 21 May 2009 (UTC)
Alright, I've expanded it a bit to show what I think should be the behaviour in various situations. I think its self-explanatory, but if you have questions, just ask. Headbomb {ταλκκοντριβς – WP Physics} 19:58, 21 May 2009 (UTC)
The last part (content transfered to the banner shell when fully-collapsed) is technically impossible (except with some very messy JavaScript). I'm not convinced by using the background colours (although maybe using the text colours from Pyrospirit's metadata script could work?). The icons, on the other hand, are inspired. Now, where can we find some importance icons? :D Happymelon 21:51, 21 May 2009 (UTC)
If you add the messagebox & standard-talk classes to those examples, it gives it more of that "familiar" brown looking appearance. -- WOSlinker (talk) 22:19, 21 May 2009 (UTC)
(unindent) Yes there a lot one could do to tweak the appearance, I've just shown what I think was the "core idea" of what the layout should be. Aka italics, bolds, nowraps (see code), behaviour, etc... There's a lot of things I didn't address because it involves dealing with spans and table code way too much for my liking. For example, I didn't bother doing borders properly, so I used the mdash line to show where I think should be a visual delimitation. Another thing is I don't think there should be vertical lines, but I didn't bother to remove them, etc... I just used the default wikitable background because it was simpler, etc... If something is not possible (or way too excruciating to bother doing), then lets not worry to much about and do the rest. Headbomb {ταλκκοντριβς – WP Physics} 23:44, 21 May 2009 (UTC)
Some minor tweaks (for unassessed class and unknown importance mostly) were made. See User:Headbomb/Sandbox/Banner.Headbomb {ταλκκοντριβς – WP Physics} 13:11, 22 May 2009 (UTC)
Anymore feedback on this idea? Should we (well mostly you I suppose) go ahead with it? Headbomb {ταλκκοντριβς – WP Physics} 14:17, 26 May 2009 (UTC)
I'm not sure whether we've got much of a consensus here. I guess we could try it for a few days and see what howls of complaint or support we get. But the implementation itself might be a bit messy, the separator needs to only be added when both quality and importance are assessed, the surrounding braces when either-or, and so forth. Happymelon 15:06, 26 May 2009 (UTC)
I like it, but I'd maybe prefer the class icons (we have one for all of them, even redirect and stuff, don't we?) to the coloured boxes. However, I like either way. Dendodge T\C 16:48, 26 May 2009 (UTC)
I'm not much of a fan of the class icons. They are rather small, and for most of them, aren't all that clear (start vs stub for example). However, I wouldn't mind seeing the various {{X-Class}} be updated to incorporated the class icons like {{GA-Class}} and {{FA-Class}} already do. The seperators could be there by default (a later feature would be to make them dependant on wheter or not the banner has the importance scale enabled). See the fluid dynamics example for what I mean. Emdashes when the importance scale is disabled, {{-importance}} when the scale is enabled, but unfilled. Headbomb {ταλκκοντριβς – WP Physics} 18:16, 26 May 2009 (UTC)
You mean icons in the coloured cells for the quality assessment? They're already there, have been for months. :P You just need to add .wpb .assess * {display: inline!important;} to your stylesheets to see them.
It's current practice to only display the "(Rated X-Class)" when the article has actually been rated, and I don't think it should be otherwise. That is, the banner shouldn't say "(Rated ???-Class, ???-Importance)" when neither are filled in, but not display anything, similarly "(Rated X-Class)" instead of "(Rated X-Class, ???-Importance)", and (potentially, although unlikely) "(Rated Y-Importance)" when the importance is set but the quality is not. Otherwise the shell gets unnecessarily messy. Happymelon 20:43, 26 May 2009 (UTC)

(unindent) No they're not. See for example Talk:Hydrogen spectral series (there's no C-class icon , only the C-class yellow box. As for ???-Class/Importance, they really should be there IMO. They currently take a lot of space because they are placed on two lines, and I suspect this is the reason why these are not displayed, but my way of doing things is really minimalist as far as space is concerned. The ??? indicates that the article has not yet been rated, while the &emdash; indicates that no rating needs to be provided. The initial coding would probably be easier if it behaves like I suggest, as the undisplay of ???-class and/or ???-imp would probably be a real PITA. Headbomb {ταλκκοντριβς – WP Physics} 22:00, 26 May 2009 (UTC)

Oh I assure you they are there, you just need to look carefully :P. That, and put the necessary code in your monobook.css in order to make them visible :D.
Are we talking about the same feature here? Currently when placed inside a banner shell, WikiProject banners collapse to look something like this:
With all the other gunk hidden inside the collapse. We are proposing to make a change to:
Also displaying the importance rating. Now currently, when no rating is given, the banner displays like this:
Rather than like this:
And I think that this is the correct behaviour. Anything else is, IMO, messy. Coding complexity is to functionality as performance is to coding: it is not impossible, just fiddly. This change is likely to be somewhat controversial; it has much more likelihood of sticking if no more functionality is changed than is necessary. Happymelon 22:17, 26 May 2009 (UTC)
If this requires monobook.css modifications, then its not what 95%+ of users will see. If we're talking about current behaviour, then the above modification would be OK I suppose, although I would remove "rated" since its pretty redundant.
and (depending on the situation)
although (if there is consensus against displaying ???), then I suppose
would be okay. However, I was arguing for something that would look a bit more like (with whatever magic markup you use for your tables)

and (depending on the situation)

Headbomb {ταλκκοντριβς – WP Physics} 22:50, 26 May 2009 (UTC)
Yuck. Sorry, but that's not going to get my vote any time soon. Why are the colours needed? What value do they add?
Vis the icons, we had a fairly large discussion when they were first added a while back (when they were initially visible to everyone); the consensus was against icons for all classes, so they were hidden by default, and people like me who like to see them can add a line to their monobook to make them visible again. If you like them, do so and see them. Happymelon 23:03, 26 May 2009 (UTC)
(Retweak widths to something more reasonable). The main reason for moving to the colour boxes is that it allows to further reduce verbiage (no need to write "class" and "importance" anymore), and liberates space for the Wikiproject column. If colors are to be avoided, then
WikiProject Tulips / Floridae A-Class Top-Importance
WikiProject Tulips / Floridae ???-Class Top-Importance
WikiProject Tulips / Floridae A-Class ???-Importance
WikiProject Tulips / Floridae ???-Class ???-Importance
Headbomb {ταλκκοντριβς – WP Physics} 23:13, 26 May 2009 (UTC)
But now what's the difference between that and the brackets? Happymelon 08:22, 27 May 2009 (UTC)
More spaces for the projects and taskforces mostly. And that's without the icon expansion (see my sandbox linked above).Headbomb {ταλκκοντριβς – WP Physics} 08:42, 27 May 2009 (UTC)

(unindent) I propose we go forward with what you've said above. Other things (like the icons) can be added later. Headbomb {ταλκκοντριβς – WP Physics} 17:06, 29 May 2009 (UTC)

Another section break (collapsed importance)

lens Review Ok, I have something that seems to do the trick; and also only displays the protect-IE-from-itself hack when it's actually needed. How does it look? Happymelon 11:38, 12 June 2009 (UTC)
Well, firstly, it is showing NA-importance when (a) importance is not used and (b) when importance is something strange like "bottom". — Martin (MSGJ · talk) 15:23, 12 June 2009 (UTC)
Okay I have switched off the display of NA-importance so that's the first problem sorted I think, as it's the only importance automatically set by the mask. — Martin (MSGJ · talk) 15:40, 12 June 2009 (UTC)
Oh damn, it doesn't integrate with custom importance scales. Hmm, do we bite the bullet and implement custom importance masks in the main banner? It could be a big shakeup, but I am actually tempted... Happymelon 16:37, 12 June 2009 (UTC)
What would be the alternative solutions? Is there any reasons to not switch towards supporting custom importance classes? Headbomb {ταλκκοντριβς – WP Physics} 21:11, 12 June 2009 (UTC)
I don't think there are any, really. It's just another massive amount of work, and it's not as neat as the class mask because one depends on the other: the importance mask has to be given the normalised output of the class mask, so it has to occur at a different level in the stupid quasi-programming language we're playing with. However, I am inclined to think that it is a good idea overall. But it moves this out of the realm of the quick fix. Happymelon 21:39, 12 June 2009 (UTC)
Ugh, I would advise against this. We now have a fairly effective way of implementing custom importance scales for the very few number of projects which use it. There is no reason why the Top/High/Mid/Low/NA scale should not be suitable for every project, and I don't see an advantage in encouraging more projects to use weird and wonderful importance ratings just because they can :) If the nested importance thing goes ahead, then personally I think these few projects can live without this feature. But for consistency it would require a check on importance=¬, otherwise it will display on some and not other articles within the same project which is probably not a good idea. — Martin (MSGJ · talk) 12:24, 16 June 2009 (UTC)
Mmm. You certainly have a point in that if we make it easy, people will do it, which is not always good. The problem will be that those projects that do use a custom scale may get, as you say, nothing displayed when they set |importance=Bottom. What do you mean about the |importance=¬ check? Happymelon 13:07, 17 June 2009 (UTC)
I meant that it would not be desirable for nested importances to be shown on some instances of a project banner (e.g. when the articles was rated with one of standard importance ratings) and not others (e.g. when an article is rated bottom-importance). It should be all or nothing for each banner. Therefore a check to see whether the importance parameter is passed by the banner should be used. Any clearer? — Martin (MSGJ · talk) 14:25, 17 June 2009 (UTC)
Because when a custom scale is used, |importance= is not passed through the main banner. Yes, clearer. But ¬ is normalised to "unknown", so I don't think it would display in any case...? I can check, but I think the question of "what to display when the rest of the banner is showing Bottom-importance" is actually unreachable... Happymelon 14:35, 17 June 2009 (UTC)
Yup, no display, ever. Does this resolve the issues? I confess I've somewhat lost track of where some of the things here are at in terms of review (to much RL intruding :D) Happymelon 14:39, 17 June 2009 (UTC)
I think you are still not understanding my point, so I'll try again. I am proposing that Rocketry articles should never get nested importance, not just the ones which are rated Bottom-importance. Why? Because then it is simply the case that we can't offer that project a new feature because they are using a custom importance scale, which is fine. The alternative is an inconsistent result (depending on the importance rating) which may give the impression that the meta banner is operating in an undesirable way and "broken". — Martin (MSGJ · talk) 14:52, 17 June 2009 (UTC)
Yes, that's exactly what I'm saying. When the banner uses a custom imporance scale, the nested-importance code always thinks that the importance is undefined, and so displays nothing. This is what you want, no? I've added some more examples to the shell at the top of this subsection. Happymelon 15:19, 17 June 2009 (UTC
Okay, you were understanding perfectly and I'm just being stupid! Yes, only Unknown and NA can be set automatically and neither of these will be displayed. — Martin (MSGJ · talk) 15:59, 17 June 2009 (UTC)
Why not simply a |bottom=yes in the metabanner?Headbomb {ταλκκοντριβς – WP Physics} 13:45, 17 June 2009 (UTC)
Because it's not just {{Bottom-importance}}; although there is certainly less variety in the importance custom scales than the quality scales. How would we react to a request to add a "Middle-importance"? Happymelon 14:17, 17 June 2009 (UTC)
Tell them to stop being silly and use Mid-importance :) — Martin (MSGJ · talk) 14:54, 17 June 2009 (UTC)
Exactly. And if new ones show up (such as pink-importance), then you could always implement |pink=yes.Headbomb {ταλκκοντριβς – WP Physics} 15:06, 17 June 2009 (UTC)
But do we want to open the door to an unclosed set of extra parameters which have to be passed all the way down to /importancescale every time it's called (and would have to be set again in hooks etc)? That is not good practice. If we do make it easier to implement custom scales, it should be by making it possible to make all the changes in one place - a custom importance mask - rather than having to repeat them wherever an importance rating is required. Happymelon 15:19, 17 June 2009 (UTC)

Ok, so is this good to go? Happymelon 21:01, 17 June 2009 (UTC)

No harm in giving it a spin. — Martin (MSGJ · talk) 21:44, 17 June 2009 (UTC)
Ok then, let's shake the tree and see what falls out :D Happymelon 22:19, 17 June 2009 (UTC)

Champagne & Caviar

I'd like to ask everyone to raise a glass to Rob Halsell, who has (ish)recently change enwiki's default category sortkey to no longer include the namespace prefix (T18552). This means that I've just been able to resolve one of our longest-standing issues, the totally-broken |listas= functionality, by simply removing the sortkeys from all our categories. The cats should sort themselves out over the next few days; Rob is colluding with Tim to run a parallelised version of the maintenance script to update the sortkeys wiki-wide; as the regular serial version will, in the words of Brion, "take a billion years to run" over enwiki's 40-million-or-so-row categorylinks table.

Points to note:

  1. When adding categories for whatever reason, they should now usually not have a sortkey of any kind (except for filtering in tracking cats, of course). So use [[Category:Foo]] instead of [[Category:Foo|{{PAGENAME}}]]. This actually applies wiki-wide, not just to WPBM.
  2. There is now nothing to stop us converting over {{WPBiography}}. <evil laugh/>

Happymelon 09:54, 12 June 2009 (UTC)

Caviar for Funandtrvl
WOOHOO!! DeFaultRyan 14:55, 12 June 2009 (UTC)
Still a bit confused about listas. Does this prevent the default sort conflicts which used to occur? — Martin (MSGJ · talk) 15:03, 12 June 2009 (UTC)
All |listas=foo has ever done here has been to add a {{DEFUALTSORT:FOO}} to the page when set. We then proceeded to totally disregard that sort by adding an explicit sortkey of {{PAGENAME}} to every category. The defaultsort conflicts were from other banners' attempts to resolve the same issue (talk pages all appearing under "T" if no DEFAULTSORT was set) by specifying {{DEFAULTSORT:{{PAGENAME}}}} if nothing else was given. Now all this hacking around is unnecessary, because Talk:Foo will be sorted by default under "F" if no sortkey is specified, either by DEFAULTSORT or with an explicit key in the category link. All in all a very positive development. Happymelon 17:19, 12 June 2009 (UTC)
Okay, where's the caviar? --Funandtrvl (talk) 18:43, 13 June 2009 (UTC)
Thanks, that's good! --Funandtrvl (talk) 18:59, 13 June 2009 (UTC)

We're running for the big league now: Template talk:WPBiography#WPBannerMeta, reprise. Although actually this template, used on 2.1 million pages, makes WPBiography, with a 'mere' 720,000, look almost orphaned... :D Happymelon 21:25, 15 June 2009 (UTC)

Very funny! --Funandtrvl (talk) 23:00, 15 June 2009 (UTC)
The caviar is just for me?? Wow!! I need to go on another cruise vacation, where they have it!! --Funandtrvl (talk) 20:19, 22 June 2009 (UTC)

Can't get the redirect class to work on {{WikiProject Elements}}

See Talk:Aluminium-27. I place |class=redirect and it never shows up. All others classes work just fine.Headbomb {ταλκκοντριβς – WP Physics} 14:27, 13 June 2009 (UTC)

You need a custom class mask to implement Redirect-Class these days. See Template:WPBannerMeta/class for details. — Martin (MSGJ · talk) 15:42, 13 June 2009 (UTC)
But there is a custom class mask. See {{WikiProject Elements/Class}}, which I copied from {{physics/class}}.Headbomb {ταλκκοντριβς – WP Physics} 15:52, 13 June 2009 (UTC)
Ah, I think I found the problem. I've capitalized "/Class" but the template is looking for "/class".Headbomb {ταλκκοντριβς – WP Physics} 15:54, 13 June 2009 (UTC)
Ah, well spotted. There are a couple of inconsistencies on that class mask. For example Image-Class is used in one place but pages in the File talk namespace are given NA-Class. — Martin (MSGJ · talk) 16:00, 13 June 2009 (UTC)

Hi-Could you check out why the "priority" parameter doesn't work for the testcases? Thanks. --Funandtrvl (talk) 00:38, 16 June 2009 (UTC)

The priority parameter was not being passed through. Diff -- WOSlinker (talk) 06:30, 16 June 2009 (UTC)

/Comments subpages bleeding through to talk page TOC

See Talk:Eastern Nazarene College, the Talk:Eastern Nazarene College/Comments subpage seems to be bleeding through somehow. Also had to force a TOC. –xenotalk 19:06, 16 June 2009 (UTC)

It's because there's a section header in the comments subpage. Dendodge T\C 19:10, 16 June 2009 (UTC)
I thought that might be it. Thanks, –xenotalk 19:26, 16 June 2009 (UTC)

Minor apperance tweak

Currently the projects and taskforces listed appear as '''Wikiproject Australia''' / '''Adelaide''' / '''Brisbane''' / '''Canberra''' / '''New South Wales''' / '''Melbourne''' / '''Perth''' / '''Queensland''' / '''Sidney''' / '''Tasmania''' / '''Victoria''' However, this causes slashes to appear on new lines rather than at the end of a line. This should be revised to '''Wikiproject Australia'''&nbsp;/ '''Adelaide'''&nbsp;/ '''Brisbane'''&nbsp;/ '''Canberra'''&nbsp;/ '''New South Wales'''&nbsp;/ '''Melbourne'''&nbsp;/ '''Perth'''&nbsp;/ '''Queensland'''&nbsp;/ '''Sidney'''&nbsp;/ '''Tasmania'''&nbsp;/ '''Victoria''' or equivalent.

Or

Wikiproject Australia / Adelaide / Brisbane / Canberra / New South Wales / Melbourne / Perth / Queensland / Sidney / Tasmania / Victoria

vs.

Wikiproject Australia / Adelaide / Brisbane / Canberra / New South Wales / Melbourne / Perth / Queensland / Sidney / Tasmania / Victoria

(difference might not show up depending on zoom level and screen size)

Also, it would be interesting to investigate

Wikiproject Australia:  Adelaide / Brisbane / Canberra / New South Wales / Melbourne / Perth / Queensland / Sidney / Tasmania / Victoria

as a possibility. See User:Headbomb/Sandbox/Banner (taskforces collasped) for an example. Headbomb {ταλκκοντριβς – WP Physics} 01:18, 18 June 2009 (UTC)

I've done the linewrapping tweak, that was easy. I don't think I'm a fan of the italics; in some cases (eg {{WikiProject Africa}}) the 'taskforces' are just as important as the main project; it would be a disservice to reduce their prominence. And I don't think there's a serious space shortage (or much space to be gained by changing the formatting). Happymelon 08:19, 18 June 2009 (UTC)

Task forces in collapsed banners

Has there been some kind of recent change regarding this? It was switched off in {{WikiProject Korea}}, but now seems to be on. PC78 (talk) 23:51, 20 June 2009 (UTC)

I added it on 8 June. Sorry if it wasn't desired; do you want them removed? — Martin (MSGJ · talk) 18:46, 21 June 2009 (UTC)
Please. I must have missed that. PC78 (talk) 20:08, 21 June 2009 (UTC)
 Done, although I can't see any disadvantage in having them. — Martin (MSGJ · talk) 20:29, 21 June 2009 (UTC)
It just adds unnecessary clutter, IMHO. The task forces aren't all that active anyway. Cheers! PC78 (talk) 22:43, 21 June 2009 (UTC)

Anyone know how to remove the "importance" parameters from the above template for the Runes task force? John Carter (talk) 19:52, 24 June 2009 (UTC)

If I've interpreted your question correctly, you don't wish there to be importance assessments for the task force. You just need to remove the tf 1 importance parameter, as I have now  Done. — Martin (MSGJ · talk) 20:42, 24 June 2009 (UTC)
You did. Thank you. John Carter (talk) 20:44, 24 June 2009 (UTC)

Could someone take a look at this template? Problems: 1. Isn't the "note" for TFs not the way to do it? 2. in the "include only", there's no closing "/include only" and what does all that stuff after include only do again? Thanks --Funandtrvl (talk) 03:28, 25 June 2009 (UTC)

You're right, it was a mess. I've done my best with it. — Martin (MSGJ · talk) 07:32, 25 June 2009 (UTC)

Page type

I've started a template to report the type of page, for use in sentences like "This article/page/??? is within the scope of ..." in the main text of the banner and in the taskforces. It's at Template:WPBannerMeta/pagetype. Comments welcome. — Martin (MSGJ · talk) 16:13, 8 June 2009 (UTC)

Well, there were no comments so I've implemented this on the default taskfore text as a start. I'm thinking that instead of "Portal page", "Project page", "Disambiguation page", "User page", etc. we just use "page" as it is simpler. What do people think? — Martin (MSGJ · talk) 09:38, 11 June 2009 (UTC)
This could probably stand on its own at {{pagetype}} or something; could potentially be useful to other templates. Very sensible idea though; haven't looked at the code fully, but it seems a fairly simple concept; shouldn't be too many idiosyncracies. Happymelon 23:52, 11 June 2009 (UTC)
Agreed and moved. — Martin (MSGJ · talk) 07:16, 12 June 2009 (UTC)
I've been through the banners in Category:WikiProject banners without quality assessment and changed them to use pagetype where appropriate. -- WOSlinker (talk) 19:18, 12 June 2009 (UTC)
It just needs using in Template:WPBannerMeta/importancescale and Template:WPBannerMeta/qualityscale now. -- WOSlinker (talk) 19:37, 12 June 2009 (UTC)
Yes, good idea. I just held back because I wanted to be absolutely sure that it couldn't possibly say "This article is not an article and ..." because it would be silly. And I think this could happen, if you set NA-importance on an article. — Martin (MSGJ · talk) 18:11, 13 June 2009 (UTC)
You could always change the NA messages from "This page is not an article and does not ..." to "This page does not ...". -- WOSlinker (talk) 18:28, 13 June 2009 (UTC)
That sounds like a sensible suggestion. The other solution is to call {{pagetype|NA}} to avoid the possibility I mentioned. — Martin (MSGJ · talk) 23:30, 13 June 2009 (UTC)

lens Review Can you check my code on importancescale/sandbox. I realised that as we don't display NA-importance, the above can never happen! — Martin (MSGJ · talk) 07:32, 14 June 2009 (UTC)

It needed to have |class= passed through to get the correct switch on redirects and dab pages. Looks good otherwise though. It does say "article" on non-talk pages, which is a bit wierd, though; I see that that's documented on {{pagetype}}, but would it be sensible to add a #switch option for SUBJECTSPACE (ie, all non-talk namespaces) of "page"?? Happymelon 09:16, 14 June 2009 (UTC)
I wasn't going to bother, as they will be NA-importance by default anyway, so it would only make a difference if an importance was forced on a dab page. But I agree it doesn't do any harm. {{Pagetype}} can be occur on subject pages in two ways: on templatepage (where "article" should be used) and on examples (where the class should be used, if specified). I think my recent edit should have done this. — Martin (MSGJ · talk) 16:15, 14 June 2009 (UTC)

Two methods for using {{pagetype}} with non-articles on the quality scale. Any preferences? Note that method 2 requires the full description of the page type to be used because we can't just say "this is a page ..." — Martin (MSGJ · talk) 22:12, 14 June 2009 (UTC)

Option file disambiguation page
1 This file is not an article and does not require a rating ... This page is not an article and does not require a rating ...
2 This is a file and does not require a rating ... This is a disambiguation page and does not require a rating ...
3 This file does not require a rating ... This page does not require a rating ...
Is "This file does not require..." not possible? That's my personal preference, for the right balance of conciseness and grammatical accuracy... Happymelon 17:10, 15 June 2009 (UTC)
Ah, so we have a third option. plus Added. I didn't put it in initially because it doesn't get across that the reason it doesn't require a rating isbecause it's a file (and not an article). Well, I agree it's the simplest. Any other opinions? — Martin (MSGJ · talk) 21:05, 15 June 2009 (UTC)
Okay, if there are no further opinions, I intend to implement option 3 in a few days' time, along with the corresponding change in the importance scale wording, as discussed above. — Martin (MSGJ · talk) 12:13, 16 June 2009 (UTC)

 Done. Hopefully that won't cause any problems. I would like to move the conditionals on ASSESSMENT_LINK, by setting it to [[Wikipedia:Version 1.0 Editorial Team/Assessment}}]] on {{WPBM}} itself rather than on the subtemplates. Would this cause any problems? — Martin (MSGJ · talk) 10:53, 18 June 2009 (UTC)

It's not like that already? Definitely. Although you probably need to be careful not to screw up the notification message on /templatepage. Happymelon 11:06, 18 June 2009 (UTC)
Yes, thanks for the reminder. — Martin (MSGJ · talk) 11:10, 18 June 2009 (UTC)

Hang on. The generic importance scale is on a different page. So maybe this wasn't a great idea after all. — Martin (MSGJ · talk) 11:26, 18 June 2009 (UTC)

I've fixed it temporarily. But one of the following needs to happen I think:
  • The generic quality and importance scales are put together on one page somewhere, or
  • The changes I made to be reverted.
— Martin (MSGJ · talk) 11:41, 18 June 2009 (UTC)
It's not so bad, I guess. As a thought, though, you might want to check the hooks, particularly the customimportance one. I don't think there is a perfect solution here. Happymelon 11:46, 18 June 2009 (UTC)

lens Review I think I have a better proposal. Revert the changes to ASSESSMENT_LINK on WPBM and put the mask on /core instead. Then each can be given their own link and the current messy solution can be fixed. A future possible idea might be to move the generic scales somewhere together: WP:WikiProject Council/Assessment might be a good place. — Martin (MSGJ · talk) 11:46, 23 June 2009 (UTC)

Gave up waiting for comments and I've reverted it. I think it was much better before. — Martin (MSGJ · talk) 21:36, 25 June 2009 (UTC)

Right margin padding on image_right

Hi, there isn't any padding on the right margin when image_right is used, the image ends up flushed up against the rt. margin, almost looking like part of the image is cut off. Could you set it up like image_left is, so there is a slight margin to the right of the image? See: Template:Lake project for an example, and that template needs a few fixes, see: Template talk:Lake project. Thanks again! --Funandtrvl (talk) 20:17, 22 June 2009 (UTC)

I see what you mean. It actually looks fine on Firefox so I guess you are using Internet Explorer (that's where I can see the problem). I'll probably leave this one for happy-melon to look at when he has a moment. — Martin (MSGJ · talk) 20:56, 22 June 2009 (UTC)
Thanks, yes it's on IE8. It looks like in Template:WPBannerMeta/core that image_left has one more line of code in the table than image_right does, will wait for Happy-melon! --Funandtrvl (talk) 21:06, 22 June 2009 (UTC)

I think it's the Internet Explorer box model bug. Not sure how best to resolve it; I'll have a play... Happymelon 13:16, 30 June 2009 (UTC)

Yes, it was. I think using "display:block" instead of "width:100%" avoids it; I've now implemented this fix, let's hope it doesn't destroy anything else! Happymelon 15:22, 30 June 2009 (UTC)
Well, I wish that were the fix, but the photo is still up against the right margin on Template talk:Lake project. --Funandtrvl (talk) 23:37, 30 June 2009 (UTC)
It's looking okay to me on IE8. Which browser do you use? — Martin (MSGJ · talk) 08:04, 1 July 2009 (UTC)
Fine to me on IE7 and FF3; I've asked for more shots from browsershots.org; nothing that's come up so far has revealed a problem. I'd second the browser question. Happymelon 13:33, 1 July 2009 (UTC)
It looks ok on a 15.4" widescreen, will check other monitor later today, could be resolution setting. --Funandtrvl (talk) 13:55, 1 July 2009 (UTC)
From those browsershots, there seems to be something really badly wrong with {{Talk header}}, but that's a different kettle of fish. Also, quite a few browsers cut the right border off WPBM for some reason, but again that's a different problem. Every shot shows the clipping problem resolved. Happymelon 14:31, 1 July 2009 (UTC)
Yep, it looks ok on diff monitors, thanks again!! --Funandtrvl (talk) 22:44, 1 July 2009 (UTC)

Proposal regarding NOTES and C_NOTES

I suppose that the idea behind collapsed notes is that too many notes can make a banner too large and display too much information. However if there is only one collapsed note triggered, then it is fairly pointless to collapse it.

On the other hand, if all five uncollapsed notes are triggered then it will be huge anyway. So here's a solution which solves both issues:

  • Deprecate collapsed notes. (Maybe support an extra one or two normal notes to compensate.)
  • If three or more notes are triggered, then automatically collapse all the notes.
  • (We could provide extra flexibility, and allow projects to specify the threshold for collapsing (including zero and infinite).

Good idea or bad? I stole this idea from the FILM template which does something like this. — Martin (MSGJ · talk) 12:09, 30 April 2009 (UTC)

This is an excellent idea, and nicely resolves all the outstanding issues with notes and c notes. A study of the number of notes and tfs used by banners would be very useful; I'll see if I can write a script to gather that data. We should definitely try to incorporate flexibility in the collapse threshold. Happymelon 12:46, 30 April 2009 (UTC)
Data. Some interesting points there, I think. I'm not 100% sure that it's competely accurate; the absence of any banners with more than 5 notes is suspicious. Happymelon 13:54, 30 April 2009 (UTC)
Did the columns get swapped or something? WikiProject College football is listed with one collapsed note, but it only uses a single "regular" note. P.S.: Sounds like a great idea. DeFaultRyan 15:19, 30 April 2009 (UTC)
Yes, that's exactly what happened. No project would be listed as having more than five c notes because they'd use the /notes hook on |HOOK_COLLAPSED= instead, which would count towards the "notes" count (I was looking for the appearance of C_NOTE_#_TEXT, (!C_)NOTE_#_TEXT and TF_#LINK, respectively, and compensating for the /tfnested hook for the last one). So any project that's listed as having both c notes and normal notes might be actually using just c notes. Happymelon 15:38, 30 April 2009 (UTC)
Yes please on the collapsed notes. This was functionality that Template:Ice Hockey had which is now gone with BannerMeta. -Djsasso (talk) 15:40, 30 April 2009 (UTC)
Nevermind MSGJ was nice enough to fix it. -Djsasso (talk) 15:45, 30 April 2009 (UTC)

Right, let's get this moving! How's this for a plan of attack?

  1. Taskforces should be unaffected by this proposal. It is quite reasonable to want taskforces to be on display even when other information is collapsed.
  2. Increase supported notes to 8. I like this number and I think it will be sufficient for most projects even when collapsed notes are converted.
  3. In the transition period, collapsed notes will be treated the same as uncollapsed notes. When they have all been converted we can remove support for collapsed notes.
  4. Hammer out the code which will work out whether or not to collapse notes. This may be slightly tricky because if HOOK_COLLAPSED is defined then there will still be a collapsed section regardless of the number of notes.
  5. What else?

— Martin (MSGJ · talk) 20:23, 5 May 2009 (UTC)

Hmn, good point on HOOK_COLLAPSED, not sure how that's best handled. I wonder how many banners are actually using it... I was thinking ten notes, but it's purely plucking a number out of the air whichever way. Otherwise it sounds good. Happymelon 21:56, 5 May 2009 (UTC)

Great, I see you've started work on this. I was hoping you would! A few thoughts:

  1. I was going to suggest another purpose-specific note and now would be a good time. For example, image-needed is a very common one and it would make it much simpler. I'm not sure if there are any others which are common enough to be included.
  2. Regarding hooks, the relevant ones are HOOK_NOTE and HOOK_COLLAPSED. I would suggest that HOOK_COLLAPSED should stay always collapsed. This would give a way to specify that some content is automatically collapsed regardless of the number of notes. (I can't see Template:Philosophy working otherwise.) About HOOK_NOTE, most hooks (e.g. peer review, collaboration, A-class review, etc.) give one line of output. Therefore a non-empty HOOK_NOTE should probaby count as 1 for the calculation. Of course there are some which can give multiple lines, but these will have to be avoided for the calculation to work properly.
  3. Maybe better to normalise all the note triggers as 0 or 1, rather than pass them through {{yesno}} twice.

I'll probably think of more things later! — Martin (MSGJ · talk) 08:57, 16 May 2009 (UTC)

  1. Imageneeded is indeed a very common note, it would be a good idea to implement it in core. However, some projects use quite complicated syntax for specifying where the image is needed from, how the page is categorised, etc. I'm not sure how full-featured we should make it, probably minimal, but even that might still require an |imagedetails= parameter.
  2. Most uses of HOOK_COLLAPSED seem to be on banners that only use collapsed notes; this functionality will be available by setting |COLLAPSED=0. The way I've set it up, all the notes appear in one section; either they are all collapsed or all expanded. Separating stuff would have to be via the /collapsed hook.
  3. Doing that would lose the ¬ information, which would screw up the display on the templatepage.
Happymelon 10:14, 16 May 2009 (UTC)
  1. Yes, an optional imagedetails parameter might be a good idea. It is also quite common to be able to specify part of the category using the image parameter. For example image=London would categorise into Category:Wikipedia requested images in London or similar. An ifexist call could be used for this.
  2. I don't think I'm really understanding. It is fairly common to have collapsed taskforces (e.g. the philosphy template I mentioned) and so I think it will be necessary to allow for a collapsed section even if the notes are not collapsed ...
  3. I'm sure there must be an efficient way although I haven't thought enough about it. Calling {{yesno}} again seems unnecessary as they are already normalised.
— Martin (MSGJ · talk) 12:24, 18 May 2009 (UTC)
  1. This needs more (and separate) evaluation of the best syntax to use. Call it an 'agreement in principle' to implement some form of this :D
  2. The relevant banners are here; there aren't that many of them. Actually Philosophy and Korea are the banners to work explicitly as you say; there might be others using the /collapsed hook, but they won't be affected by the transition.
  3. The issue is that we need to retain the ¬ for undefined notes for /templatepage, but strip them for that particular analysis, or they'll kill the #expr: statement. It could be done without using yesno again:
    {{yesno|{{{note 4|¬}}}|¬=0|yes=1|no=0}}+{{#switch:{{{note 4|¬}}}||¬=0|1}}+, but that's essentially duplicating the code from yesno anyway, and duplication is a Bad Thing (that's what templates are for :D).
Happymelon 12:38, 18 May 2009 (UTC)
Duplication can be a Good Thing, if it can significantly reduce the complexity of a template ;) (I'm not talking about this one, because I haven't really thought about it yet ... but we had an earlier conversation about another one). Just because an existing template can be made to do something, doesn't mean it has to be done this way :) One reason I'm not really understanding point 2 is that you say "/collapsed hook" but seem to mean it in a different way to HOOK_COLLAPSED. — Martin (MSGJ · talk) 12:48, 18 May 2009 (UTC)
Duplication is always a Bad Thing, but if the alternative is worse, then it can still be a Good Idea overall :D
When I say "/collapsed hook" I mean Template:WPBannerMeta/hooks/collapsed, which hooks to |HOOK_BOTTOM=. With this system, there will be no distinction between HOOK_COLLAPSED and HOOK_NOTE; the former will probably be removed. Happymelon 13:00, 18 May 2009 (UTC)
Oh I never knew about that hook. So can collapsed taskforces be implemented using it? If so, then I have no concerns about deprecating HOOK_COLLAPSED. — Martin (MSGJ · talk) 13:06, 18 May 2009 (UTC)
The /collapsed hook basically adds an extra collapsed section wherever you want, with whatever you want in it. IIRC it could do with a few tweaks, but it works well for when more than one collapsible section is needed. Happymelon 15:00, 18 May 2009 (UTC)

Ok, I think this is ready for testing. |COLLAPSED= is now the maximum number of triggered notes that won't collapse. So |COLLAPSED=0 always collapses notes, |COLLAPSED=99 will never collapse them, |COLLAPSED=-1 would show a box whether there were any notes or not, which is a bit wierd, but reasonable. |HOOK_COLLAPSED= now injects into the count, if it's valid numeric input, we can write a hook to go with /hooks/notes like /hooks/tfnested is to /hooks/taskforces, to make the count always correct. And the |C_NOTE= parameters are deprecated, replaced by continuing the |NOTE_#_..= line up to ten. Code is running in the sandbox. Comments? Happymelon 18:53, 18 May 2009 (UTC)

It's looking quite good. I've got some testcases at Template:Fishproject/testcases. I think maybe you were trying to align the collapsed notes the same way as the uncollapsed ones, but your method was breaking it so I removed it. — Martin (MSGJ · talk) 14:26, 19 May 2009 (UTC)
Fixed by the wonders of modern science... :D I'd forgotten I left that in; I realised it didn't work as soon as I first tested it, but forgot to remove it. The new version is much slimmer. Happymelon 16:14, 19 May 2009 (UTC)
It's looking good. I've been trying to think of a good way to simplify the duplicated code but haven't come up with anything yet. What work will be involved in implementing this? I think we may need to track all uses of HOOK_NOTE as well? — Martin (MSGJ · talk) 21:13, 20 May 2009 (UTC)
I don't think it's possible to avoid duplication: either you duplicate the wrapper, you duplicate the notes themselves, or you break the whole thing out into a subtemplate and pass everything through. The former is definitely the least repetitive.
We'll implement it with the C_NOTEs also in place in the notes section; these should be replaced with normal NOTEs. HOOK_COLLAPSED also needs to go, as it's used for something completely different in the new version (that's bad programming practice, but we can get away with it here as we can hunt down all the uses of it). We should probably track use of HOOK_NOTE as well, yes, and write and implement something to hook to HOOK_COLLAPSED to add the right numbers to the counter, but that's not essential. Happymelon 22:37, 20 May 2009 (UTC)

Implemented

Ok, we're rolling! I've deployed the new code, written a hook at {{WPBannerMeta/hooks/notecounter}} which desperately needs documenting :S, and updated all the banners which will have been broken by the change. There are still a fair few banners using C_NOTES which need to be updated, and I'm sure there are a lot of bugs to shake out, but it seems to do the job! Happymelon 12:07, 26 May 2009 (UTC)
Done most of this. Still waiting for the inevitable bug reports! :D Happymelon 15:00, 26 May 2009 (UTC)

It's looking good. I still think we need to track HOOK_NOTE usage to make sure they are all compliant. — Martin (MSGJ · talk) 17:01, 27 May 2009 (UTC)
I agree; I've repurposed Category:WPBannerMeta banners affecting note magic to now track these. We might want to filter out those that also use HOOK_COLLAPSED?? Happymelon 10:09, 28 May 2009 (UTC)
Yes, good idea. I think that it is perhaps not worth setting up the note counter for hooks such as peer review, collaboration and A-class, simply because there will never normally be more than one row. If there is one row, it is likely to be an error. — Martin (MSGJ · talk) 10:24, 28 May 2009 (UTC)
My last edit (diff) probably explains more clearly what I am trying to say above. The most likely number of rows for a non-empty HOOK_NOTE is 1, so we can save ourselves some work here. Although it is possible for an article to have two peer-reviews or A-class reviews (and thus have a current review as well as an old review) I'm suggesting that this is not frequent enough to be worth worrying about! — Martin (MSGJ · talk) 10:53, 28 May 2009 (UTC)
Or at least, if people care about it enough, they can use hooks/notecounter and do it properly. I agree. Happymelon 11:05, 28 May 2009 (UTC)

What would people feel about reducing the default threshold to 2, as originally proposed? (Then, banners with 3 or more notes will collapse by default.) — Martin (MSGJ · talk) 11:14, 28 May 2009 (UTC)

No objection from me. Happymelon 11:17, 28 May 2009 (UTC)
 Done, also found a nice way to treat blank values of COLLAPSED and HOOK_COLLAPSED the same as undefined values without using another parser function. (Please check!) — Martin (MSGJ · talk) 10:03, 29 May 2009 (UTC)

Another thing. You added some padding into the collapsed head (padding:0.2em 2px 0 0.2em). I update /collapsed to match this, but all the other text without images (Comments, To-do list, etc.) is not padded and it looks bad. So can we remove this padding, or add it to all of them? — Martin (MSGJ · talk) 11:51, 28 May 2009 (UTC)

The important thing is the padding-right, which is necessary to get the show/hide buttons to line up. I'm not fussed about the other padding (although I think I've fixed the discrepancy between the two collapsed implementations). Happymelon 15:32, 28 May 2009 (UTC)
There's still descrepancy with other text which looks a bit ugly. See Template:WikiProject Cats for an example. — Martin (MSGJ · talk) 16:59, 28 May 2009 (UTC)
I see. As I said, IGADN about anything other than the right border; feel free to tweak it, or I will sometime. I think the top/bottom padding might be a good idea, tho. Happymelon 21:58, 28 May 2009 (UTC)
That acronym is a new one for me! I'm not confident with these settings, so I won't be fiddling with them. Maybe we can just remove the left padding altogether though? — Martin (MSGJ · talk) 08:09, 29 May 2009 (UTC)
That's cos I screwed it up :D It's supposed to be IDGAD: I Don't Give A Damn...
Yeah I'd be fine with that. Happymelon 09:26, 29 May 2009 (UTC)
 Done Happymelon 09:34, 29 May 2009 (UTC)

By the way, nice work on this. The transition was surprisingly painless and we've had very few complaints. — Martin (MSGJ · talk) 10:29, 3 June 2009 (UTC)

I've been through Category:WPBannerMeta banners affecting note magic and think that the notecounters have now been added to banners which are using more than one hook note, i.e. those which might be expected to have more than one row of output. I think the default setting is okay for the remainder. I've been toying with putting a warning message on /templatepage to advise when HOOK_NOTE is set and HOOK_COLLAPSED is not. — Martin (MSGJ · talk) 12:59, 5 June 2009 (UTC)

I think comments should appear lower than the notes. Thoughts? — Martin (MSGJ · talk) 08:42, 8 June 2009 (UTC)

I agree :D Happymelon 23:47, 11 June 2009 (UTC)

One issue: with a blank NOTE_TEXT it is possible to use notes to add categories but without having a row of text. In these cases, the note should not count towards the collapsing trigger. — Martin (MSGJ · talk) 09:58, 12 June 2009 (UTC)

{{WPBannerMeta/hooks/cats}}?? Seems easier to push that than to rewrite the note counter; that would add quite a lot of checks for something that's not really a Good Idea anyway... Happymelon 10:02, 12 June 2009 (UTC)
That's a pity. I always thought duplication was a Bad Idea :P I'm obviously not keeping up. Seriously though, I'll have a think about this, because I have implemented quite a few notes with blank text (I thought it was a nice feature when I found out it was possible!) and I'd hate to go back and change them all. — Martin (MSGJ · talk) 15:08, 12 June 2009 (UTC)

I have put a warning on templatepage for when HOOK_NOTE is used without HOOK_COLLAPSED. Setting HOOK_COLLAPSED=auto can be used to supress the warning when the automatic behaviour (1 for non-empty hook, 0 otherwise) is desired. And I just had a crazy idea ... I was thinking it would be nice if the /collapsed hook could have a notecounter and collapse magically like the collapsed section in /core. And then I thought that maybe we could move all that code into a separate template which both could use. Any thoughts? — Martin (MSGJ · talk) 21:03, 22 June 2009 (UTC)

Yeah maybe. It would be nice to consolidate all our declarations of collapsible tables so they all use the same padding, margins, etc; should make it easier to line things up. Maybe something to work on? Happymelon 18:04, 2 July 2009 (UTC)

Hi-Is there a way to have this template place newly created categories, i.e. Category:NA-Class school articles into Category:WikiProject Schools articles by quality automatically, or must the Category:School articles by quality be created instead and used in place of the Cat:WP Schools articles by quality? Thanks --Funandtrvl (talk) 05:30, 2 July 2009 (UTC)

I think you've done it the best way, by using the parent parameter of {{cat class}}. To prevent the warnings on the template page, you might want to create Category:School articles by quality and just redirect it to Category:WikiProject Schools articles by quality. — Martin (MSGJ · talk) 06:08, 2 July 2009 (UTC)
The /sandbox has a WPBM version for WPSchools that I believe is ready to implement (hopefully!). Would you check it for us and then convert the template? Thanks again --Funandtrvl (talk) 07:15, 2 July 2009 (UTC)
Please see Template talk:WPSchools for requests to add attention and comments parameters, with reasons explained. --Funandtrvl (talk) 16:15, 2 July 2009 (UTC)

"Additional" vs. "More information"

It is my humble opinion that the WPBM would look better with the previous title for the collapsed section, of "More information", instead of "Additional...".
Reasoning:

  1. It's a shorter word.
  2. It's a more concise word.
  3. It's not as awkward of a word.
  4. It's only one syllable, instead of four.
  5. Usually, "additional" follows "more", not the other way around. For example: "More information will be available tomorrow, additionally..." (Not: "Additional information will be available tomorrow, more...")

Q: Is there any possiblility that it could be changed back? Thanks for considering it, and Happy 4th of July!! --Funandtrvl (talk) 03:48, 4 July 2009 (UTC)

I've reverted it. I still prefer "additional"; it sounds like the perfect word to me and not awkward at all. But I don't really care. Happy independence day to you too :) — Martin (MSGJ · talk) 10:59, 4 July 2009 (UTC)
Thank you! --Funandtrvl (talk) 16:37, 4 July 2009 (UTC)

Hi- I believe this sandbox version is ready for implementation. Please check it over for us. Thanks --Funandtrvl (talk) 02:09, 6 July 2009 (UTC)

All done. By the way, for future information, did you know that you can enter taskforces 1-10 and they will all prompt you for the categories on the templatepage (although 6-10 won't function in any other way). When you've created all the categories you can then hook them all. This saves renumbering and shuffling them around to get the category prompts which I think you were doing on this sandbox. — Martin (MSGJ · talk) 13:16, 6 July 2009 (UTC)
Of course, I didn't know that!! Maybe you could add it to the /doc instructions for add'l TFs, for future reference, so other editors will know the shortcuts also? Thanks again --Funandtrvl (talk) 16:49, 6 July 2009 (UTC)
I wasn't going to bother, because it's only of use to editors coding the templates for relatively big wikiprojects, and may well confuse others! — Martin (MSGJ · talk) 16:57, 6 July 2009 (UTC)
Q: Please clarify, wouldn't you have to renumber 6-10, anyways, because it's 1-5 in the upper part and then the hook is 1-10? So, do you put 1-10 in the upper part and then renumber 6-10 and put it into a hook after you've created all the categories? The WP South America template will be needing it done too, due to mult. TFs. --Funandtrvl (talk) 17:05, 6 July 2009 (UTC)
To avoid renumbering you could either leave 1-5 in place and just hook 6-10 (without renumbering). Or better still might be to hook all 1-10 and then leave the main 5 available for expansion in the future. — Martin (MSGJ · talk) 07:24, 7 July 2009 (UTC)
Q: Is Template:WikiProject Polynesia/Work group categories not needed anymore? If so, you could delete the pg? --Funandtrvl (talk) 17:10, 6 July 2009 (UTC)
 Done — Martin (MSGJ · talk) 07:24, 7 July 2009 (UTC)

Problem with collapsed sections?

I've just spotted this on the meta doc page:

As you can see, the "More information" text is squashed over on the left hand side. That's not right, is it? (Browser: IE8) PC78 (talk) 19:26, 2 July 2009 (UTC)

Yes, I noticed this as well, since H-M's latest tweak to try and fix the padding on the right image. — Martin (MSGJ · talk) 20:12, 2 July 2009 (UTC)
What do we see in these examples?
This article is within the scope of WikiProject Tulips, a collaborative effort to improve the coverage of Tulips on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Happymelon 13:17, 3 July 2009 (UTC)
On IE8, "more info" and "show" lined up against the left margin. --Funandtrvl (talk) 15:00, 3 July 2009 (UTC)
For all four (now six) examples? They each contain slightly different formatting... Happymelon 15:08, 3 July 2009 (UTC)
Yes, they all look the same. PC78 (talk) 15:14, 3 July 2009 (UTC)
On Chrome, 1-5 look the same and the [Show] is next to the colon. 6 is slightly more squashed and More Information extends to two lines. — Martin (MSGJ · talk) 15:17, 3 July 2009 (UTC)
No, hang on. The bottom one looks good on IE8. PC78 (talk) 15:20, 3 July 2009 (UTC)
Number 6 looks worse on Chrome?!?! That's very wierd... Happymelon 15:23, 3 July 2009 (UTC)
Yes. See the image on the right. And another thing I've noticed on Chrome: the right border of the table does not show. Can you fix this as well? — Martin (MSGJ · talk) 15:30, 3 July 2009 (UTC)
On IE8, 1-5 are by the left margin, example #6 seems ok, "more info" is left-aligned and "show" is right-aligned. --Funandtrvl (talk) 16:00, 3 July 2009 (UTC)
Number 7? Happymelon 21:32, 3 July 2009 (UTC)
#7 shifts everything to the right, 1 space. (IE8) --Funandtrvl (talk) 02:02, 4 July 2009 (UTC)
Number 7 is still crap on Chrome as well. Maybe you could revert your recent edit because it was okay until recently. — Martin (MSGJ · talk) 11:00, 4 July 2009 (UTC)
Which is the lesser evil? :P I agree that, at this stage, it's probably the dodgy right padding. We do need to find a best-of-both-worlds solution, though. Happymelon 11:36, 4 July 2009 (UTC)
Please complete
browser 1 2 3 4 5 6 7 8 9 10
FF3.5 Green tickY Red XN Red XN Red XN Red XN Green tickY Green tickY Green tickY Green tickY Green tickY
IE8 Red XN Red XN Red XN Red XN Red XN Green tickY Green tickY Green tickY Green tickY Green tickY
Chrome 2 Red XN Red XN Red XN Red XN Red XN Red XN Red XN Red XN Red XN Green tickY
I've reverted it. How about options 8 and 9? Happymelon 11:40, 4 July 2009 (UTC)
The reversion has fixed it. 8 looks like 1-5 with a bit more space before [show]. 9 is the most squashed, taking up 3 rows. — Martin (MSGJ · talk) 13:18, 4 July 2009 (UTC)
Indeed, but also reintroduced the image-right-padding problem for IE that we fixed above. Chrome's interpretation of the styles is just wierd IMO; option 7 is almost identical to the boxflow tweak that is used in the mbox templates, which works perfectly in every known browser. For the record, versions 1, 6, 7, 8 and 9 work acceptably on FF3.5. Happymelon 13:33, 4 July 2009 (UTC)

I confidently expect that eg10 works alright (there will be hell to pay if it doesn't!). My question now is, does this banner:

This article is within the scope of WikiProject Tulips...

Exhibit the IE box-model bug, as evinced by the right border, margin, bits-of-the-photo, etc, spilling out the side? Happymelon 15:27, 6 July 2009 (UTC)

Gah, I see it does on IE7 at least. Grrrr.... Happymelon 15:39, 6 July 2009 (UTC)
Yes, and on IE8. There is padding at the top but none on the right. — Martin (MSGJ · talk) 16:55, 6 July 2009 (UTC)

Hmm... I'm reasonably sure that the 'proper' solution to the bug is to use display:block or somesuch, but that seems to break up our precious force-full-width-tables trick. So I've just cheated: I've moved the 1px empty cell to the end of the row, so when IE makes the first cell expand to occupy the full width of the row (essentially the bug is that IE interprets "width:100%" as "be exactly the same width as the parent element" and sizes the object accordingly, but then the over-large object is shifted right by the parent element's left padding, spilling out of the proper space), it just covers what is actually undesirable wasted space. Adding a little bit of padding to the image itself, therefore, we can get a coffeeroll strip to stay on both IE and Firefox:

WikiProject Tulips (Rated FA-Class)
This article is within the scope of WikiProject Tulips, a collaborative effort to improve the coverage of Tulips on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
          This article is within the scope of the following WikiProjects:
WikiProject Tulips (Rated FA-Class)
This article is within the scope of WikiProject Tulips, a collaborative effort to improve the coverage of Tulips on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
This article has an assessment summary page.

Does this work correctly for everyone? Happymelon 17:12, 6 July 2009 (UTC)

Looks fine on both IE8 and FF3.5 here. Orderinchaos 18:25, 6 July 2009 (UTC)
Good! What about the right border of the table (on Chrome)? — Martin (MSGJ · talk) 07:26, 7 July 2009 (UTC)
Is it still missing? I assume the WikiProjectBannerShell underneath it has the border correctly; can you take a screen dump, zoom right in and say how the table edges line up on a pixel basis? Happymelon 10:56, 8 July 2009 (UTC)

 Done I've now implemented the new code. Hope it works ok! Happymelon 15:54, 10 July 2009 (UTC)