This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the
current talk page.
Hmm.. But now when you look at the category, the doc shows up, not the template. It's a minor issue, but could cause problems for bots, etc. Neverminde. :) -- SatyrTN (
talk |
contribs)17:55, 4 September 2007 (UTC)
either i'm missing something or it's still not working? i would think that in
this rev it would be be working… also tried previewing it in that state. 「
ѕʀʟ·
✎」
06:34, 8 September 2007 (UTC)
What's wrong with it? I fixed the extra space that had been appearing below it (did you [[WP:CACHE|clear your cache)?), it looks fine here.
Anomie16:35, 8 September 2007 (UTC)
I went to
this edit, then hit Edit, then previewed my edit.. result is that I don't see "WikiProject Malta"'s banner. But looking again, I DO see 'southern europe' which isn't there in the source. Maybe a bug in the template. 「
ѕʀʟ·
✎」
16:49, 8 September 2007 (UTC)
That was it. Thanks for fixing the break, the latent problem I suppose was that it said 'southern europe' instead of malta in the nested part. I'll re nest it. 「
ѕʀʟ·
✎」
16:52, 8 September 2007 (UTC)
Namely, when class=stub, {{Film}} pops up a custom messagebox above the project banner, which interferes with the proper appearance of the BannerShell; this needs to be handled the same way that the needs-photo=yes, etc., ones are for {{WikiProject Biography}}. — SMcCandlish [
talk] [
cont] ‹(-¿-)›07:31, 10 September 2007 (UTC)
Ahh - that makes more sense! WP:Film decided early on that they didn't want to "hide" any of the stub information. Since each WikiProject creates and maintains their own banner, you'll have to bring it up with them if you have suggestions for how to make it better. Sorry :) -- SatyrTN (
talk |
contribs)20:29, 10 September 2007 (UTC)
Hmm. AN expert eye would be appreciated, this doesn't nest properly, probably an order effect. RichFarmbrough, 10:22
22 September2007 (GMT).
Fixed. The wrong class-printing code was included in the nested header section; I moved that code to an appropriate place, and put the correct code into the header section.
Anomie13:32, 22 September 2007 (UTC)
There is a problem with {{tl:WikiProject Somerset}} or it's operation & I can't work out what it is....
I originally created {{Somerset}} for
Wikipedia:WikiProject Somerset & had advice that is wasn't working properly & didn't "nest" on article talk pages. I also took ages to get it to handle importance ratings. Then {{tl:WikiProject Somerset}} was created & a redirect put on {{Somerset}} and I added a few importance ratings to several articles. The bot has now been round & is displaying the results in relation to class & importance at
Wikipedia:WikiProject Somerset#Current status. In the process we have now lost about 500 articles which had the original banner (including most of the FA, GA & B class) & I can't work out why. Some examples:
{{editprotected}}
perhaps it is supposed to, but is there a reason the code displays:
{{#ifeq:{{lc:{{{blp}}}}}|yes|{{blp}}|}}{{#ifeq:{{lc:{{{activepol}}}}}|yes|<table class="messagebox plainlinks articletalkheader" style="background:#FFFAEF; text-align:center;"><tr><td>[[Image:Attention yellow.svg|40px|left]] '''This page is about an active [[politician]] who is running for office, is in office and campaigning for re-election, or is involved in some political conflict or controversy.'''
Because of this, this article is at risk of [[Wikipedia:Neutral point of view{{!}}biased]] editing, talk-page [[Wikipedia:Trolling{{!}}trolling]], and simple [[Wikipedia:Vandalism{{!}}vandalism]].
</td></tr></table>|}}
I don't know why it doesn't just use {{activepolitician}} like it does with {{blp}}, but the two parameters exist because the
WP:BIO people would otherwise want to keep {{WikiProject Biography}} out of the shell so they could use those parameters there (I don't know why they couldn't just call the two templates directly instead of having another template include them).
Anomie00:59, 19 October 2007 (UTC)
Because I had implemented WPBS on the {{Wine}} WP banner,
Agne27 asked on my Talk page if it's possible to make this "obscenely large" banner default to the collapsed setting even without the "nested" parameter in play. Bueller? Bueller? Anyone? Anyone? —
TAnthonyTalk16:55, 7 November 2007 (UTC)
Really, the two internal show/hide blocks should just default to closed (as they do for other banners); there's no need to collapse the entire banner to the fully-nested state by default.
Kirill18:44, 7 November 2007 (UTC)
Class and Importance over multiple projects
If a page rates 'class = Start' for one project, shouldn't it rate the same for all projects in which it's included?
Do/Should different projects have different criteria for the 'class' attribute?
If not, shouldn't 'class' be set in the WikiProjectBannerShell and inherited? It looks inelegant to have four projects within the bannershell
all saying (Rated Start-Class).
Some projects say that the 'importance' attributes supports whether an article should be included in Wiki 1.0. If that's true, then shouldn't
the 'class' attribute be the same across projects? Alternatively, does it make sense to assign, say,
Eicosanoid a class=Top for Lipid Signaling but class=Low for Chemistry?
David.Throop22:20, 7 November 2007 (UTC)
Answers:
(1) Possibly. That depends on whether one given project adheres to the same standards of others, and that's hard to know. This is particularly a question when it comes to higher rated articles. So, for instance, Physics might rate a given biography article A class, because it is complete so far as they are concerned, but Biography may rate it B for stylistic reasons. It'd be nice if they did all agree, but we can't make them.
(2) Importance varies a lot between projects, depending on the subjects significance to that project.
George Washington almost certainly is not a "Top" priority article for
Wikipedia:WikiProject Agriculture, because his modest importance to that subject does not merit it. Also, not all projects have the same standards for inclusion, rating, etc.
Finally, if this is what you were asking, it would almost certainly be an incredible effort to make this one shell contain the assessment criteria for somewhere over 500 projects. While I would like it if that could be done myself, I can't see that it would be justified.
John Carter22:38, 7 November 2007 (UTC)
Obviously the ratings system is not a perfect science, but while a stub is a stub and a start is a start, many Projects do indeed have their own criteria of sorts for higher-level class ratings. Editors will sometimes run bots to insert ratings for WP banners based on other ratings on the same talk page (usually for stubs/starts); this makes sense and is usually accepted by Projects, but some take issue with automatically assigning ratings this way (I believe WP Bio has a problem with that). I agree that the current ways seems to demand a bit more work and is perhaps redundant/inelegant, but considering the amount of Projects that exist (and the number of editors with opinions that represents), I don't think any effort to consolidate that function (if it's even possible) will be met with universal approval. —
TAnthonyTalk23:43, 7 November 2007 (UTC)
I don't think you can make the individual banners inherit the class from this container template. And if they don't, the entire automatic assessment statistics would be screwed. --
Qyd (
talk)
08:43, 11 December 2007 (UTC)
I fixed up {{WPRT}} so it nests if nonrail=yes, but if not, it transcludes {{WikiProject Trains}} and I can't seem to be able to add nested=yes to that transclusion if nested=yes for the parent transclusion. Sigh. If that makes sense. I know I've done it before, but now I have no idea how, so I'd appreciate it if someone else could take a look at it. ;)
I think I've done what you wanted.[1][2] I was going to do it last month, but I never had time until I gave up on caring about policy ;)
Anomie⚔12:58, 11 December 2007 (UTC)
Template:Oldafdmulti(
|
talk |
history |
links |
watch |
logs) is an example for a banner that is inserted on top of talk pages, just like project banners. It certainly does not need to be expanded all the time - it takes up a lot of prime space for information that is only interesting in rare cases. Could that be included here, or would we need a different template to include all kinds of banners, say
Template:TalkpageBannerShell? If we decide to include such banners here then we would need to change the wording from "This article is within the scope of the following WikiProjects:" to something like "Click here to see more banners, such as WikiProject banners." Does anyone have a better idea to word this? —
Sebastian18:50, 10 January 2008 (UTC)
For now, I'll just add a new parameter {{{text}}}, which allows to change the text that this template displays. {{{text}}} defaults to the current text, so there should be no change. Maybe in the long run we could rename this template, but that's a separate question. —
Sebastian19:06, 10 January 2008 (UTC)
To address both posts, I suggest that it is not in the reader's best interests to try and lump all banners and data into a single instance of a template. There is no real reason for visitors to un-collapse such a template because they don't immediately see anything of interest (that's just human psychology), and you'll probably find the same is true for regular users. Leaving some material out in the open...different shells for different functions...does not impede talk page functionality.
To that end, however, there is significant merit in attempting to forge a single template that can be utilized in a number of different ways. For example, {{TalkpageBannerShell |type=afd |1= }} or |type=project or type=history could display pre-defined title text so there is guaranteed uniformity amongst talk pages (rather than {{{text}}} allowing for any random words to be used). The problem is that templates like {{oldafdmulti}} are used on so many pages that trying to convert would be a significant undertaking, and utilize so many variables that trying to accommodate several such template formats may overbloat any one template. Does that make sense? In any case, this train of thought warrants some additional consideration. —
Huntster (
talk •
email •
contribs)22:47, 10 January 2008 (UTC)
This issue has been discussed before in relation to other non-WP banners, and so far there has been no consensus to expand its scope. The full WP banner info is generally of limited use, but many of the other templates are there to call attention to something and should not necessarily be condensed by default. And even if this is agreed upon, this is a major undertaking as there are many different templates designed in many different ways with many different variables. Implementing WPBS to all WP banners alone was a multi-month long task which involved many editors. And Sebastian, I kind of object to your already making all these changes without any discussion. —
TAnthonyTalk23:16, 10 January 2008 (UTC)
TAnthony, you write "all these changes". I made two changes. Do you see any problem with either one of them, or are you just generally of the opinion that people should first discuss, then change? I used to have that opinion, too (with regard to policies, which I believe should really be more stable than other pages), but then I learned from a well-respected editor that that is not a way to assure that changes are made by consensus
[3]. —
Sebastian23:32, 10 January 2008 (UTC)
Template:Oldafdmulti(
|
talk |
history |
links |
watch |
logs) is a banner that displays information that should not be hidden from view. It already has the option to hide the list of the previous AfD nominations and just displaying a message that the article has been nominated before, with a hide/show option (
example). There is no need to include this in WikiProjectBannerShell. If any, it should be include in ArticleHistory. --
Reinoutr (
talk)
12:00, 11 January 2008 (UTC)
How to adapt a banner?
Per the above, I just tried to adapt {{Oldafdmulti}}, which has a show/hide feature, but I couldn't get it to work. I took
this as a reference, but I don't understand it: It seems to me, Shinhan was adding a new row to the table, but how can that addition lead to there being less displayed? —
Sebastian19:40, 10 January 2008 (UTC)
Problems with older safari browsers
Hi - I've just realised that the reason so many navigation templates and WikiProject banners seem to have disappeared from Wikipedia in the last few months is that they haven't gone - I've just been unable to see them. With the combination of browser and platform I (and presumably other) WP editors use (Mac OS 10.2.8/ Safari 1.0.3) the shell renders all templates within it as thin, unexpandable lines. Is there any way to fix this so that I don't have to physically edit the article to see what templates are on it?
Grutness...wha?23:57, 10 January 2008 (UTC)
Exactly right. I came here because this is one place that I knew for a fact used these shells. I've seen them elsewhere, but don't know where they originate from. As to the problem itself, here's a screenshot:
If it is a problem with all uses of "collapsible", try asking at
MediaWiki talk:Common.js. If that is the case, I suspect the problem is on line 126 of the current version as I remember hearing that particularly old versions of Safari do not correctly support the table "rows" collection. Here is a test table, if this exhibits the problem then it is almost certainly the case that that the problem is with "collapsible":
The {{AfricaProject}} banner now assesses separately for most of the countries of Africa, as shown on that template. Is there any way to adjust the shell to mention the names of the various relevant subprojects as appropriate?
John Carter (
talk)
01:46, 21 January 2008 (UTC)
Sure. Each banner decides how and what to display in it's "one line", so the banner can display whatever. Look for the line that says:
Very strange; your response prompted me to go to another computer in my house, where I see no problem. On my laptop, the nesting and show/hide aren't working. I'll restart and see if that fixes it.
SandyGeorgia (
Talk)
02:05, 29 January 2008 (UTC)
Still not working. No show/hide on article history, and no nesting in banner shell. But since it works on my other computer, it's not a problem with the template. <shrug>
SandyGeorgia (
Talk)
02:10, 29 January 2008 (UTC)
Easiest way to figure it out is to remove templates one by one until the problem goes away. It looks fine to me, unfortunately, so I'm not sure what the technical symptoms are; could you perhaps take a screenshot of the broken layout?
Kirill02:56, 29 January 2008 (UTC)
By trying every possible combo, it's definitely in the BannerShell. If I remove the Banner, articlehistory goes back to normal. If I remove everything on the page except the BannerShell and the Articlehistory, they are both messed up. If I leave only articlehistory, it's fine. If I remove peer review only, they are both messed up still. BannerShell, even when the only thing on the page, is not nesting. Please don't go to too much trouble over this; I'm not getting along with my new laptop yet.
SandyGeorgia (
Talk) 03:03, 29 January 2008 (UTC) Oh, forgot. I don't know how to do screenshots, but all the WP templates run together with no nesting, no separation.
SandyGeorgia (
Talk)
03:04, 29 January 2008 (UTC)
I would suspect some problem with one of the templates inside the banner. Might have some part of the code not nested right when the template is nested. Could you try removing those so fixing it won't be looking for a needle in a haystack?
Gimmetrow03:10, 29 January 2008 (UTC)
In the future (I know there has been a previous suggestion with no concensus reached) but if such a proposal is to be suggested again, and if there will be a merger, how will all the articles with the other template be fixed? Will it be automatic once the redirect is in place? Would a bot be capable of doing it automatically for each article? I previously used to add the older template to articles until I found out about this template (as I believe this one is better).. anyway I would hate for someone to have to change from one template to the other manually as I am sure there would be hundreds of thousands of articles with either templates.
Calaka (
talk)
18:12, 5 February 2008 (UTC)
That kind of change could easily be made by a bot or even AWB, but I seriously doubt a consensus to merge will ever be reached on this one. —
TAnthonyTalk19:32, 5 February 2008 (UTC)
Thank you for the reply. At first it seemed a bit difficult (but I am not that good with programming so there is no knowing what a bot is capable of doing). Hmmm I am not sure whether there are more people who prefer this one or the later, but I think it would be best if in time only one was used for consistancys sake... Anyway I guess it will sort itself out when someone else brings out a vote to deleter/merge one or the other. Cheers!
Calaka (
talk)
04:08, 6 February 2008 (UTC)
We had a major effort to implement this template months ago, with the result that this template was in use on exponentially more Talk pages than {{WikiProjectBanners}}; however, I know from experience that the supporters of that template feel as strongly as we do, and really really hate it if you try to replace theirs with this one, LOL. With the huge amounts of articles on WP, I think there's room for two alternate shells. —
TAnthonyTalk04:20, 6 February 2008 (UTC)
I feel like we've discussed this before, but I can't recall the outcome: is it appropriate for us to add the {{WikiProjectBannerShell}} code to the project banner samples at
Wikipedia:WikiProject Council/Guide/WikiProject? There don't seem to be a lot of non-compliant banners created these days, but these samples are used by those that are created (I've been asking). I don't necessarily want to make that page more complicated and yet, since we're updating all banners without asking their creators anyway... —
TAnthonyTalk17:22, 29 February 2008 (UTC)
I would say, definitely yes. The WPBS nested code has become a de-facto standard across all WikiProject Banners - I don't think anyone has ever disputed its addition to a banner. So yes, add the code to the examples. I've been meaning to make a more public link to {{
WPBannerMeta}} there as well...
Happy‑
melon09:55, 8 April 2008 (UTC)
No, we should not merge them, and the collapsible should be removed. There has been much debate about this, we have two for the two different purposes, and this one was designed as the longer one.
SandyGeorgia (
Talk)
22:45, 26 March 2008 (UTC)
I think
this probably fairly adequately explains why I made that change. Nonetheless, I have reverted as requested. I am fully aware of the two separate templates, and I have never had any satisfactory explanation as to why we need separate ones when one, with suitable options, will quite adequately suffice. It's probably best to respond to this rhetorical question at the TfD, if anywhere.
Happy‑
melon22:56, 26 March 2008 (UTC)
From a technical standpoint, there's not much difference between {{WikiProjectBanners}} and {{WikiProjectBannerShell}} with a fully-collapsed option; given the way the parameters on the former work, it wouldn't even be necessary to change the calls themselves, since the functionality could be done through a meta-transclusion.
Kirill23:25, 26 March 2008 (UTC)
(outdent) Also from a technical standpoint, there's no reason *not* to keep the "collapsible" option on this template. I'd like to suggest bringing it back. -- SatyrTN (
talk /
contribs)01:13, 27 March 2008 (UTC)
Agree, no reason not to have the added function, as it is entirely optional, and it doesn't change anything in the already transcluded instances. Please add back optional "collapsed" parameter. --
Qyd (
talk)
19:32, 28 March 2008 (UTC)
WikiProjectBannerShell|1=|blp=yes breaks the template's display
Lately, adding the |blp=yes directly after |1= makes the projects not be displayed any longer (happened on
Talk:Donald Patriquin). {{WikiProjectBannerShell|blp=yes|1= works, also adding |blp=yes after all the project banners works. This used to be different and should be fixed IMHO.
BNutzer (
talk)
16:01, 28 March 2008 (UTC)
That's entirely natural, and completely unavoidable. Think about what's going on. All the project banners are being assigned to the first parameter. The |1= is to ensure A) that the equals signs in the template calls don't screw up the template, and B) that whitespace is stripped from around the templates. If you put |blp=yes straight after |1=, then you're assigning nothing to the first parameter, and all the project banners (as well as "yes") to the blp parameter. I think you must be mistaken about this working before because there's no way I can think of that this functionality could ever have been provided without the displays of phantom "yes" quotes in wierd places.
Happy‑
melon16:08, 28 March 2008 (UTC)
You appear to be much more knowledgeable about how the code works than me. I was sure I had used it differently before, but I guess I am mistaken there. My apologies for the false alarm then.
BNutzer (
talk)
19:16, 28 March 2008 (UTC)
I was also unaware of the significance of order in this respect. I think a lot of people have no understanding of what the |1= actually does, so if it isn't emphasized anywhere that this must be the parameter sequence, perhaps it should. __
meco (
talk)
12:20, 2 April 2008 (UTC)
As I just implemented the shell on
Talk:Rudolf von Sebottendorf I experienced that the WP Germany template would not format correctly when placed last in order. When I moved it up in sequence, it now works fine. Perhaps someone can try and replicate this to see if there is a bug in that particular template's code. __
meco (
talk)
12:17, 2 April 2008 (UTC)
Wow, that's a tough one! I've spent ten minutes on it, but I have no idea what's wrong. Fortunately there seems to be an easy fix - just move the banner up one!
Happy‑
melon15:51, 3 April 2008 (UTC)
This article is within the scope of WikiProject Mexico, a collaborative effort to improve the coverage of
Mexico 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.MexicoWikipedia:WikiProject MexicoTemplate:WikiProject MexicoMexico articles
This article is within the scope of
WikiProject Mesoamerica, a project which is currently considered to be inactive.MesoamericaWikipedia:WikiProject MesoamericaTemplate:WikiProject MesoamericaMesoamerica articles
This article is within the scope of
WikiProject Mesoamerica, a project which is currently considered to be inactive.MesoamericaWikipedia:WikiProject MesoamericaTemplate:WikiProject MesoamericaMesoamerica articles
This article is within the scope of WikiProject Mexico, a collaborative effort to improve the coverage of
Mexico 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.MexicoWikipedia:WikiProject MexicoTemplate:WikiProject MexicoMexico articles
Problems like this are almost always caused by extra linebreaks in the template code, which result in paragraph breaks when combined with other templates in certain orders. Playing around with the code to remove newlines usually fixes the problem, as I did
here.
Happy‑
melon16:32, 5 April 2008 (UTC)
Converted to WPBannerMeta, thereby solving the many problems with the banner (including non-categorisation into
Category:WikiProject banners, lack of |small= and |nested= functionality, poor formatting and substantial additional whitespace :D).
Happy‑
melon20:20, 9 April 2008 (UTC)
It looks like your changes were reverted by a project member. May want to check back, but it is nesting properly. -MBK00420:23, 9 April 2008 (UTC)
(edit conflict x2) With respect to Happy-melon, I replaced the template with custom code...they simply aren't at that point of needed complexity yet (they don't have a WP image or subcategories yet). As they grow, the code can adapt or they can move to the template. I will be leaving a note on their project talk page advising of the change, and will provide any requested code support in the future. —
Huntster (
t •
@ •
c)20:24, 9 April 2008 (UTC)
Of course no one is going to force them to use WPBannerMeta, although I'd note that the current appearance could be exactly duplicated in rather fewer lines of code using the banner. As you say, as and when they need more functionality (particularly the class/importance assessments) I'd encourage them to use the meta-template. Regardless, the nested, small and whitespace issues have been fixed, and that's the most important thing.
Happy‑
melon20:57, 9 April 2008 (UTC)
Some projects put a review in a comments subdirectory
I have discovered that some projects are putting their assessment notes in a subdirectory called Comments. I have no idea where this originated or where to ask questions about that. Anyway, I am here because I have a suggested improvement to this template.
The problem is that if the project banner is closed within the shell, the reader will not see the comments. I suggest that this template displays the comments if there are any. See
Talk:Hastings for an example where I have simulated the result.
MortimerCat (
talk)
01:19, 14 April 2008 (UTC)
I think that this will create substantial and unnecessary levels of clutter on the talk page - the banner shell was originally created to reduce the amount of space taken up by talk-page messages, not increase it by transcluding extra content. Most of the project banners, particularly the one the comments were written for, will have functionality to display the comments within the (collapsible) banner, creating redundancy. Additionally, if there are headings within the comments section, the talk page ToC will move inside the banner shell, requiring a manual fix to correct. Without knowing how many of the 43,000 pages using WPBS would have this problem, I don't think it's a good idea to incorporate this functionality.
Happy‑
melon08:23, 14 April 2008 (UTC)
I like the idea, and it would be easy to implement, but how about another approach. Rather than having the comments directly displayed in the banner shell, simply link to the Comments page. Consider how the {{documentation}} template decides whether or not to show that a template has a sandbox...a sort of "If /Comments page exists, display link." Would not unnecessary clutter those pages that don't have comments, but makes it easy for editors to see that they exist if they do. Very minimal real estate for what some consider valuable material. Should be simple to code. —
Huntster (
t •
@ •
c)10:25, 14 April 2008 (UTC)
I agree, displaying the comments is negating why the shell is there in the first place. As Huntster suggests, I am replacing the ones I have added, and replacing with a note Expand banners to see assessment comments to indicate that comments are available. It would be nice to have t automated though.
MortimerCat (
talk)
19:57, 14 April 2008 (UTC)
Okay, for the perusal of interested parties, I've coded this functionality at
User:Huntster/Sandbox (
diff); and you can see how it would look
here. Everything seems to test out fine. Minimal real estate when in use, and nothing looks different when not in use. Thoughts? —
Huntster (
t •
@ •
c)11:54, 15 April 2008 (UTC)
{{editprotected}}
Okay, since there's been no additional comments on it, may I get an admin to replace the code with
this diff? As previously stated, it takes up very little real estate while still conveying the requested information, and does not show if there are no comments. —
Huntster (
t •
@ •
c)23:33, 7 May 2008 (UTC)
WikiProjectBannerShell and BLP notice (for Template:WikiProject Biography request, see
this)
The living=yes parameter in Template:WikiProject Biography posts a BLP notice on the talk page. There probably is more than 100,000 articles tagged with {{WikiProject Biography|living=yes}}. When Template:WikiProject Biography is in WikiProjectBannerShell, the BLP notice is hidden. To overcoome this, some people additionally use {{WikiProjectBannerShell|blp=yes}} Also, some people add {{BLP}} to WikiProjectBannerShell to overcome the hidden BLP problem. See
Talk:Eduardo Maruri as an example. While |blp=yes or {{BLP}} may be a solution, they seem redundant to the long used {{WikiProject Biography|living=yes}}. Is it possible to change Template:WikiProject Biography and/or WikiProjectBannerShell so that the BLP notice is not hidden when Template:WikiProject Biography is in WikiProjectBannerShell? Doing so would eliminate a need to use {{WikiProjectBannerShell|blp=yes}} on the 100,000+ articles now using {{WikiProject Biography|living=yes}}. Idealy, the living=yes parameter in Template:WikiProject Biography should cause the BLP notice to appear outside and above WikiProjectBannerShell, if possible. Thanks. --
GregManninLB (
talk)
15:31, 6 May 2008 (UTC)
The last option (adding |living=yes to {{
WikiProject Biography}} resulting in the BLP notice displaying outside the banner) is impossible without using a lot of messy javascript. It would be possible to cause the BLP notice to display even when the template was collapsed inside WPBS, but that would still look messy, particularly as the BLP notice is not a WikiProject banner and so should not be shelled with WPBS. The BLP notice does not actually belong inside the banner shell at all. I think that the only effective way of doing this would be to encourage the use of |blp=yes in WPBS as well as|living=yes in WikiProject Biography. Once this system is widespread (by which I mean universal :D we could alter {{
WikiProject Biography}} to not display the BLP notice when |nested=yes is also defined (since it would be duplicated by the notice over WPBS) but still add to the relevant categories.
Happy‑
melon18:14, 6 May 2008 (UTC)
I'm actually in the process of upgrading WPFISHING now. I'll take a look at the other one when I have time. —
Huntster (
t •
@ •
c)22:06, 8 May 2008 (UTC)
I just made some changes to how this template displays nested banners to fix some problems in IE. If you see problems in any browser, do a
cache clear refresh first and see if that fixes it. Hopefully people using IE will now be able to see nested banners without them going partially out of the parent shell. If you see any templates or talk pages that are messed up because of this please let me know immediately and I will be happy to look into it. --
CapitalR (
talk)
22:32, 8 May 2008 (UTC)
You've done it again! Excellent work: the way the banners fall off the right-hand-side of the shell in IE7 was something I thoughth I'd just have to live with... my faith in humanity's ability to solve all the world's problems is restored :D.
Happy‑
melon08:25, 9 May 2008 (UTC)
Yup, this was a tricky one. I'm a Firefox user myself, but had always felt sorry for those IE users having this template look funny, so I finally got around to fixing it for them. I'm rather surprised that it worked so smoothly and didn't have any unintended effects. Let's hope it stays that way.... --
CapitalR (
talk)
12:40, 9 May 2008 (UTC)
For me, I'm seeing an empty space in the last line of the shell. It looks as if it is missing a project or something, just a large blank area. Any way this can be fixed to compress only the projects with no black space like it was before? –
Nurmsook! (
talk)
17:56, 11 May 2008 (UTC)
Two questions: what browser are you using, and can you give me an example of a page where this occurs? It seems to look fine in the browsers I have tested it on for most pages. Also, please
bypass your cache to see if that fixes it (Firefox=Ctrl+Shift+R, IE=Ctrl+F5). If it persists, could you also get me a screen shot? --
CapitalR (
talk)
18:00, 11 May 2008 (UTC)
I'm using Internet Explorer and it's occuring on all pages that use this shell (ex:
Talk:Eric Brewer (ice hockey)screenshot), including the template page itself
screenshot. I tried bypassing my cache twice and it has no effect, so I'm thinking it must be something in the script that got altered from the past two edits made to the template, as this was not occuring prior to these edits. –
Nurmsook! (
talk)
20:16, 11 May 2008 (UTC)
Great, thanks for the screenshot. I can't exactly tell what was wrong, but I think I fixed it, so let me know if everything is looking right for you now. It might take an hour or so for the job queue to get flushed and all of the changes to propagate to the talk pages, but I think it should be working properly now. Let's hope there were no side effects. Sorry for the trouble! --
CapitalR (
talk)
21:02, 11 May 2008 (UTC)
The {{tmbox}} is the new ambox/mbox compatible meta-template for talk page message boxes. We are thinking of making the {{tmbox}} work with the {{WikiProjectBannerShell}}. Comments and advice from you who made / take care of / are interested in the {{WikiProjectBannerShell}} would be appreciated. See discussion at
Template talk:Tmbox#Sizes / modes / shapes.
There's a discussion about a minor (but very noticeable) formatting change going on
here, which doesn't seem to be attracting very much interest; any comments from this page would be welcome, as the two are fairly similar. I dislike the change for reasons explained there; in fact I would like to propose that we add the "click show for further details" to WPBS, when the |collapsed=yes parameter is set (obviously telling viewers to click show when the banner is expanded is rather silly). It would make the banners more similar without disrupting the vast majority of instances (where WPBS is expanded). Thoughts?
Happy‑
melon08:31, 14 April 2008 (UTC)
I'm all for it, as long as the "click show..." isn't put on a new line. As with the other template, the new line for those 5 words is not necessary, and just makes the box waste vertical space on the page.
Equazcion•✗/
C •08:42, 14 Apr 2008 (UTC)
I would be against this change (that is, if I'm reading correctly, to slim the bar down to *just* the text "This article is within the scope of multiple WikiProjects"). One of the points of this shell is to minimize the footprint of the banners while still showing useful information. In this case, we get to see which banners are there and, typically, what class the article is rated, while still getting getting rid of all the 'useless garbage' in the full banners. I, for one, like seeing this information up front without having to waste effort clicking on linktext. —
Huntster (
t •
@ •
c)09:39, 12 July 2008 (UTC)
Are you sure you aren't thinking of {{WikiProjectBanners}}? This template doesn't have any "click [show]" text on a separate line...just a single "[show]" beside the collapsed title text.
I'm obviously an idiot for not paying attention to the black and white text above. You are talking about adding text that says "Click [show] for further details." or somesuch, correct? While not hard to implement, I question how "[show]" can be ambiguous in this situation. —
Huntster (
t •
@ •
c)10:50, 12 July 2008 (UTC)
Okay, everything should be fixed. The top and bottom banners had whitespace issues. Basically, if there is whitespace inside the banner box, it will not be a problem with this template, but with one of the banners. Just leave a message here if you see this again and someone will check it out. —
Huntster (
t •
@ •
c)15:04, 16 July 2008 (UTC)
I know it's not technially a wikiproject, but the banner functions in pretty much the same way, and show the same kind of information. Tucking it into the shell seems like a good idea.
Ed Fitzgerald (unfutz)(
talk /
cont)22:16, 21 August 2008 (UTC)
I just tested {{WP1.0}} on Talk:Frankenstein and a couple of other places, and it seems to work fine. The current template, {{V0.5}}, seems to work as well. Can you make sure it is still erroring for you? —
Huntster (
t •
@ •
c)03:35, 22 August 2008 (UTC)
Yeah, that was me, sorry, I have real problems remembering the correct format for that parameter -- what does it do, incidentally, is there something about its function that would help me to remember it? Also, although the parameter for the template is correct on WPBS on the LotR article, now it doesn't seem to have a show/hide link. Is there a reason for that?
Ed Fitzgerald (unfutz)(
talk /
cont)02:23, 23 August 2008 (UTC)
The way templates work, if you call the template as {{template|foo}}, then when the template is expanded the parameter {{{1}}} (the "first unnamed parameter") is replaced with foo. So what if you want that "first unnamed parameter" to be replaced with bar=foo (or anything else containing "=")? If you call the template as {{template|bar=foo}}, the parameter {{{bar}}} is replaced with foo, and {{{1}}} isn't replaced at all. The solution is to specifically name the parameter: {{template|1=bar=foo}}. Since all WikiProject banners will have at least 1 "=" in their template invocation (for the "", if nothing else), the "1=" is effectively mandatory for {{WPBS}}.
Anomie⚔03:40, 23 August 2008 (UTC)
Thanks. It seems to be something in my Wikipedia set up. If I log out and look at the page, the show/hide button is there, same with using my wife's account. My account, however, on my computer or hers, does not show the hide/show button. I guess I'll root around a little and try to figure out what;s causing the problem.
Ed Fitzgerald (unfutz)(
talk /
cont)14:52, 23 August 2008 (UTC)
OK, here is the problem. If I have the switch "Open external links in a new tab/window" in "Preferences / Gadgets / User interface gadgets" turned on, the show/hide button on WPBS on
Talk:The Lord of the Rings disappears (as does my UTC clock, also set by a gagdet switch) if I have included
Template:ME-project in the shell, or if the "class=" parameter in
Template:Children'sLiteratureWikiProject has a value in it. If I turn off that switch, disabling new windows for external links, the UTC clock and the show/hide button return. Sounds wierd, but I've confirmed it on another computer. This is using IE7 under Vista.
Ed Fitzgerald (unfutz)(
talk /
cont)19:45, 23 August 2008 (UTC)
Hrm... I see both of those templates include a broken link in their output (to http://en.wikipedia.org{{localurl:Talk:The_Lord_of_the_Rings/Comments|action=edit}}), and IE7 throws a jscript error when trying to do much of anything with those link's href property. Sounds like a bug in IE7 with not handling screwed-up links correctly.
Also, BTW, I see someone changed that talk page from this template to the (unattractive, IMO) {{wpb}} shortly after your edits. Does it still stop your clock now? I suspect it does.
Anomie⚔21:31, 23 August 2008 (UTC)
Fixed with
this diff. The "noinclude" tag must always be on the same line as the last line of included code, though it is another mystery why this didn't always manifest with that template. Oh well. —
Huntster (
t •
@ •
c)20:05, 1 September 2008 (UTC)
Can this template be centred like other talkpage headers? (I'd do it myself, but I wanted to make sure first that there wasn't some already discussed rationale for this.) -
jc3703:20, 19 September 2008 (UTC)
Can you post a screenshot? Talk:Red hair looks fine for me (with Mozilla Firefox.) Also try logging out of wikipedia: if that makes a difference, is it is a clue to the root cause. --
Hroðulf (or Hrothulf) (
Talk)
09:50, 19 September 2008 (UTC)
After reboot, ctrl+F5, etc., it still has this issue.
It displays as left-aligned. But the talkheader shows as centered. Is there a difference between how the two are formatted? -
jc3710:06, 19 September 2008 (UTC)
jc37: You must be using some really old browser. What you describe is exactly what I see when using my Internet Explorer 5.5 (from 2001 or so). But I don't see it in any of my other browsers. Its the "messagebox" CSS class that use "margin: auto" which old browsers don't understand, so those boxes become left aligned in older browsers. We fixed the problem in the "tmbox" classes, used in for instance {{tmbox}}. So tmbox based boxes look good in all browsers.
However, there is more to this! I took a look at
Talk:Red hair with my IE 5.5, and what was really intriguing was that the {{talkheader}} was centred! Now that was strange since it uses the old "messagebox" class. So I investigated. You re-relearn something everyday... It has an old HTML setting ' align="center" ' that makes it centre even in the old browsers. So since that is neat and works well until we have upgraded these boxes to use the tmbox classes I took the liberty of adding the align="center" to {{WPBannerMeta}}, {{WikiProjectBannerShell}} and {{WikiProjectBanners}}. So now even jc37 will see these boxes centred in his ancient browser. :))
With AOL 9.0 under Windows Vista, the show/hide option isn't shown and all banners are displayed. Things seem to be fine under IE 7.0, Firefox 2.0 and Safari 3.1.2. The problem just developed recently. Any thoughts? Ed Fitzgeraldt /
c20:00, 1 October 2008 (UTC)
I'm absolutely baffled by this one. I utterly hate the meta template (no offense to its fans...hand-coding is easier to customise and is for me to troubleshoot), but in this instance, I cannot find anything that is out of place. —
Huntster (
t •
@ •
c)10:42, 3 October 2008 (UTC)
Could you please change {{#ifeq:{{lc:{{{collapsed|}}}}}|yes||un}}collapsed to {{#ifeq:{{lc:{{{collapsed|}}}}}|yes|collapsed}} (there is no uncollapsed class) and cellspacing="4px" to cellspacing="4" (HTML attributes never include px)? Sorry for not asking everything at once, and thanks. —
Ms2ger (
talk)
17:17, 3 October 2008 (UTC)
Thanks for your help! In CSS (and thus style attributes), a length has to be followed by a unit identifier, e.g. px[4], while in HTML attributes, integers are used for pixels
[5]. IMO, MediaWiki should check that, but I suppose I'd have to code it myself to get it through. —
Ms2ger (
talk)
18:42, 3 October 2008 (UTC)
And even then your patch would sit there for two years, on the basis that "we aren't accepting any more style changes for the time being" or something similar. [view source for further comment]. — SMcCandlish [
talk] [
cont] ‹(-¿-)›13:27, 4 October 2008 (UTC)
Just a clarification: The align="center" code is only needed for templates that use the old "messagebox" classes. Or more precisely, any tables that use "auto" for the left and right margin to center themselves need the align="center" code, since older browsers don't understand "auto". The mbox classes instead use "10%" for both the left and right margin to center themselves.
SMcCandlish: Nope, they are two different things. When the align="center" is used in the <table> tag it centres the whole table on the page. While style="text-align:center;" centres the contents of the table within the table.
Can I just have a sanity check, please: it is just me that sees one of the banners misplaced slightly inside the shell template on
Talk:American football?? It only appears when I'm logged in to this account, and not when I'm logged into my alternate account, even though that account uses exactly the same CSS and JS as this one... :SHappy‑
melon17:14, 3 October 2008 (UTC)
I too took a look at
Talk:American football using all three of my browsers (FF 2, IE 5.5 and Opera 9.02). I see the same thing in all three of them: That is, the outer templates such as the "important note" etc. varies in the placement of their left border with 1px. And that is normal since some of them use the "messagebox" classes and some use the "tmbox" classes. But to me all the banners inside the bannershell are perfectly aligned. In spite that they use different classes. (Most of them use the "messagebox" classes, but {{WikiProject American football}} uses {{WPBannerMeta}} that uses the "tmbox" classes.) So if you see one banner with 1px difference in the left border it should be the {{WikiProject American football}}, even though I don't see it.
But yes, too much template coding combined with CSS coding is likely to make you insane. Or perhaps we already were insane since we dared to try to code and understand this stuff? :))
When logged in as
Happy-melon, I see
this, but when logged in as
Also-Happy-melon or logged out, I see
this. The only difference that I can think of is that the
MediaWiki:Sysop.js javascript is loaded on my admin account but not the others. But Ms2ger says he gets it and he's not an admin. This above anything else is what confuses me - the effect is constant on both my browsers and regardless of which order I view and review the page. I think the only thing left to say is, WTF?!!
Happy‑
melon21:40, 3 October 2008 (UTC)
And I am an admin but I don't see that problem, no matter if I am logged in or not.
I took a look in your /monobook.css and /monobook.js and I can't see anything there that should cause it. But you should perhaps anyway try to blank them both and see what happens. (I assume you know you then have to wait some minute and then
bypass your browser cache to see the difference.)
But at least it is the {{WikiProject American football}} that is smaller for you, just as I expected. But still, why don't the rest of us see it? So yeah, WTF?!!
Strike that. I just realised I have not bypassed my own browser cache for a while. So I tried that, no change. Then I tried to purge the page and now I see the misalignment, both when logged in and logged out. And I see it in all three of my browsers now. So you should try to purge the page from both your browsers and then I expect you to see it in both your browsers.
The next thing is to fix the problem. Why is there a height="0" in the table header of {{WPBannerMeta}}? I don't see any good reason to have that there and it might cause some problems.
When I first wrapped the content in a subtable, the outer table 'blew up' in vertical height when not nested (and when using the CSS tricks that are currently decaching to hide the header row). I can't remember which browser - I think it might have been FF2. Using the marvelous WebDeveloper plugin for firefox I've found that applying the CSS rule
.wpbs-inner.tmbox{margin:3px0px0px1px;}
corrects the display in FF2, so if this rule works consistently we could add it to
MediaWiki:Common.css until such time as we've converted all the banner templates to use tmbox. I haven't checked (or even seen) what the effect is when multiple tmbox-based banners appear in the same shell. I have to go to sleep now so can't test further.
Happy‑
melon22:39, 3 October 2008 (UTC)
Hi David, i've been away a bit, and it seems you are still working on all this templatebanner mess, so i figured you would know best where to look. As of recently, i'm seeing
this problem with the wikiprojectbannershell on Safari 3.1. Can you help pinpoint the problem ? non tmboxed banners do not have this problem. --
TheDJ (
talk •
contribs)
13:58, 21 October 2008 (UTC)
Could you point to the page here at Wikipedia which you took that example from?
And it really is
User:Happy-melon who is working with those templates, not me. He has been doing a lot of code changes lately and I am not up to date with his changes. And he has Safari, while I can't run Safari on my operating system.
I don't have Safari, actually, which explains why I haven't seen this issue before. I echo DG: I need to know what the code looks like that produced that output for you.
Happy‑
melon16:47, 22 October 2008 (UTC)
I looked around a little since TheDJ has not yet responded. I see the problem when I use my slightly old Opera 9.02 and look at
Talk:International Space Station. I don't see the problem with my Firefox 2 and not with my Internet Explorer 5.5. The cases I have found that has the problems use {{WPBannerMeta}} inside {{WikiProjectBannerShell}}. I have not had time to look closer at the code, and I might not have any spare time for a week now or so.
The problem is almost certainly (read probably definitely!) with the tmbox classes rather than WPBannerMeta per se, but I'll consider all options, naturally! Can you (TheDJ and DG) take a look at
this sandbox and tell me what you see?
Happy‑
melon15:54, 23 October 2008 (UTC)
Happy-melon: In the sandbox you linked to, when I use my Opera 9.02 I see the following banners being only as wide as their text content: Discworld, Aerosmith and Foo. The others (including the "trivial" one) have 100% width.
Hmmmm... I've just downloaded and installed Opera 9.02 from the opera.com archives, and it renders both pages entirely correctly! How bizzarre! I might try Safari just to be certain. Good idea to move this to TT:WPBM btw, go ahead with that.
Happy‑
melon17:01, 23 October 2008 (UTC)
Well, you and I don't have the same operating system, and my Opera has been auto-updated up to that version number. So there might be some differences. But still, yeah bizarre indeed.
Safari 3.1.2 under Wine shows only Biology and Buddhism full-width, even the trivial tmbox is partial width. It's not specific to this template, or even Wikipedia, though. This exhibits the same thing:
In the normal case for Safari the cell with width=100% is forcing the table to its maximum size (but only if that dummy cell is present!), the margin setting never forces the table to expand. When the table is inside another table with width=auto, that 100%ing doesn't happen, probably because the outer table doesn't have a width to take 100% of in Safari's model. If I add an explicit width=80% to the outer table in the above and remove the colspan (by inserting a dummy cell in that row to match the dummy in the first row, Safari has other problems with sizing colspanned rows too), it suddenly works as we want in Safari.
Anomie⚔01:47, 24 October 2008 (UTC)
I'm not surprised that it worked when you added an explicit width to the outer table, but I am surprised that this is not a more widely-known issue. Surely all our mbox templates must collapse in this fashion? What does
That looks fine, of course. But both of these look wrong:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
A short piece of text
A short piece of text
It's only when the mbox is inside a table with width=auto (or inside a colspanned cell no matter if the table has a width specified or not) that Safari screws it up.
Anomie⚔00:06, 25 October 2008 (UTC)
That's concerning, and seems insurmountable, unless you have any clever ideas, DG. I think a fix would be to change the .mbox-inside .tmbox declaration to:
.mbox-inside.tmbox{/* For tmboxes inside other templates. */margin:2px;width:100%;}
Given that we're never going to have boxflow issues within the WPBS template! Does adding this code to your monobook solve the issue, Anomie?
Happy‑
melon08:30, 25 October 2008 (UTC)
I did a little testing some day ago with the 80% wide ones, but gave up for now. As I reported before my Opera 9.02 also has these problems, but my testing showed that it has slightly different problems from what Anomie reports for his Safari...
Oh, you are right Happy-melon. We probably shouldn't waste our time to try to fix the 80% wide case, since that is just the old temporary case. Since we are planning to make them 100% wide. And making it work for 100% width is probably much simpler. I think your code above will work.
Anomie: The code that Happy-melon shows above doesn't work for the {{WikiProjectBannerShell}} at the moment, since it doesn't use the "mbox-inside" class yet. (We are going to add that class later.) But you can test it in your sandbox by adding that class to the surrounding table.
I'll try to squeeze in some time to fix so also the banners that use the old "messagebox" class become 100% wide automatically, as we do for the ".mbox-inside .tmbox". I think all we have to do is to add something like ".mbox-inside .messagebox," to the ".messagebox.standard-talk { }" declaration in
MediaWiki:Common.css. But we'll have to test that carefully first of course.
When I download the page and all related JS/CSS files and just edit things locally, adding width:100% to the rule does fix the width issues. But on both Safari (in Wine) and Firefox 3, the tmbox boxes then all seem to be shifted right 2 pixels from being centered; both browsers size the banner to 100% and then apply the margin setting. Changing to margin:2px 0 fixes that.
Anomie⚔13:20, 25 October 2008 (UTC)
Anomie: Oops, I was wrong about the "mbox-inside" class, it is there in {{WikiProjectBannerShell}} again.
Everyone: I tested the code that Happy-melon suggested above, and it works fine in all three of my browsers: Firefox 2, IE 5.5 and Opera 9.02. I also see some minor margin problems just like Anomie describe. But just as Anomie found out, changing to margin: 2px 0 0 0; fixes it for all my browsers too.
I have tested the code above, and it seems to work fine in all three of my browsers. The reason I use ".wpbs-inner .messagebox," above, instead of ".mbox-inside .messagebox,", is that there might be some cases where a "messagebox" is used inside certain image boxes that has the "mbox-inside" class. If we use ".mbox-inside .messagebox," then those messageboxes will become talk page brown on those image pages.
Shouldn't that second code block have the comment before the selectors or after the {? I seem to remember a change recently that moved all comments from out of the middle of selectors because of some b0rken browser choking on it.
[6]Anomie⚔14:11, 26 October 2008 (UTC)
Anomie: Right, I was the one who noticed that problem and fixed it in
MediaWiki:Common.css. And I didn't add those comments to my code above, it was Happy-melon who sneaked them in. (I have now restored my code above to what I wrote.)
Happy-melon: Please stop editing and breaking my comments. You have done this before, and it is getting annoying. (Last time was much worse, when you totally messed up my table at the Village pump about the image namespace change.
[7]) The least thing you could do is to state in your comments when you have done changes to our comments. But really, stop altering other people's talk page comments.
Everyone: I have done some more thinking and testing of the CSS code for this, and have some improvements:
First change is to use Anomie's suggestion from above to just use "margin: 2px 0;" instead of "margin: 2px 0 0 0;". Both margin settings work, but I think the "margin: 2px 0;" looks better in the browsers I have.
Second change is a more correct selector for the "nested-talk" code. Here is the new code:
.mbox-inside.tmbox{/* For tmboxes inside other templates. */margin:2px0;width:100%;/* Fix for Safari and Opera. */}/* For old WikiProject banners inside banner shells. */.mbox-inside.standard-talk,.messagebox.nested-talk{border:1pxsolid#c0c090;background-color:#f8eaba;width:100%;margin:2px0;padding:2px;}
The difference with the new ".mbox-inside .standard-talk," selector is that now only "messagebox" boxes that are intended to be on talk pages will be converted to talk page brown and 100% wide when inside an "mbox-inside" tagged box, such as inside the {{WikiProjectBannerShell}}. While the selector I used in my previous example above ".wpbs-inner .messagebox" converts any "messagebox" box to talk page brown and 100% wide, when inside a bannershell. Both works well enough for us, so it is more a matter of theoretical correctness.
I consider 'demonstrations' and 'examples' on talk pages to be distinct from 'discussions' and 'opinions'; the latter are of course inviolate, and I would never edit such, with the sole exceptions of things like correcting indentation. However, and we've had this discussion before too, I tend to consider code examples, demonstrations and programming suggestions to be 'active content', and feel that editing such material to keep it 'up to date' is preferable to continually posting endless new examples of almost identical content with only minor differences. Naturally it is unacceptable to make changes that alter the meaning of an example, but trivial changes (as well as edits that restore the meaning of old examples) are, IMO, acceptable. Although I usually attempt to note where I have made changes, you correctly note previous cases where I have neglected to do so. Since you appear to object to this position, I will try to remember to leave your comments in whatever state I find them. But that's by-the-by... I like the new selector for the second part, very sensible. And since it's only three days until the new CSS and JS decaches for the new collapsible banners, it's only a temporary fix anyway.
Happy‑
melon13:58, 28 October 2008 (UTC)
Happy-melon: Well, the most important part is that you should note when you do changes to "examples" on a talk page. Since it is very confusing when I make a code example and add a text explanation below, and then you change the code example which makes my text explanation below seem confused. And of course even worse when you break my code example. (And even worse to break the code when I claim in my text that I have tested and verified the code in all three of my browsers.)
And regarding the code being "temporary": Well, as we have discussed before it will probably take at least some months and perhaps some year before all usage cases of the messagebox classes have been updated to use the tmbox classes instead.
Everyone: So, should we use "margin: 2px 0;" or "margin: 2px 0 0 0;" ? Both margin settings work, but I think the "margin: 2px 0;" looks better in the browsers I have.
And gah! Now I see why the old code used "margin: 2px 0 0 0;". Now that we use "margin: 2px 0;" we get more margin at the bottom than at the top, in most browsers. So I investigated: {{WikiProjectBannerShell}} uses this padding for the wpbs-inner cell: "padding:2px 4px 4px 4px;". I want to update that padding to "padding: 2px 4px;", instead of changing the margin back for the banners. I tested and that makes it right in all three of my browsers. Does anyone know any reason to not do that change?
This is true, I will try to be more careful in future. Of course I thought I was making the trivial change of adding a few comments, such that the 'meaning' of the example wasn't changed at all; unfortunately I didn't know I was also breaking it :D...
Vis temporariness, remember that this particular fix doesnt' really apply to all messageboxes, only to those which ever appear in an mbox-inside, of which the WikiProject banners are (AFAIK) the only examples. So this code only really applies until we've converted all 800-some WikiProject banners to use mbox classes and the new nested system. If that takes over a year we really need to work on our productivity :D You are right, however, that fully deprecating the messagebox system is going to take rather longer.
(The below completely irrelevant given the editconflict with DG's post above :D) Since what we're really trying to do here is to unify the appearance of the new and old templates when they appear inside an .mbox-inside, perhaps the most sensible thing to do would be to exactly duplicate the styles that are applied to the .mbox-inside .tmbox tables for the other two options (.mbox-inside .standard-talk and .messagebox.nested-talk). This is the only way I've found that it's possible to make the two classes exactly identical. Code to do this is below; it's more extensive than the examples above:
.mbox-inside.tmbox{/* For tmboxes inside other templates. */margin:2px0;width:100%;/* Fix for Safari and Opera. */}.mbox-inside.standard-talk,.messagebox.nested-talk{border:1pxsolid#c0c090;background-color:#f8eaba;width:100%;/* Apply the same */margin:2px0;/* styles to messageboxes */padding:0;/* as to the new */border-collapse:collapse;/* tmbox classes */}.mbox-inside.standard-talkth,.messagebox.nested-talkth{/* Apply the most important part of '.mbox-text' to */padding:0.25em0.9em;/* the header cells of normal nested messageboxes */}.mbox-inside.standard-talktd,.messagebox.nested-talktd{padding:0.5em;}
The last two declarations apply some relevant styles from the .mbox-text and .mbox-image classes to the cells of the other tables, as these templates don't contain the necessary class declarations. Applying these styles to the messagebox classes does introduce its own issues, such as there being no padding between the quality-scale cell and the edge of the table; these could only be fixed by applying all the various mbox tricks to the necessary cells, which would require a huge amount of convoluted and hacky CSS (and couldn't be reliably done completely without adding classes to the tables); needless to say, this whole process would be a lot easier if we could modify the entire banner collection easily at once... but then we wouldn't be in this situation in the first place :D... These style issues will go away once the banners are converted to use the mbox classes directly, so (given that that process can start in 3 days time) the moral of the story is: we can try till kingdom come to make these two groups of tables render identically, but the only way we're really going to achieve it is to make them use the same classes and styles. The other moral is, border-collapse:collapse; is a bitch to imitate without actually doing it...
Happy‑
melon19:40, 28 October 2008 (UTC)(End completely irrelevant part)
DG, I've independently come to the same conclusion on my hardcoded version of WPBS. I know the discussion over "2px 4px" vs "2px 4px 4px 4px" has been had before, but I can't remember what was decided and why!! Either way, changing it seems to solve the immediate problem, so go ahead IMO.
Happy‑
melon19:46, 28 October 2008 (UTC)
Okay, I have changed {{WikiProjectBannerShell}} to use "padding: 2px 4px;" for the wpbs-inner cell.
Happy-melon: And regarding your "irrelevant part" above: Now that we fixed the width, margin and padding I think the "messagebox" and "tmbox" based banners look enough much like each other that no further fixes need to be done with that. The next step, as you point out, is to continue to convert banners to use the tmbox classes.
I am very curios/thrilled to see how your new javascript and CSS code for the auto hiding of the headers will work out there on the real pages. (That is, so the banners don't need the "nested=yes" setting anymore.) If I understand it right, that is the javascript and CSS that will be fully decached in three days, right?
this is the critical edit, so yes, a couple of days should do it. Have we actually pinned down precisely how long the caching time is? I guess I'd better get writing up the explanation of how to use the new system...
Happy‑
melon21:08, 28 October 2008 (UTC)
Yes and no: For the CSS files it is exactly 31 days caching, or as my web browser states it: 2678400 seconds. For the javascript files I don't know. We should probably check with the devs what the exact javascript caching time is.
Oops, thanks for "filling in" the numbers Ms2ger. Because of Happy-melon's question above I asked over at
MediaWiki talk:Common.js#Javascript caching time and did get a full answer earlier today. (Have a look, it is interesting.) But I forgot to report back here. And yes, the answer is that the servers set both 30 and 31 days caching at the same time on some javascript and some CSS files...
So as I stated over there: So to be on the safe side, and since the difference is only a day anyway, let us assume that some users won't see our changes until 31 days have passed.
I've been using this template on several article talk pages within the scope of
Wikipedia:WikiProject Wine. It has worked fine, until just now when I placed it on
Talk:Sangiovese. No show/hide gadgets appear, and the WikiProject descriptions aren't collapsed. Any idea what's wrong? I didn't do anything different than on other pages (see
Talk:Zinfandel for example). ~
Amatulić (
talk)
23:38, 29 October 2008 (UTC)
What browser, do you have any other javascript installed, do you get any javascript errors, does it still happen after purging/null-editing/dummy-editing, does it still happen if you log out/log back in/log in as a different user? I'm on FF2.0, and I see no problems - the page renders perfectly. However, I suspect this is the same or related to
Template talk:WPBannerMeta#Nesting again....
Happy‑
melon23:49, 29 October 2008 (UTC)
Using IE7, no special settings, problem still occurs after purging caches, editing the page, logging off and on, etc. I will point out that this template works on every other page I have put it on, but not
Talk:Sangiovese. I do get a little "Error on page" message in the lower left corner of the browser window, and that message doesn't appear on any other page. So it is likely a javascript error, but the error is not on my end. ~
Amatulić (
talk)
00:26, 30 October 2008 (UTC)
Talk:Sangiovese is probably just the only talk page you put it on that has a
"Comments" subpage. There is a certain bit of code that has been copied into a number of WikiProject banners that causes broken links to be generated, and any gadget/script that manipulates all links on the page will blow up in IE7 when it finds one of those links.
This edit probably fixed it.
Anomie⚔00:47, 30 October 2008 (UTC)
I haven't seen the version of
Talk:Sangiovese that broke for Amatulic, but the current version works fine in all three of my browsers. (Firefox 2, IE 5.5 and Opera 9.02.) So it seems you fixed it Anomie.
I'm not sure the problem surfaces in any browser other than IE7, actually, and you also have to have a gadget/script installed that pokes at the broken link.
This test pageshould exhibit the problem, but I can't test it at the moment to say for sure.
Anomie⚔01:41, 30 October 2008 (UTC)
Amatulić: Yes, Anomie fixed the problem. And thanks that you reported that it now works.
Anomie: Your test page works in my IE 5.5. So it seems you are right that it is IE 7 that is extra sensitive. Or I simply don't have any of the scripts installed that provokes the error. Anyway, the solution is of course to not use broken code. Thanks for fixing the broken pages.