Jump to content

Template talk:Tmbox/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3

SVG

Please replace the PNGs with SVGs as follows. Anyone have a SVG for Image:Imbox content.png? 

    | speedy     = [[Image:Ambox warning pn.svg|40x40px]] 
    | delete     = [[Image:Ambox warning pn.svg|40x40px]] 
    | content    = [[Image:Imbox content.png|40x40px]]
    | style      = [[Image:Broom icon.svg|40x40px]]
    | move       = [[Image:Merge-split-transwiki default.svg|40x40px]]
    | protection = [[Image:Padlock-silver-medium.svg|40x40px]]
    | notice          <!-- notice = default -->
    | #default   = [[Image:Information icon.svg|40x40px]]

--ChrisRuvolo (t) 20:32, 25 June 2008 (UTC)

☒N Not done
{{tmbox}} should use PNGs just like ambox, imbox, cmbox and ombox. Here's some explanation for those of you who did not take part in the icon design discussions over at Wikipedia talk:Article message boxes:
  • For several technical reasons we prefer to use PNGs in the mboxes. Among other things the SVGs get problems with their transparent background in older web browsers. The mbox PNGs have been hand modified to workaround that background problem, so they look good in all browsers.
  • If/when matching SVGs have been made they should not be uploaded to Wikipedia, but instead to Wikimedia Commons. The reason the PNGs are uploaded to Wikipedia is so we can protect (lock) them here, since they are high-use here, since they are used in the mboxes.
We haven't made the tmbox specific PNGs yet since the background colours for tmbox have not yet been decided. Thus for the current draft version of tmbox I used the imbox PNGs.
--David Göthberg (talk) 22:47, 25 June 2008 (UTC)
I thought the rendered PNG background issue was resolved by a change to the mediawiki use of librsvg? Didn't that only effect old IE versions (now a minority of browser traffic)? What other technical issue is there? Thanks. --ChrisRuvolo (t) 22:57, 25 June 2008 (UTC)
No, MediaWiki can not resolve this since it does not know the background colour of the box that the SVG is used in. And the same SVG can be used in different places/pages with different background. I just checked in my Internet Explorer 5.5: SVG images still get a white background instead of transparent background, thus looking like white boxes when inside for instance a brown talk page box.
When we know exactly the image size we are going to use and the background colour of the box, and an image is used in high use templates like the mboxes, then it is worth the trouble to make hand modified PNG images. In this case the PNGs are superior to the SVGs. PNGs are not inherently evil. Oh, and some people out there still have to use IE 5.5. since that is the last IE version that runs on some older Windows versions that are still in use. (Of course, they could upgrade to Firefox instead...)
--David Göthberg (talk) 23:14, 25 June 2008 (UTC)
I concur with User:Davidgothberg, having done editing on Portable Network Graphics with The GIMP on my Everex workstation. Properly encoded, PNGs work properly with all background Web colors; that is not yet the case with the Scalable Vector Graphics engine on Wikipedia®. As I understand things, Images that meet certain high-usage requirements need to be locked down against unauthorized replacement, accidental or otherwise. B. C. Schmerker (talk) 05:28, 26 June 2008 (UTC)

Icons

Someone please make these icons look like they came from the same set. Especially "Move". It doesn't match at all.

In fact, pretty much every message-box template on Wikipedia looks garish, especially when you place a bunch of them together. —Werson (talk) 05:04, 26 June 2008 (UTC)

There's some really nice icon sets on Commons that don't often get a lot of attention here on en.wiki. While I'm not greatly opposed to our current ones, I'd be pleased at the chance to explore some of these lesser known options. -- Ned Scott 05:31, 26 June 2008 (UTC)
Maybe this has been discussed before, but is there any reason we can't use the Tango icons?
(These aren't talk-page messages, but you get the jist of what I mean.) They all match and look nice together, plus they match the direction the open-source community's moving in.—Werson (talk) 18:06, 26 June 2008 (UTC)
Interesting. In a few days I'm looking to hold a discussion on formatting, specifically the background color and accent colors, and where they should be placed. (Some ideas) The icons deserve to be looked at, too, but they need to be separate from the formatting (except where the colors should agree). Even so, I don't particularly like these because they seem too saturated and hence not serious enough. I also don't like how move now doesn't match the purple bar. That's just me, though.--HereToHelp (talk to me) 20:20, 26 June 2008 (UTC)
I agree, they're a little candy-looking. I'm not a big fan of color-coding myself. But the colors shouldn't be too hard to alter. (I changed the "move" icon, for example). —Werson (talk) 22:39, 26 June 2008 (UTC)
Thanks, but even so I still prefer the old ones. Still, I support a discussion of icons. Just keep in mind that they need to be standard across all templates, listed at the top of the page. Are there any other sets to choose from?--HereToHelp (talk to me) 22:46, 26 June 2008 (UTC)
Good point. I raised a discussion Wikipedia talk:Article message boxes#Icons here; that seems like the correct place for it. —Werson (talk) 23:00, 26 June 2008 (UTC)
As I understand the situation, Wikipedia® has already standardized on default icons for Type. Notwithstanding this issue, a transparent-back PNG version of Image:Dialog-error-round.svg would be a good default Image for an Indefinite Block message, e.g.:
Otherwise, more discussion would be needed prior to any major changes. B. C. Schmerker (talk) 07:04, 27 June 2008 (UTC)
B. C. Schmerker: We discussed and updated the ambox/imbox etc. default icons recently. See the now archived discussion at Wikipedia talk:Article message boxes/Archive 8#New ambox version. The consensus then was that Image:Deletion icon.svg was good, Image:Octagon delete.svg was better, and that Image:Ambox deletion.png was best.
Of course, consensus can change. I just wanted to point out the old discussion and its conclusions. And there is nothing preventing that the different mboxes use different default images. But for simplicity we have used the same images in all the different mboxes so far.
But for instance the current style type (minor problem or minor warning) default image Image:Broom icon.svg works very well for ambox and fairly well for imbox, but should probably be changed to something else for most of the other mboxes. We just haven't come up with a good alternative yet.
--David Göthberg (talk) 12:35, 28 June 2008 (UTC)
Noted—Image:Deletion icon.svg, similar to Image:Dialog-error-round.svg, is consistent with what I envisioned for Speedy; Image:Ambox deletion.png, similar to Image:Ambox warning pn.svg, is already standard for Delete and, in my view, ought to remain unchanged. I amended User:B.C.Schmerker/Templates/MBoxSampler1 to reflect these knowns; I used color-keyed Exclamation triangles across the example Delete, Content and Style types as one example of how to standardize the three across Page and Talk. (The icons for Notice, Move, Featured, Protection and License types are unchanged from current.) B. C. Schmerker (talk) 06:39, 29 June 2008 (UTC)

Speedy & Delete

Why are speedy delete and "slow" getting inculded in the examples as they are not talk page templates, they go on the article mainspace?. Peachey88 (Talk Page | Contribs) 09:33, 26 June 2008 (UTC)

See David Göthberg's comment under #Going about this all wrong--HereToHelp (talk to me) 12:15, 26 June 2008 (UTC)
G8 →AzaToth 17:03, 26 June 2008 (UTC)
AzaToth's comment is pretty cryptic. First I though he meant "great". Then I realised he probably means Wikipedia:Criteria for speedy deletion#G8, which specifies criteria for when talk pages are deleted. And the speedy message box for that is {{db-g8}} = {{db-talk}}, which is used on talk pages.
--David Göthberg (talk) 18:29, 26 June 2008 (UTC)
Hehe, I just felt to do an minimalistic comment :) →AzaToth 19:38, 26 June 2008 (UTC)
Evil! :) --David G 2008-06-26, 20:06
To answer User:Peachey88, The Type=Speedy is actually used for specific Administrator templates, such as the Level 4 Warnings and Level 3 Block, e.g.
Hopefully, this will give you some context for this discussion. B. C. Schmerker (talk) 16:09, 27 June 2008 (UTC)

Stackable

There doesn't seem to be any real discussion of this issue: since when have we wanted to make talkspace messageboxes stack? They are currently nicely separated; uniquely so amongst our template styles. I think that this is one of the nicest features of the existing style, as it marks each box out as a separate entity conveying (usually) widely differing information. Plus, as someone said above, with templates like {{ArticleHistory}} and {{WikiProjectBannerShell}} being collapsible, stackable boxes will get very confusing. Happy‑melon 18:53, 26 June 2008 (UTC)

I agree. Talk page message boxes probably are better with some space between them like they have now. And a small technical correction, not "uniquely" since both {{imbox}} and {{ombox}} have space between them. Currently only {{ambox}} and {{cmbox}} stack tightly.
But they are all "stackable" in the sense that they have the same width (80% of the text area width) and that the different types look good together.
--David Göthberg (talk) 19:35, 26 June 2008 (UTC)
Interesting point. I agree, and it will be interesting to see how stacking (or not) affects the formatting choices. David G: When you get a chance, I'm waiting for a response.--HereToHelp (talk to me) 20:29, 26 June 2008 (UTC)
I'd prefer them to stack tightly; most talk pages are ridiculously crowded with boxes as it is. The more tidily/efficiently the information can be conveyed, the better. —Werson (talk) 22:40, 26 June 2008 (UTC)
Don't forget about the small option. -- Ned Scott 06:38, 28 June 2008 (UTC)
Ned Scott: Oh dear, thanks for the reminder. Yes, we have to add the code for the "small=yes" option before we deploy tmbox. I had forgotten about that. I'll fix that in some day.
--David Göthberg (talk) 03:18, 29 June 2008 (UTC)

Some examples

I think at this point it would be good to reflect on the various issues that are floating around here. It is, in my opinion, premature to be debating the specifics when meta-issues like stacking, use of colours, and position of colours if used, still need to be decided upon. So I've tried to create here a set of "in the wild" examples: how these various designs will actually relate to real talk pages. The talk page I've taken the templates from is Talk:Muhammad: I ran it through Special:ExpandTemplates, cleaned the code up, and then altered the styles accordingly. Take a look and see what you think. Happy‑melon 20:10, 27 June 2008 (UTC)

No stacking, no colours

Well, that's what we've got right now at Talk:Muhammad, so take a look there for the 'status quo'

Stacking, no colours

↓ ↓
Important notice: Prior discussion has determined that pictures of Muhammad will not be removed from this article, and removal of pictures without discussion at Talk:Muhammad/images will be reverted. If you find these images offensive, it is possible to configure your browser not to display them; for instructions, see the FAQ. Discussion of images should be posted to the subpage Talk:Muhammad/images.
Important notice: Wikipedia's Muhammad FAQ addresses some common points of argument, including the use of images and honorifics such as "peace be upon him". The FAQ represents the consensus of editors here. If you are new to this article and have a question or suggestion for it, please read the FAQ first.
Censorship This topic may attract censorship. Please keep in mind that Wikipedia is not censored.

Articles may contain content that some readers consider objectionable or offensive. Images or details contained within this article, in particular, may be graphic or otherwise objectionable in order to ensure complete coverage of its subject matter. For more information, please refer to our content disclaimer regarding objectionable content.

To-do list for Muhammad: edit · history · watch · refresh

Here are some tasks you can do:
  • Verify: Recently the references were cleaned up. Some errors may have crept in. Please check if the statements are supported by the sources.
  • Cleanup: reduce the number of inline and block quotes by summarizing them efficiently
  • Expand: The "Sunnah and Islamic law" section
This article is within the scope of the following WikiProjects:
This article has an assessment summary page.
Good article Muhammad was one of the good articles, but it has been removed from the list. There are suggestions below for improving the article to meet the good article criteria. Once these issues have been addressed, the article can be renominated. Editors may also seek a reassessment of the decision if they believe there was a mistake.
 Muhammad is currently a good article nominee. An editor has reviewed the article, and left comments on the review page. However, this editor has requested a second opinion either from a more experienced reviewer, or someone with more expertise on this subject, to gain further consensus that this article meets the good article criteria. In the meantime, editors are encouraged to revise the article based on the first reviewer's comments.

Date: 23:36, 30 May 2008 (UTC)

I have to say I don't like this at all (although you can obtain the same effect live for yourself by adding 

.messagebox.standard-talk {margin: 0 auto}

to your monobook.css if you do). It causes the boxes to form themselves into one huge block of coffeeroll colouring, which is more intrusive than the separated boxes. That said, it does save on some space: perhaps a compromise (0.5em rather than 1em?) would be ideal. Happy‑melon 20:10, 27 June 2008 (UTC)

I think that halving the space between templates would bring them too close together and would create a rather crowded appearance. Saving an inch is a dubious benefit, in any case, and the Skip to table of contents template at the top more than compensates for this small difference in length. If only there was something similar for the long References sections... Waltham, The Duke of 21:56, 28 June 2008 (UTC)
Agreed. Wikipedia is not paper; space is free.--HereToHelp (talk to me) 21:58, 28 June 2008 (UTC)
Space is not free. It costs visual footprint for the reader. That's why we have templates to hide long lists of WikiProject banners and such: we don't want talk pages to begin with screenfuls of templates. However, in this instance, the difference between a tiny gap and no gap does not seem to be material. WhatamIdoing (talk) 16:32, 30 June 2008 (UTC)
Yes, but nitpicking at the tiny bit of space between banners isn't going to realistically help. -- Ned Scott 07:09, 3 July 2008 (UTC)

WikiProject banners and talk page message box standardisation

I guess it is time to explain this since there seems to be misunderstandings about this:

The {{tmbox}} meta-template is just a convenient way of making the message box styles available for message box builders. (Well, it packages some nifty functionality too and proper box flow.)

The WikiProject banners have special technical needs and thus will probably continue to use their own meta-templates. This saves us from adding a lot of WikiProject banner specific functions to the tmbox.

However, the WikiProject banners still are talk page message boxes, and they are non-urgent/non-warning, thus they are of "notice" type. The WikiProject banners do use the message box CSS classes in MediaWiki:Common.css and thus they will use whatever style we decide on for the notice type.

Remember, we are not only designing the tmbox here, we are re-standardising the styles for all talk page message boxes.

--David Göthberg (talk) 13:34, 28 June 2008 (UTC)

For anyone wanting to standardise WikiProject banners, take a look at the {{WPBannerMeta}} template. -- Uksignpix (talk) 22:40, 29 June 2008 (UTC)

Icon valign top

Since it's invariable that these boxes will eventually have extended amounts of content, I would suggest that the icon be moved to the top of the box (or at least have the option of doing so). For example, check out a blocking template I made. In my opinion, the icon looks weird in the middle and doesn't really mix with the "traditional" dialog boxes that users are used to seeing in the operating systems. It looks better when MBisanz scaled the icon up, but without javascript, I can't think of a way of automatically doing that for larger boxes, so I figure a valign top is another choice:

The Opera Mini proxy network is currently blocked from editing due to abuse.

You, yourself, are not personally blocked. However, in order to prevent abuse by vandals and other banned users, editing Wikipedia while using this browser is currently disabled because it can be can be used as an open proxy through its demo interface.

What to do:

  1. Contact Opera. Let them know you are caught by this problem and want them to participate in our X-Forwarded-For project. Also, ask them to fully integrate it with their demo interface so that it, too, will no longer be considered an open proxy.
  2. If you already have an account: you may request an an IP block exemption if your account is in good standing, and you will be able to bypass this block.
  3. Simply edit from home. Remember: you, personally, are not blocked— only the Opera network is, so you should be able to edit normally from your home connection. Though, please be sure to contact Opera to let them know about the problem so that once they close the aforementioned holes you can edit using Opera Mini again.

Anyway, just an idea. Cheers. --slakr\ talk / 02:41, 1 July 2008 (UTC)

I like this idea, can it be set as a hook David or Happy? MBisanz talk 02:50, 1 July 2008 (UTC)
This is an excellent proposal for standard Template Messages with large amounts of formatted text, e.g. the DB templates for speedy deletion, AfD/TfD/IfD/CfD templates for deletion nominations, the ProD proposed-deletion template, Administrators' talk-page standard messages, etc. My return question is, how difficult would it be to support ImageToTop and/or ImageRightToTop booleans in the Template code? B. C. Schmerker (talk) 07:56, 1 July 2008 (UTC)
My personal opinion, which I remember expressing before, is that top-aligned icons look ugly even in long messageboxes; and I personally prefer seeing the template above with the icon centred. But that's just me. However, on a technical note, it would be trivial to implement this through a new parameter; I am, however, loathe to participate in such feature creep. More importantly, this would create some discontinuity between {{tmbox}} and the other mbox templates, which is not a good idea. So yes, it could be done very easily, but no, I wouldn't personally want to do it. Happy‑melon 12:29, 1 July 2008 (UTC)
I agree with Happy-melon.
Technically:
If we are going to add this feature then I think we shouldn't use a special parameter like "imagetop=yes". Instead we should use the more flexible approach that we have with the "style" and "textstyle" parameters. That is, we could add a "imagestyle" parameter and then if you want the image to align to the top you would use "imagestyle = vertical-align: top;". (This is more flexible since then also other CSS style settings can be used for the image cell, and it means simpler code in the tmbox itself.)
Stylistically:
But I don't think we should align images to the top of message boxes. The same thing was discussed for {{imbox}} and most of us wanted the images to be middle aligned, not top aligned. What's the point of standardising message boxes if people constantly want special parameters so they can re-design the boxes totally?
If you have very special needs for your message box then hard code it with table code, and use the tmbox CSS classes in MediaWiki:Common.css directly. Currently only the old talk page message box classes are in Commons.css: ".messagebox" and ".messagebox.standard-talk". We will add the ".tmbox" classes when we have consensus for the new styles for talk page message boxes. We have a page that describes how to use the CSS classes for ambox, the tmbox classes will work the same way: Wikipedia:Ambox CSS classes.
--David Göthberg (talk) 15:29, 3 July 2008 (UTC)
Noted; I saw a potential mod that is apparently NOT agreed to. B. C. Schmerker (talk) 16:47, 3 July 2008 (UTC)

2px border

Why is there a 2px border in some cases? This looks horrible on pages with templates with 1px borders and 2px borders. The borders for talk page templates have been 1px for years. --- RockMFR 03:20, 14 July 2008 (UTC)

The styles this template currently produces is just a suggestion. We are still discussing what styles to use. Discussion is going on at this talk page and you can see the full list of styles we are discussion at Template:Tmbox/styles and discuss those styles at its special talk page. You are very welcome to comment on the different suggestions at that talk page.
If you are seeing these styles on actual talk pages then it is because some users have been impatient and started to deploy this template and the {{mbox}} template (which calls this template), in spite that they are not ready to deploy. That is, we do not have consensus for their styles yet, so please don't deploy yet! (But in most cases we haven't bothered to revert those edits since we probably are going to deploy soon, and most of those edits contained other fixes to the message boxes, thus reverting them is messy.)
The reason I choose 2px border in my suggestion "David G's version" is that I tried 1px border and that was too thin to make the colours properly visible. But since most message boxes will use the notice type I wanted to keep the old standardised style for that type, so most boxes will look like before. And as you noted, that style uses 1px border. We did the same with the {{ombox}} which has now been deployed for some time.
--David Göthberg (talk) 09:45, 14 July 2008 (UTC)

Controversial image

Well, not really. But the image used in {{controversial}} is rather... Well, it is... It's kind of...

Out of fashion? :-D It looks old and dusty, and doesn't match with the rest. It really sticks out. Any ideas? Waltham, The Duke of 13:05, 22 July 2008 (UTC)

I tried a "newer" green version, do we want to try a blue or red or yellow. MBisanz talk 17:01, 22 July 2008 (UTC)
Better, thanks. It does looks a little alien... ;-D
I don't know which colour would be the most suitable, but I do know that this would exclude yellow due to insufficient contrast. We should probably also avoid red, as this is an informational box. This leaves us with green and blue... I can't decide if we have reasons not to like the green colour's positive connotations with regards to the actual message of the box, or to object to the usage of blue due to that colour's prominence in notice-type boxes and relevant icons, creating unwanted similarity. Perhaps we should leave it as it is now. Waltham, The Duke of 11:20, 23 July 2008 (UTC)
Recommend testing a charcoal-gray background (#404040) with the white question-mark for readability; the blue alternative could also be of use. B. C. Schmerker (talk) 16:57, 23 July 2008 (UTC)

Back to this page

For more technical discussion. Namely, what do we do about the 'small' and 'nested' styles? I can see the 'nested' issue being less of a problem, since it is only used by WikiProject banners, which are less likely to use this template. I still think the class should be renamed to "tmbox-nested" so we can fully deprecate the "messagebox-" series of classes, and eventually remove them. Do you think {{tmbox}} should support the 'small' style, however? If so, how? Happy‑melon 17:59, 5 August 2008 (UTC)

Yes, I agree that whatever talk page message box classes we use should be renamed to "tmbox-something". And yes, it is better the WikiProject banners have their own meta-template, since their needs are so special.
Personally I don't use the small style, but I don't mind it and I know others like it and sometimes use it. So yes, I think the {{tmbox}} should support the small style. (For other readers: You can read about the small style here: Wikipedia:Talk page templates#Small option, and there are visual examples further down on that page.) I intend to add the parameter "small=yes" and I don't think there will be any technical problems in adding that functionality. But I haven't tried it yet. I'm going to fix that when I get the time. The only "problem" that I foresee with it is that in the small style we traditionally use 30px images (which I agree with is the proper size for the small boxes), and that means we either need to add another set of default images, or accept that the images get slightly badly resized to 30px images (including them getting a bad background in some older browsers), or we have to accept using 40px images even in the small style. So we need to think about the image size.
--David Göthberg (talk) 21:10, 5 August 2008 (UTC)
Weee! I have added code for the small style in the {{tmbox/sandbox}}. And there are two sections with test examples at the bottom of the same page. It seems to work very well. And the image rescaling to 30px doesn't look bad at all, just a very slight blurring that is only visible in lower screen resolutions. I used the styles from ".messagebox.small-talk" in MediaWiki:Common.css but with a minor change to the top and bottom margin to make it flow better with other full sized tmboxes.
The "Small message boxes" and "Testing box flow" examples in the /sandbox look good in my Firefox 2, IE 5.5 and Opera 9. Can someone check how they look in more recent Internet Explorer versions and in Safari? (Those browsers are not available for my OS.)
--David Göthberg (talk) 23:23, 7 August 2008 (UTC)
On IE7: The small boxes have a wider spacing than the large boxes, which I don't think looks very good. They should either be the same or be closer spaced. The image scaling looks great. I love the way the small and large boxes stack together! Happy‑melon 10:28, 8 August 2008 (UTC)
Yeah, I see the same spacing bug in my Opera 9. I have done several tests but have not found a fix. And unfortunately we can not reduce the spacing for the small boxes since then it gets too tight in the other browsers. I think the old small talkpage message boxes probably have the same problem, but I have not verified that yet. That is, at least I don't think we add a new bug...
--David Göthberg (talk) 12:41, 8 August 2008 (UTC)

Simpler to use small option

I've been doing some thinking. Building talkpage message boxes that supports the "small=yes" option is somewhat complicated. The simplest case is a box that only uses the default tmbox images and uses the same long text for both the big and small box, then the code is pretty straightforward, like this: 

{{tmbox
| type = notice
| small = {{{small|}}
| text = Long text
}}

But if the box has its own image then it really should be resized to 30px to not look too big in the small case. And the smaller box preferably should have a shorter text. Then the code becomes rather complex, like this: 

{{tmbox
| type = notice
| small = {{{small|}}
| image = {{#ifeq:{{{small|}}}|yes
  | [[Image:Something.svg|30px]] 
  | [[Image:Something.svg|40px]] 
  }}
| text = {{#ifeq:{{{small|}}}|yes
  | Long text 
  | Short text 
  }}
}}

I could make life easier for those that build talk page message boxes by adding some new parameters to the {{tmbox}}. Making the complex case above look like this instead: 

{{tmbox
| type = notice
| image = [[Image:Something.svg|40px]] 
| text = Long text 
| small = {{{small|}}
| smallimage = [[Image:Something.svg|30px]] 
| smalltext = Short text 
}}

In the example above "smallimage" and "smalltext" are used instead of the normal "image" and "text" if "small=yes" and "smallimage" and "smalltext" do have content. If they don't have content tmbox instead uses the normal "image" and "text" even if "small=yes".

I could also add some imageright magic: We could have a "smallimageright" parameter that either takes a smaller image to be used, or takes "smallimageright=none" which makes it so that no right image is shown when "small=yes".

This added functionality would of course make the code inside tmbox more complex. But I think it would make life easier for those that build talkpage message boxes, and that is after all the purpose of the tmbox.

What do you guys think? Should I code up an example in the /sandbox with the extra parameters? Or is this just functionality creep? After all, I haven't seen the "small=yes" option used for a long time now.

--David Göthberg (talk) 01:32, 8 August 2008 (UTC)

I'm honestly not sure. I think it would be nice to see how much more complicated and bulky the tmbox code becomes with the extra parameters. I think |smallimageright= is certainly unnecessary, given how small the intersection between "pages using templates with a right image" and "pages using small templates" must be. I think having |smallimage= and |smalltext= would be helpful to messagebox builders, which is indeed the idea. I say if it's not too much more processor-intensive, let's run with it. Happy‑melon 09:43, 8 August 2008 (UTC)
I could not resist, so I have already added the "smallimage", "smallimageright" and "smalltext" parameters in my personal tmbox sandbox: {{tmbox/test1}}. And as my edit comments say there: "This is ugly code..." But at least it won't cost much CPU since it is just a bunch "#ifeq:" and "#if:" on local variables so no extra transclusions or other expensive parser functions. The code I added there is with the full bells and whistles. See the examples at the bottom of that page.
The code is pretty bulky, so people will have a problem to handle that code in the future. So I am very hesitant if we should add that code to tmbox. There are a way to make the code look much nicer by using two templates, but that will cost a little more CPU. (I'll code that up later. It only costs a single extra transclusion.) I could make a compromise where most templates only call the old "clean" tmbox, while those that need the small option can call a special "tmbox-small" that has the neat but more CPU costly small code. But that would not be user friendly to those that build talkpage message boxes. So I think if we add these parameters then we probably should "not worry about performance" and go with the neat but slightly CPU costly code for the main tmbox itself. It just costs a single extra transclusion per tmbox anyway. (Which is way better than most templates that transclude the {{!}} multiple times just because they use wikitables instead of HTML tables...)
--David Göthberg (talk) 12:41, 8 August 2008 (UTC)
Hmn, looks (as you say) very messy. I've managed to bring down some of the overhead stats in Template:Tmbox/test2, using #ifexpr: instead of nested #if: and #ifeq:, which I think is also more readable. Comparison:
Test1:

Preprocessor node count: 3434/1000000
Post-expand include size: 48735/2048000 bytes
Template argument size: 7408/2048000 bytes
Expensive parser function count: 3/500

Test2:

Preprocessor node count: 3543/1000000
Post-expand include size: 38251/2048000 bytes
Template argument size: 6533/2048000 bytes
Expensive parser function count: 3/500
What's your idea for the transclusion method? Happy‑melon 13:27, 8 August 2008 (UTC)

First some notes about your /test2 code: You don't need the "#ifexpr:" code there, you can see in the history of /test2 a simpler code that I tried. And your code currently doesn't work right for "smallimageright". I think the error is in the switch case but I haven't had time to find the error yet. And experience has shown that we need to keep the </td> tags on the same line as their content. (I don't remember exactly what errors that caused, something with box flow I think.) But anyway, nice optimisations! But it still means very messy code.

My less messy transclusion method: You can see my idea at {{tmbox/test3}}. It handles all the extra "small" parameters and then makes a clean call to {{tmbox/sandbox}}. Thus the code in /sandbox only needs to understand "small=yes" but not the "smallimage", "smallimageright" and "smalltext" parameters, thus making its code much simpler. (I should perhaps point that call to say /test4 later on but for now its enough for testing since /sandbox currently has the right code for it.)

I have tried three different versions of the /test3 code, one with clean readable code, and two optimised. The cost for this approach is: 

Not optimised:
Preprocessor node count: 3478/1000000
Post-expand include size: 81132/2048000 bytes
Template argument size: 11796/2048000 bytes
Expensive parser function count: 3/500

Optimised:
Preprocessor node count: 3772/1000000
Post-expand include size: 61358/2048000 bytes
Template argument size: 11949/2048000 bytes
Expensive parser function count: 3/500

Further optimised:
Preprocessor node count: 3821/1000000
Post-expand include size: 61215/2048000 bytes
Template argument size: 11977/2048000 bytes
Expensive parser function count: 3/500

Since the optimisations didn't save that much and the code became pretty messy in /test3 I reverted myself to the "not optimised" version. You can see the different version in the history of /test3.

I think I want to use one of these "translusion methods" since it makes much more serviceable code, even though it costs more server load compared to your optimised version with one single template.

By the way: The three "expensive parser functions" are in the three shortcut boxes that we use as examples on those pages. So is not caused by tmbox.

Now I'm of to meet my dance girls! I'll be back tomorrow.

--David Göthberg (talk) 17:39, 8 August 2008 (UTC)

I like the transcluded code very much - very clean! I agree we should go with that despite the fractionally higher transclusion costs. What are we going to call it, though? {{tmbox/core}}?? It is a bit of a shame to have two templates in the transcluded-list, but I guess that's unavoidable. Perhaps {{tmbox/small}} would be more innocuous, although less intuitive. Have fun with your dancing girls :P Happy‑melon 19:24, 8 August 2008 (UTC)
Thanks. So seems this is the method we will use then. (Although for the record I find the whole "small=yes" option unnecessary, but that is just my personal preference.) I was thinking to call it {{tmbox/core}} since that is now more or less Wikipedia tradition. I don't like the name {{tmbox/small}}. I'll fix this in some day since I have a busy weekend. If you like you can of course do it for me since you just have to cut and paste the code. Although I already have an idea how to document it and add it without any disruption to pages that already use the tmbox, so you can save your work by leaving it to me.
--David Göthberg (talk) 17:52, 9 August 2008 (UTC)
I agree entirely on the whole small option, but it's out there and so we need to deal with it. I've updated Template:tmbox and Template:Tmbox/core. I also made this edit to the tmbox code; is there a reason to handle |smallimageright=none but not |imageright=none? Surely neither of the parameters need to take =none, because there's no CSS fix required...?
I've also added the code to Common.css - I'd be grateful if you could double-check that I've got everything right. I'll leave the documentation to you. Happy‑melon 15:06, 10 August 2008 (UTC)
Right, seems we have to keep the "small=yes" option since some users want it.
Well, regarding "smallimageright=none" I thought like this: As you know "imageright" has no "none" option since leaving "imageright" empty defaults to no image. But think of the case where you have a right side image for the large message box, then I think you often don't want an image for the small case since in the small case there normally is not room enough for a right side image. But if you don't feed a "smallimageright" then we fall back to using the "imageright" since all the small parameters should fall back to their larger value if no small data was fed. Thus you need to be able to set "imageright=someimage" and at the same time have "smallimageright=none".
Of course we should probably make {{tmbox/core}} support "imageright=none" too, thus making the parameters more logical. (Which of course will mean the same thing as "imageright=".) That is, since the documentation now will say there is a "image=none", "smallimage=none" and "smallimageright=none" option I expect people will assume that "imageright=none" is a valid setting too. Thus I think we can keep your current version of tmbox but instead add the "(small)imageright=none" handling to tmbox/core.
And yes, I am just about to double check all your tmbox and tmbox CSS class related edits, and run a bunch of tests to see that all works as it should.
--David Göthberg (talk) 20:44, 10 August 2008 (UTC)
Of course, I see what you mean. I think what threw me was the way |smallimageright= supported it but |imageright= didn't. I think that it should be supported for both, as you say. Oh BTW I managed to screw up the CSS, but RockMFR fixed it, so it's all good (now :D). Looks like we're at the final countdown now... Happy‑melon 21:02, 10 August 2008 (UTC)
I have implemented the "imageright=none" and "smallimageright=none" options, tested all the small options properly, and documented them at {{tmbox}}. (I on purpose did not document the "imageright=none" since that one is just there for completeness, but if you guys want that one in the doc then I would be okay with that.) This means the tmbox code is now complete and bug free as far as I know.
I have added support for the small options in {{mbox}}, so that shape shifting templates can support the small style when on talk pages. I ran some tests and it works as expected, when an mbox with the small options set is placed on a talk page it becomes small and shows the small images, when placed on other types of pages it becomes large and shows the large images.
I have also checked the tmbox CSS classes in MediaWiki:Common.css. The code missed the ".tmbox-protection" class, and had no handling of when tmboxes are placed inside other boxes. I fixed that. I have ran a full set of test cases and the CSS classes now works perfectly. This means we can change tmbox to use the CSS classes when the 30 days CSS caching in the web browsers have passed. That is on 11 September 2008.
We need to change some text and add some more examples to bring the tmbox documentation up to the same standard as for the other mboxes.
I think we can deploy tmbox now!
And when we have fixed the documentation for {{mbox}} then we can deploy that one too.
--David Göthberg (talk) 06:48, 11 August 2008 (UTC)
I am very glad to hear that. Standardisation is back on track, and soon enough we'll have finished; I can already see us looking for employment elsewhere.
PS: If the 30 days start from today, doesn't that make it 10 September? Although I'll grant you that 11 September has very special connotations. Here in Greece, especially, it's the day schools open after the summer break. :-) Waltham, The Duke of 13:32, 11 August 2008 (UTC)
Employment elsewhere? Well, I have lots of stuff (some of it pretty cool) on my Wikipedia to-do list, so if you ever feel unemployed... :))
Right, I did the last edit to the tmbox CSS classes in MediaWiki:Common.css at 05:57 11 August 2008 UTC. As I remember it the CSS caching used to be set to exactly 30 days, thus any time after 05:57 10 September 2008 UTC should be good. But before 5:57 would cause problems for some users, thus I usually add a day when I note such dates so I don't need to state the clock. However, I just rechecked: The current CSS pages are set to 2678400 seconds = 31 days. I could have sworn it was 30 days before. Either my memory fails me or Wikipedia sets 31 days now because we are in a 31 days month. Anyway, this means we instead have to wait until 05:57 11 September 2008 UTC, or as I usually state it, any time during 12 September 2008.
Haha! That you put a smiley after the sentence "it's the day schools open after the summer break" proves you are a geek, since only geeks are happy when school starts. (Well, being picky about time maths is very geeky too.) But yeah, here at Wikipedia 99.9% of us are geeks. :))
--David Göthberg (talk) 16:29, 11 August 2008 (UTC)
Actually, I do have a full plate myself, though as far as templates are concerned, I mostly deal with succession box. There's hardly any general interest in that area, and SBS is more or less in limbo at the moment, but I have a new cunning plan to be set in motion within the following months. If I am lucky, this should, at last, turn the tide. (Still, if you have a temp job for me like this one, where I get to comment on style rather than code, let me know.)
I am somewhat geeky, but not in a way that makes me appreciate school in any way. (Simply put, our schools are awful.) I prefer studying my own curriculum; one which often comes straight out of Wikipedia. :-) I do enjoy, though, the way that children have to submit themselves to the bonds of schooling on that day, every single year—especially considering that my own schedule is generally much more bearable.
Yes, I am rather mean, too. (evil grin) Waltham, The Duke of 12:02, 12 August 2008 (UTC)

Template is missing the documentation (Template:Tmbox/doc)

{{editprotected}}

I noticed in the recent update to the template that the documentation information that was automatically displayed from Template:Tmbox/doc (using the {{Documentation}} tag) was removed and is now missing. Please re-add it. 

<noinclude>

{{Documentation}}
<!-- PLEASE ADD THIS TEMPLATE'S CATEGORIES AND INTERWIKIS TO THE /doc SUBPAGE, THANKS -->
</noinclude>

Thanks. Lightsup55 ( T | C ) 15:08, 10 August 2008 (UTC)

Whoops, thanks for catching that one! Happy‑melon 15:27, 10 August 2008 (UTC)

Deploy!

Many colour styles have been suggested and discussed for the talk page message boxes. (See Template:Tmbox/styles and Template talk:Tmbox/styles.) The discussions have been going for a long time and we have announced this discussion in lots of places, including at the village pumps and as a watchlist-notice. We did not reach a proper consensus, but some of us have agreed that for now we can use Waltham's style with 2px borders. To get things rolling we now want to deploy the {{tmbox}}. Since when we deploy it people will notice the new styles and if people don't like it we will get new active discussion here. And we can of course change the styles even after we have deployed the {{tmbox}}. Thus we can adapt to any future consensus.

Apart from the colours there are the minor technical detail with the "small=yes" option that needs further discussion, see section "Back to this page" above.

I think we can deploy right now, even though we have not added the "small" option yet. Right?

--David Göthberg (talk) 21:10, 5 August 2008 (UTC)

What's the rush? This is very unlike you, DG: usually you're the one clamouring for more time to test and develop!! I think the small style is going to be a bit less than perfectly straightforward, as you say, so we need to be sure we've got this down to wraps before making "deploying" noises. If you think the transclusion-count of imbox is bad, remember how many talk namespaces there are, never mind how many pages!! This could quite easily overtake {{portal}} in transclusion count, maybe even give {{!}} a run for its money! It's going to be the first change in the top 5 templates for a long time, anyway. So on this one of all mbox templates, no rush. Happy‑melon 21:20, 5 August 2008 (UTC)
Okay, you are probably right. I will add, test and document the "small" functionality first.
--David Göthberg (talk) 21:31, 7 August 2008 (UTC)
I think that we are ready stylistically (we know what we want) but not quite programmatically (we haven't gotten it yet). I wrk mostly with style issues so whenever David says we're ready on the technical end is fine by me.--HereToHelp (talk to me) 23:21, 8 August 2008 (UTC)
Same with me. Waltham, The Duke of 16:44, 9 August 2008 (UTC)
After examining the Documentation, which as of this post now includes the functionality for small=yes, I'd say that this Template is a go for deployment. Well done upgrade of the Coffee Roll standard of 2005 for new requirements. B. C. Schmerker (talk) 04:37, 11 August 2008 (UTC)
Thanks for everything guys.
Yesterday Happy-melon added a description in the tmbox documentation of when to use which type. I think it is a good description.
I also noticed that Happy-melon added the tmbox CSS classes to {{tmbox}}. This means the boxes can be skinned already now, by using the "!important" keyword. But we also still have the hardcoded styles there so the boxes will work well for everyone even though the 31 days CSS caching in the web browsers has not passed.
So I say we are ready. Gentlemen, fire up your browsers and start DEPLOYING!
As usual, if you find any tricky cases list them on this talk page and the rest of us can help out.
--David Göthberg (talk) 08:43, 13 August 2008 (UTC)

Width bug?

I found this when trying to use a collapsible table inside a tmbox. How do we gracefully stop the show/hide button disappearing out of the right hand side of the box? Happy‑melon 13:10, 12 August 2008 (UTC)

I don't see any problem in that revision of that template. It looks good in all three of my browsers (Firefox 2, IE 5.5, Opera 9) and in all different screen resolutions and window widths I've tried. The [show/hide] button works fine and sits exactly where it should in the upper right corner for me.
I see that you "fixed" it in your next revision by using 90% width, but then it looks bad in my browsers.
In what browser do you see the problem?
--David Göthberg (talk) 17:09, 12 August 2008 (UTC)
This is the appearance of the box on IE7.0/XPh-SP2. My 'fix' doesn't make the box look particularly brilliant on my display either, but I wanted to build in some conservatism for alternative font sizes, resolutions, etc. A proper solution would be infinitely preferable. Happy‑melon 19:58, 12 August 2008 (UTC)
I took a look at your image. Ouch, ugly bug indeed. I don't see anything like that in my browsers, they all show the whole [show] button well within the tmbox border.
Please, can someone else who reads this page and that happens to have a recent Internet Explorer version take a look and tell what they see?
--David Göthberg (talk) 04:21, 13 August 2008 (UTC)
I am seeing just a bracket there, but this version of IE is not the most recent. --NewbyG (talk) 04:45, 13 August 2008 (UTC)
My Firefox 3 displays it just fine, but my Internet Explorer 7 only shows the left bracket. Waltham, The Duke of 22:56, 13 August 2008 (UTC)
I don't think we can fix this by any sane change in the tmbox code. I think the javascript and/or CSS for the [show/hide] function needs fixing instead. Thus I think this should be reported to those that coded the [show/hide] function. (Don't know who they are and where to report to them.)
--David Göthberg (talk) 02:34, 14 August 2008 (UTC)

Simpler to use class names

I am thinking of changing the naming of the CSS classes for all the different kinds of mboxes. See my discussion about that at Template talk:Mbox#Simpler to use class names.

--David Göthberg (talk) 09:30, 14 August 2008 (UTC)

Conversion

Hi, I've converted most of those in Category:Article talk header templates that needed doing but there were a few left that are protected. If someone else wants to do them the that would be good, otherwise I'll have to post some {{editprotected}} messages at some point, but I'm going to do some more unprotected ones first. -- WOSlinker (talk) 18:27, 16 August 2008 (UTC)

All done. Happy‑melon 20:09, 16 August 2008 (UTC)
WOSlinker: Wow, you have been working hard! I checked some of your edits and they were perfect, you even got the tricky image handling for "small=yes" right! Very nice work. Thanks a bunch!
And you did right in listing the protected boxes here. Since if you had used {{editprotected}} then the admin trying to handle it might not know how {{tmbox}} works. While this talk page is watched by several admins that know the details of tmbox.
--David Göthberg (talk) 04:34, 17 August 2008 (UTC)

Three more that need looking at:

I also converted {{Oldprodfull}} but it was reverted by Rockfang. Should I make the change again? -- WOSlinker (talk) 10:09, 17 August 2008 (UTC)

 Done. I also restored the change to {{oldprodfull}}, with links to the discussions here. Happy‑melon 14:23, 17 August 2008 (UTC)

Another protected one:

And two that are too fidily for me

-- WOSlinker (talk) 18:05, 18 August 2008 (UTC)

More:

-- WOSlinker (talk) 06:59, 19 August 2008 (UTC)

Another two that may be able to be converted but I'm not sure about the bit at the start of those templates, so haven't converted them myself.

-- WOSlinker (talk) 00:06, 25 August 2008 (UTC)

margin_bottom

The current box seems to have a non-standard margin_bottom, if compared with the messagebox-class.
It seems to me that all those infoboxes have a margin_bottom of 1em, this one has 4px though (if !small), which makes for a non-standardized look of eg. {{controversial}} on Talk:Michael Jackson.
Since there's already a lot of style information in tmbox/core I recommend changing "margin: 4px 10%;" to "margin: 4px 10% 1em;". An alternative would be to work the messagebox-class into it.
I don't know if this has repercussions I'm not aware of though. :)
AmaltheaTalk 10:29, 17 August 2008 (UTC)

The "1em" margin you see in the small style is the left side margin, not the bottom margin. The {{tmbox}} (and the "tmbox" classes in MediaWiki:Common.css) has 4px top and bottom margin, both in the full box size case and in the "small=yes" case.
The top and bottom margin has been discussed among others in the sections Stackable, Some examples and Back to this page above. Some wanted the boxes to stack tightly, some wanted pretty much space between them. The 4px top and bottom margin is thus a compromise.
The discussions on this page created a new standard for talk page message boxes. (But for the default "notice" style it is very similar to the old standard.) Thus the 'class="messagebox standard-talk"' is now the old standard and should now be phased out.
The reason the different talk page boxes on for instance Talk:Michael Jackson currently look a bit odd together is that many of the boxes you see there have not yet been updated to the new talk page message box standard. We just deployed the new standard some days ago and we have just started to update the old boxes. So be patient, some weeks from now that talk page is going to look fine with the same margins and widths on all the boxes.
By the way, most of the WikiProject boxes you see on the talk pages can not use the {{tmbox}} meta-template since they need lots of extra functionality. So they will instead use the tmbox CSS classes directly. However due to the 31 days caching of the CSS pages in the web browsers we can not deploy those classes before 12 September 2008. That is why {{tmbox}} currently uses hardcoded styles. And that means we should wait to update the WikiProject boxes until 12 September.
--David Göthberg (talk) 11:45, 17 August 2008 (UTC)
Oh alright, thanks for the exhaustive answer. :)
I searched the page for "margin" first, but somehow didn't see that it had been discussed.
If the new classes and thus the new margins of 4px won't be used anywhere outside tmbox until mid September, would it make sense to temporarily have a hardcoded 1em margin here as well, or are you worried that users of this box would rely on the 4px margin (which they shouldn't in any case)? That way we could have neatly consistent boxes in the next month, too.
Cheers, AmaltheaTalk 12:25, 17 August 2008 (UTC)
Well, they used the term "space" in the discussions above. :))
Good idea to make the old and new boxes match. But I would like to do it the other way around. After all, most browsers do reload the CSS pages more often than once a month, so most users will see new styles fairly fast. So I suggest we instead update the margin in ".messagebox.standard-talk" to match our new standard! Thus making that class look like this:
.messagebox.standard-talk {
    border: 1px solid #c0c090;
    background-color: #f8eaba;
    margin: 4px auto;
}
--David Göthberg (talk) 13:25, 17 August 2008 (UTC)
Right, that's better. I'm guessing that ".messagebox" is used in various places which is why you chose ".messagebox.standard-talk"?
If I'm not mistaken MediaWiki:Common.css is loaded with a timestamp in the query parameters - are there really browsers that'll get it from the cache anyway?
AmaltheaTalk 13:54, 17 August 2008 (UTC)
Right, if you look in MediaWiki:Common.css you'll see there are a whole bunch of ".messagebox.something" classes there for different needs. ".messagebox.standard-talk" matches the code <table style="messagebox standard-talk"> in a template, so that template will get whatever styles we set for ".messagebox.standard-talk" in the CSS files.
Well, I don't know exactly how the caching stuff works in different browsers. But I know that the Wikipedia style sheets are marked to be cached for 31 days. And I know that when we deployed {{ambox}} immediately after making the CSS classes, we got complaints from people for some weeks. We had to tell them how to force their browsers to reload the style sheets and that helped. (But millions of users out there who were not Wikipedia editors and thus didn't ask on the talk pages probably saw ugly boxes for some weeks...) So apparently some browsers do cache the style sheets for that time.
--David Göthberg (talk) 15:04, 17 August 2008 (UTC)
Thanks, looking good. :) --AmaltheaTalk 23:08, 20 August 2008 (UTC)

Script talk header templates

I've done all those in Category:Script talk header templates apart from {{Cyrillic}} & {{Arabic}} which were a little bit more complex so I've left them for the moment. If somebody else wants to look at them then that would be good.

Also, when Davidgothberg converted {{Khmer}} he also added some more options to allow use on both article & talk spaces and also used the type = style parameter. Is it worth doing something similar with the others to match that one and should I be using type=style? -- WOSlinker (talk) 15:30, 17 August 2008 (UTC)

I like what DG has done to {{Khmer}} - I'd recommend that that be copied to all the script templates. Happy‑melon 16:42, 17 August 2008 (UTC)
The Swede has gone berserk: This case and some other similar cases I have seen inspired me to come up with the {{namespace detect showall}} meta-template. It covers all namespace detection cases I can think of (even a bunch of hypothetical future cases) in a single template.
For simple two template cases like {{Khmer}} it is perhaps too complex, but anyway I thought you guys would like to take a look. We can of course make simpler to use templates for cases like these when only two namespaces are involved. In this case I would name it {{main talk showall}}.
--David Göthberg (talk) 14:30, 21 August 2008 (UTC)

Deprecated ambox parameters

Happy‑melon: Today you added some old deprecated type parameter names from the {{ambox}} to the {{tmbox}} and the other mboxes. Please don't do that. We deprecated those type names long ago since they caused a lot of confusion. Please don't bring that confusion over to the other mboxes. That's why we removed them from the ambox documentation long ago.

Instead I am planning to add detection in ambox of when it is used with the deprecated parameters and then let it categorise such cases into a maintenance category. So we can fix those cases and finally get rid of those deprecated types. I have used that approach several times before, and it works very well. See for instance CAT:SHORTFIX, Category:Wikipedia namespace detection clean-up and CAT:CATREDFIX.

I am also planning to do such detection to find any {{imbox}} cases that use the deprecated "bigimage" parameter.

I just haven't gotten around to do this clean-up.

I will revert your changes to the mboxes, so no one starts to use the "new" type names.

--David Göthberg (talk) 18:26, 17 August 2008 (UTC)

Perhaps a note to indicate that they were deprecated would have been helpful? I'm not psychic you know. Happy‑melon 18:35, 17 August 2008 (UTC)
To expand on that admittedly rather terse comment (although you really want to be careful when informing people that they've acted counter to some ancient consensus - 99% of the time it's through ignorance, not malice), why was the decision made to bury these parameters under the rug? At the very least, HTML comments in the wikicode (which I have just added) would have prevented confusion. Otherwise you actively encourage the see-a-problem-find-the-problem-fix-the-problem edits that I just reverted. Happy‑melon 18:49, 17 August 2008 (UTC)
Happy-melon, you seem to have put those depereciated comments in ambox against the delete and move type options but that doesn't appear to match up with the template documentation where they are shown and it's appears to be serious and merge that are depereciated as they are not in the docs. -- WOSlinker (talk) 19:02, 17 August 2008 (UTC)
Good point! I've reordered the parameters so that the deprecated ones are aligned with the comments. Happy‑melon 20:42, 17 August 2008 (UTC)
Happy-melon: Yeah, we should have noted in the source or in the doc that those parameters are deprecated. We've been more careful with the deprecated "bigimage" parameter in {{imbox}}. It was pretty chaotic back then when we standardised the ambox. It was a new experience for all of us.
As far as I remember the red "type=serious" style was renamed to "type=delete" since it is made for deletion templates, but lots of people thought it was for "major warnings". But non-deletion related major warnings are the orange "type=content" style. So we had lots of confusion.
The purple "type=merge" style is made for move, merge, split and transwiki templates. "merge" sounds strange when you do a move, split or transwiki. But all those things are "movements". And people were arguing about if correct grammar is "merge" or "merger". So we changed to "move".
Thanks for having patience with me. I should have explained better.
--David Göthberg (talk) 21:59, 17 August 2008 (UTC)
That's ok, we've all got a handful of these things-I-really-must-get-round-to-tidying-up loose ends floating around in our in-trays - I know I keep finding ones of mine! I can appreciate the value of having only one parameter for each class, and the logic of the names that were chosen. How about we have a look and see how many templates would need changing to get them completely deprecated? I'll add something to {{ambox}} and see what drops out. Happy‑melon 20:21, 18 August 2008 (UTC)
Ok, they should be filtering into Category:Ambox templates using deprecated types - we can fix all the templates that show up, then widen the code to all pages for any stragglers. Then we should be able to remove the types from ambox entirely. Happy‑melon 21:22, 18 August 2008 (UTC)
Ah, you do it exactly like I used to do such searches, nice! Yeah, it can be nice to start with a "tight" search like you do now, to first handle the easy/obvious cases. Then as you say we can widen the search to all namespaces to find any cases where amboxes are used with the deprecated parameters directly on a page. We can even widen the search further after that, that is we can check if there are any cases where invalid or misspelled parameter values are fed. (Like "type=contnet".)
But I became inpatient with searching like that some time ago, since one has to wait several days between each widening, since it can take up to two weeks to see all cases, since categorising is ran as a low priority task by the Wikipedia servers. So I invented a method to do the full search already from the beginning: We can sort the category on the full page names, thus any templates will be sorted under "T" and thus easy to find and fix first. To avoid getting all articles that start with "T" under "T" too, we can detect namespace and add "Main:" before the article name in the sort parameter to the category. Here's the code I would use for the ambox search:
{{#switch:{{{type|}}}
|   <!-- No type fed, is valid input -->
| speedy
| delete
| content
| style
| move
| protection
| notice     =    <!-- Do nothing, valid "type" -->
| #default   = [[Category:Ambox templates using deprecated 
types|{{main other|Main:}}{{FULLPAGENAME}}]]
}}
Note: I artificially wrapped the long category name in this example to make it fit in my browser window, restore to one line before using it.
But since this is the widely used ambox I think we should wait with adding this code until we have taken care of the currently visible templates in that category, since we might get so many page hits that it makes it hard to go to "T". And I ran some tests, the code above seems to do what it should.
--David Göthberg (talk) 07:24, 19 August 2008 (UTC)

Would this be any better: 

{{#switch:{{{type|}}}
|   <!-- No type fed, is valid input -->
| speedy
| delete
| content
| style
| move
| protection
| notice     =    <!-- Do nothing, valid "type" -->
| #default   = [[Category:Ambox templates using deprecated types|{{{type}}}]]
}}

Which would sort the category by the type values for those included. -- WOSlinker (talk) 11:04, 19 August 2008 (UTC)

The days of it taking days or weeks for categories to update are gone now - Tim recently quadrupled the number of job-queue-parsing maintenance threads running on the wikimedia servers, and your "categories may be several days out of date" message, which I keep meaning to remove, was added at the time when we had that clock error that screwed all the maintenance threads and left the job queue at 15 million for a week. Leaving it overnight is invariably enough these days - like the whole editing-ambox-will-crash-the-servers mentality, unfortunate coincidences have conspired to give us an unnecessarily negative approach to category updates.
I do, however, like your idea of looking for amboxes with any unapproved class. Once we've done the twenty or so that are now in the maintenance cat, we should definitely have a look at those. Happy‑melon 21:02, 19 August 2008 (UTC)
WOSlinker: Hehe, that was a nice idea. But I think we should sort on namespace for starters. Since we want to find and fix any cases in template space first, since they in turn usually cause a lot of hits in the other namespaces. Perhaps we should combine both? That is to sort on "namespace + type + pagename". Since then we get the thing I guess you are after, to get similar cases (probably caused by the same editor) sorted together, but still we can take care of template space first.
Anyway, since we have emptied the category I have now widened the search to all namespaces. I used my code above for now.
Happy-melon: I hope you are right that categorising is that much faster now. But I don't think we should remove the MediaWiki message I added some time ago "Updates to this list can occasionally be delayed for a few days", since it seems to still sometimes take up to some hours. Instead we should perhaps change it from "days" to "hours". But I have done this kind of searches fairly recently, and then it seemed the old rule still applied: A page only gets sorted into the category when it gets re-rendered. And pages don't get re-rendered (and thus parsed) until someone visits them. So pages that doesn't get many visitors can pop up in our category loooong after we added/changed the error-reporting code. Of course, for pages where an editor by hand adds a category (compared to some template doing it automatically) then the page gets re-rendered immediately since that editor views the result when he's done, thus the categorising for that page immediately gets put on the job queue and as you say now should be categorised pretty fast.
--David Göthberg (talk) 07:13, 21 August 2008 (UTC)
The ambox change you made is not working because you left in the line break between "deprecated" and "types". -- WOSlinker (talk) 13:30, 21 August 2008 (UTC)
Oops, how embarrassing. (I even noted above that whoever should paste it should take care about that. Well, I know what kind of mistakes I tend to do...) I have fixed it now. Thankfully it was only in the category name so the template itself still worked okay.
Thanks for catching that bug, I kind of thought it was strange that we had no stragglers out on other namespaces. Now that category is filling up with pages neatly sorted by namespace. :))
--David Göthberg (talk) 14:45, 21 August 2008 (UTC)

Deprecated ambox parameters, section break 1

I have now fixed the remaining non-userspace cases with invalid "type" parameters. I don't feel like manually fixing the remaining 79 user space cases. Instead I would like to make it so that the error detection also adds a line of text directly below the message box stating something like:
This message box is using an invalid "type={{{type|}}}" parameter and needs fixing. (learn more)
That will probably also stop people from adding new cases.
And at the same time I do that edit I want to finally remove the support for the deprecated "type=serious" and "type=merge" parameters.
And now I will go ahead and add error detection to the other mboxes.
--David Göthberg (talk) 22:11, 1 October 2008 (UTC)
I have added error detection to the other mboxes. They report to Category:Wikipedia message box parameter needs fixing. As far as I can see I have cleared out all cases there. But the updates to the category listings are currently delayed several hours, so hundreds of cases linger in the list. The same goes for the ambox cases I fixed, some of them are still listed in Category:Ambox templates using deprecated types.
Happy-melon: Do you see now why I want the system messages in the category listings to say "Updates to this list can occasionally be delayed for a few hours"?
--David Göthberg (talk) 07:37, 2 October 2008 (UTC)
The comment below was moved here from the talk page of David:

Any reason not to add class="error" to the error message? —Ms2ger (talk) 16:46, 4 October 2008 (UTC)

Oh, I tried it out. Hehe, VERY visible. The reasons that I didn't use it was two: 1: I didn't know about it. 2: I didn't hand-code such a big bold red text since for non-urgent warnings like this one I usually prefer to use the soft approach: That is to start with a low intensity warning, to not stress people too much. (And some also find big error messages rude.) Then I usually increase the warning level until people have fixed most cases. Then I/we can fix the remaining cases. So we started with the category that gets visible at the bottom of the pages. Yesterday I added the next level with a not too intrusive message in plain text directly under the amboxes. So I think we can wait some days and then we can apply the "error" class to make the text big bold and red.
A nifty thing with the error message (even if it is in normal text size) is that when I/we work through the error category it makes it much easier to see which box on a long page is the one that needs fixing.
And the soft approach means that we start out slowly and gives us time to answer questions from people and work in those responses in the explanation at the error reporting category. Because if one starts the hard way one gets flooded with worried questions from lots of people. I usually even start with a hidden category, so I get no questions at all but get some time to see what kind of errors there are out there so I can write up a good explanation at the category page what needs to be done. And so I can fix those templates that affect thousands of pages before going public.
All this might sound like a lot of work. But it just means I do the same amount of coding work, but spread it out over time. And it actually means much less work, since it saves me handling a lot of confused people.
--David Göthberg (talk) 18:32, 4 October 2008 (UTC)
Good point, thanks for the explanation. —Ms2ger (talk) 19:51, 4 October 2008 (UTC)

Nested strikes back...

Boo! :D I've just come to a realisation that our deciding not to support the nested style in {{tmbox}} is probably going to bite. When the cache on the new tmbox classes expires we are (I assume) going to deprecate and replace the "messagebox ..." classes; but the nested style is defined in MediaWiki:Common.css as 

.messagebox.nested-talk {
    border: 1px solid #c0c090;
    background-color: #f8eaba;
    width: 100%;
    margin: 2px 0 0 0;
    padding: 2px;
}

Which of course means it will only apply if the "messagebox" class is also applied. Politest way to describe the result (we'll need class="messagebox nested-talk tmbox tmbox-notice" for nested boxes, I think <shudder>) is "messy". We need to add something to Common.css so we can phase out "nested-talk". Can you tell me if the addition I made to {{tmbox/core}} is correct? If so, I think we can declare "tmbox-nested" using the same syntax as "tmbox-small": 

table.tmbox-nested {
    width: 100%;
    margin: 2px 0 0 0;
    padding: 2px;
}

Then I can use something neat like 

{| class=tmbox {{#switch:yes|{{{nested|}}}=tmbox-nested|{{{small|}}}=tmbox-small}} tmbox-notice
...

to invoke the necessary classes in wikiproject banners. Of course, we could just as easily add that code to {{tmbox/core}} in place of what I just added. Wouldn't require much retrofitting - none of the templates we've converted thus far have any use for nested styles. Probably 100 bytes extra to {{tmbox}}. Then we could convert every talkspace template to tmbox... :D

Appologies for the horrible rambling nature of this post, but I think we need to come to some conclusion and get code live into Common.css, or the messagebox classes are going to last a long while yet... Happy‑melon 18:11, 26 August 2008 (UTC)

Yes, you added the "tmbox-small" class to {{tmbox}} in the exact right way.
And regarding "tmbox-nested": He, at first when I saw your code it seemed all right. But then I remembered: I am way ahead of you! We don't need the "tmbox-nested" class at all. The tmbox CSS classes already have full automagic support for nesting tmboxes inside each other. Thus we don't need the "nested=yes" parameter in the WikiProject banners anymore! However that isn't visible at the moment since {{tmbox}} currently uses hard coded styles. But we do have the exact same kind of CSS code for the {{imbox}}. Take a look at these nested imboxes:
{{imbox
| image = none
| textstyle = text-align: center;
| text = 
  '''This article is within the scope of the following WikiProjects:'''
  {{imbox|text=Inner box}}
  {{imbox|text=Inner box}}
}}
Oops, seems I need to tweak the margins a little. The imbox never needed two inner boxes so I didn't give it any top and bottom margin when inside. But I'll fix that, for both the imbox and tmbox. And it is on my to-do list to fix the slight oddity with the left margin. (I know how to do it.) But anyway, as you see basically it works fine.
And it also works with the new "simpler to use CSS classes", that is when instead of "tmbox-text" we use "mbox-text". Below is a hand coded example with the new classes. (You might need to purge your browser's cache since I deployed this CSS code just some day ago.)
<table class="tmbox tmbox-notice">
<tr><td style="width: 1px;">
<td class="mbox-text" style="text-align: center;">
'''This article is within the scope of the following WikiProjects:'''
  <table class="tmbox tmbox-notice">
  <tr><td style="width: 1px;">
  <td class="mbox-text">Inner box
  </table>
  <table class="tmbox tmbox-notice">
  <tr><td style="width: 1px;">
  <td class="mbox-text">Inner box
  </table>
</table>

This article is within the scope of the following WikiProjects:

Inner box
Inner box
I guess you want the inner light brown box background as you have in the current wikibanners? That takes some extra tweaking. I am thinking we should use the same method as the "below=" parameter in {{imbox}}. But this would be a special below area that gets the light brown background, so I would like to give it a different name. Perhaps call it "banners=" or so.
And I have already fixed the current {{WikiProjectBanners}} and {{WikiProjectBannerShell}} by tagging them with the "mbox-inside" class. That class has no effect on those templates themselves, but it allows boxes that use the "tmbox" classes to detect that they are inside another box and then get full width instead of 80% width. Look at these examples:
{{WikiProject banner shell|collapsed=yes
| 1 =
  <table class="tmbox tmbox-notice">
  <tr><td style="width: 1px;">
  <td class="mbox-text">Inner box
  </table>
  <table class="tmbox tmbox-notice">
  <tr><td style="width: 1px;">
  <td class="mbox-text">Inner box
  </table>
}}
{{WikiProject banner shell
| 1 =
  <table class="tmbox tmbox-notice">
  <tr><td style="width: 1px;">
  <td class="mbox-text">Inner box
  </table>
  <table class="tmbox tmbox-notice">
  <tr><td style="width: 1px;">
  <td class="mbox-text">Inner box
  </table>
}}
{{WikiProject banner shell
| 1 =
{{WikiProject Discworld|nested=yes|category=}}
{{WikiProject Knots|nested=yes|category=}}
}}


So there is a little more work before the {{tmbox}} has full support for the banner shells. And we can't deploy the functionality before we change tmbox to use the CSS classes instead of hard coded styles.
--David Göthberg (talk) 01:44, 27 August 2008 (UTC)
I looked a bit more at the code in {{WikiProjectBannerShell}}. It needs the "collapsible collapsed/uncollapsed" classes. And as far as I remember the javascript for the collapsible system looks for a "th" tag to place the [show/hide] button in. So we need to have the header in a "th" tag instead of a "td" tag. Also the banners that are put into it needs those things. So either they need to be hand coded but can use the tmbox classes, or I can fix it like this:
I'll add the parameter "class=" so we can feed the extra class names.
I'll add the parameter "header=" that take the header text and that uses a "th" tag instead of a "td" tag. I don't want to call it "above=" since it uses a "th" tag, so it isn't a normal above area.
Both those things are pretty easy to add to {{tmbox}}. And as I previously stated, I'll add a "banners=" parameter that creates the light brown area below.
Of course, this might sound like a lot, since the {{WikiProjectBannerShell}} is only one very special box so it could use a hand coded table with the tmbox classes in. But it would be good if all the project banners that are put into it can use the {{tmbox}}. And they will need the "class=" and "header=" parameters. And that means all we need to add to accommodate {{WikiProjectBannerShell}} itself is the "banners=" parameter. So we might just as well go all the way.
--David Göthberg (talk) 02:31, 27 August 2008 (UTC)
Gah! I looked more at the different templates involved and how they behave at talk pages. Ouch, they are more complex than I thought. Both {{WikiProjectBanners}} and {{WikiProjectBannerShell}} sometimes show a message below the project banners, below the light brown area. And the project banners hide their header when they are not inside a {{WikiProjectBannerShell}}. I think I can handle that hiding with CSS.
I need to look more into this and think more.
--David Göthberg (talk) 03:32, 27 August 2008 (UTC)

Nested strikes back (section break 1)

I've spent a very patient few months trying to get {{WikiProjectBanners}} and {{WikiProjectBannerShell}} to a stage where they can be merged: my first attempt was an absolute trainwreck, but I've since adopted the softly-softly approach. Adding the formatting was the last alteration, and seems to have been accepted; the two banners are now syntactically identical: {{WikiProjectBanners}} is now identical to {{WikiProjectBannerShell|collapsed=yes}}. So it sounds to me like you're considering including a lot of functionality into {{tmbox}} that will only ever be used on one template. I don't think that's worth it. Similarly, we're in the middle of the very laborious process of converting all WikiProject banners to use {{WPBannerMeta}} (394 down, 819 to go!), which as you can see is hideously complicated (my recommendation as its architect: use a non-wrapping text editor or your head will explode!); I don't think any amount of modifications to {{tmbox}} will enable us to use that metatemplate there, plus it provides a level of abstraction that we don't really need there (anyone who isn't already familiar with the tricks involved in tmbox has no business editing that template!). I am planning on using the classes directly. There are only a handful of banners that I predict will never be converted to use WPBannerMeta (like {{WPBiography}} and {{AfricaProject}}, which are themselves almost as complicated - there are ten banners in CAT:WPB that have over fifty parameters!) and they will also probably never use tmbox. But in the 'big picture' we have two 'god templates' - {{WPBannerMeta}} and {{WikiProjectBannerShell}} - that 99% of templates involved with the nesting will use.

If you can come up with a way of persuading WikiProject banners to collapse automatically inside {{WikiProjectBanners}} without substantial modifications to them, then I will quite honestly bow down and worship: the problem of most instances of {{WPB}} not having the |nested=yes parameter set in their sub-banners is the only real obstacle in the way of a WPB-WPBS unification. It seems that with the mbox-inside class, you're already part of the way there. I've added the current situation to the bottom of your example, which demonstrates that we need to play around with the margins a bit, but otherwise it seems very good.

My conclusions from your comments and my experience are as follows:

  1. We don't need to add a .tmbox-nested class, because .tmbox .mbox-inside handles that functionality perfectly
    1. Some adjustment of the margins/cellspacing/padding/whatever of .tmbox .mbox-inside .tmbox declaration needed to improve the matching with the existing method
  2. {{WikiProjectBannerShell}} should be hardcoded, as it's too much work and codebloat to modify {{tmbox}}
    1. {{WikiProjectBanners}} will eventually be merged with WPBS - the more successful this operation here, the faster that merge will become politically viable
  3. {{WPBannerMeta}} and the handful of complicated banners should remain hardcoded, for the same reason
    1. If you can find a reliable way to achieve the same effects as the |nested=yes parameter without actually passing it, great; I doubt it's possible, however. All glory to the person who manages it, however... :D

Thoughts? Happy‑melon 11:00, 27 August 2008 (UTC)

Yes, now that I have more understanding of this I think you are right, right and right. So yeah, what I can supply is CSS classes that automate most/all of the sizing. And I have an idea how to make CSS that handles your point 3.1 above. Do I understand it correctly that it should work like this? :
When a banner is shown on a page without being surround by {{WikiProjectBannerShell}} then it should not have its header, and no [show/hide] button, and be full size.
But when shown inside {{WikiProjectBannerShell}} then it should have the header, and the [show] button, and be collapsed.
Right? But these things are tricky, I'll report back in some days when I have experimented with it.
--David Göthberg (talk) 11:38, 27 August 2008 (UTC)
That's exactly right. I think the biggest issue is the collapsing/non-collapsing: that might need javascript as well as CSS.
I've been playing around at http://test.wikipedia.org/wiki/User:Happy-melon , however, and I'm running into nasty style issues. I'm trying to set up the system with the classes it will eventually use, and the box widths are screwing up all over the place. And I was only trying to see how we needed to adjust the margins in mbox-inside! You might want to take a look (you'll need to copy my monobook.css and .js from over there (the .js has a complete copy of en.wiki's common.js for the collapsing tables)) lest we find ourselves in deep water for some reason. Of course, I've probably just forgotten something trivial... :D Happy‑melon 11:48, 27 August 2008 (UTC)
Instead of looking at your code I have been testing my own ideas. Without the "nested=yes" parameter we can not get the exact behaviour of the header we described above. (Unless we change the javascript.) I can use CSS to show and hide the header at the right times, but unfortunately the javascript still hides the content cell below the header even if the header cell is hidden, that is even if the [show/hide] button itself is hidden.
But then I realised we are going about this the wrong way. There is a simpler solution. Already from starters I though it was strange to have a header that we only show sometimes. Since the header currently is not shown when the banners are used without the bannershell they have to repeat the text from the header in their first content sentence. Which looks strange when we [show] the boxes when inside the shells. So why not keep the header at all times? And instead use the "autocollapse" feature? Then we don't even really need the shell, since if several banners are placed on the same page they will neatly collapse. But it also works with the bannershell so people can still use it if they want to.
Below are two examples, one with the shell and one without the shell. The code for the boxes inside are identical. (This is just rough test code, it works in my IE and Firefox but the widths screw up in Opera.)
With a (hardcoded) bannershell:
This article is within the scope of the following WikiProjects:
WikiProject Discworld
Content
WikiProject Knots
Content
WikiProject Ottawa
Content
The same banners but without the bannershell:
WikiProject Discworld
Content
WikiProject Knots
Content
WikiProject Ottawa
Content
I think autocollapsible banners would be much better.
Oh, and this will make the banners look the same in both {{WikiProjectBanners}} and {{WikiProjectBannerShell}}.
--David Göthberg (talk) 19:46, 27 August 2008 (UTC)
In the case we do want to keep the current behaviour (or something quite close to it), I have written JavaScript to enable this, without the nested parameter: test:User:Ms2ger (code).

The thing is, it's not really a header. If it were possible to define it as a normal cell, we probably would have (and then bolded it anyway :D). It's just the only available way of getting the necessary hidden-content effect. I think that most people would consider it an improvement if it were possible to have either-or: clicking the 'show' button hides the nested display and brings up the whole banner. I also suspect that deprecating the shell entirely is going to cause serious rumbles; probably insurmountably so. Some people like the ability to collapse the shell itself (particularly WPB which is collapsed by default) as that further reduces the space taken up by banners. In some places, like Talk:Barack Obama, the number of banners is otherwise unmanageable. I think we should be limiting ourselves to trying to autocollapse banners in the current fashion when inside WPBS, but without passing |nested=yes; if this could be achieved using a suitable combination of JS and CSS, it would be a great step forward. Hiding the header when the collapsed banner is expanded would be an interesting, but probably not tremendously useful, exercise. Happy‑melon 13:33, 28 August 2008 (UTC)

Also, wouldn't using autocollapse remove our control over the nested nature of the banners? AFAIK, every banner after the first one is collapsed whether or not it's inside a shell. If {{ArticleHistory}} is present on a page (usually it's at the top) then all the banners will be collapsed whether we want them to or not; that's not helpful if the talkpage only has one or two banners plus ArticleHistory. The usual methodology is to add a shell when there are three or more banners, and collapse the shell if there are more than about ten (a rarity, but not unheard of). Using autocollapse would shift the workload onto preventing the banners from collapsing when it's not desired, which I don't think is going to be very popular :D Happy‑melon 14:54, 28 August 2008 (UTC)

Ms2ger: I am duly impressed. (No irony intended, that seems to be some nice coding.)
Everyone: But I still think the header cell should be shown/used both when the banners are in a shell and when not used in a shell. I am not especially interested in how and when they should collapse, sorry. (Since I think the whole collapsible thing is bad from the beginning, I rather scroll a page and see what's there.)
I think I have solved the margin problem for tmbox banners inside tmbox bannershells:
It seems the only time a tmbox is put inside a tmbox is when it is a banner put in the light brown lower cell of a bannershell. And that light brown cell is not a regular tmbox-text cell, but a hard-coded special cell. Thus tmboxes inside tmboxes doesn't need the old automatic negative margins handling that we used in the imbox. So I will remove that functionality from the tmbox classes since it interferes with the banners.
Instead we can simply use the "mbox-inside" in this case. That is, in the light brown bannershell cell we can put the class "mbox-inside" and then we make the ".mbox-inside .tmbox" class set 2px borders. Thus the banners inside the light brown cell gets 2px borders and 100% width.
This means that the bannershell itself can use the tmbox classes if we want to without it making the banners inside automatically misbehave and get negative margins.
I will test this solution a bit more when I get the time and then I will update the tmbox classes in MediaWiki:Common.css.
If any other box needs to have tmboxes inside and have more than 2px margins then it can simply use more padding in the cell where it puts the tmboxes. And if it needs more padding between several tmboxes placed inside it then we can make a special class for that, say a "tmbox-inside-4" class that uses 4px padding. But I am not aware of any such usage cases. But anyway, if the need should arise we know how to fix it.
--David Göthberg (talk) 19:18, 14 September 2008 (UTC)

Nested strikes back (section break 2)

In the above discussion, I see two issues that might cause you trouble when you try to implement this:

  1. {{WikiProjectBanners}}, as far as I've ever known, is supposed to be used without the "nested" parameter. A disadvantage of using nested in there is that you have to click twice to see the details of any particular banner. Some of those who prefer WPB to WPBS might complain, unless they all only like it because they despise the banners' existence at all.
  2. Keeping the header all the time will make banners somewhat larger when non-nested, which will annoy those who hate that banners exist at all.

Personally, neither of those bother me. I prefer WPBS to WPB. Anomie⚔ 00:10, 20 September 2008 (UTC)

Right, {{WikiProjectBanners}} doesn't use the "nested=yes" parameter in the banners put inside it. But that is since the banners in there should not collapse. But the first thing that the tmbox classes will supply automatically is that the banners get 100% wide when put inside {{WikiProjectBanners}} or {{WikiProjectBannerShell}}. I don't think that the {{WikiProjectBanners}} users will dislike that the inner boxes become 100% wide and thus use the space in there better.
But if they don't want the 100% width then all they have to do is to not use the "mbox-inside" class in the {{WikiProjectBanners}} template. That is, if any kind of box has the "mbox-inside" class then a tmbox placed inside it gets 100% wide.
We originally developed this functionality for the {{imbox}} since it is often placed inside other boxes. Thus we have tagged the boxes that sometimes have imboxes inside with the "mbox-inside" class. This was the simplest solution and it works very well. And I did put the finishing touches to this functionality for the tmbox classes some days ago. So the tmbox classes already have this functionality, but we can not use it before 17 October 2008 due to the 31 days caching of the CSS files in the web browsers. (And unfortunately this can't be hard-coded as style=" " parameters while we wait.)
The other issue is the collapsing. Ms2ger has done work with the javascript for the collapse function and shown that we can automatically adapt the collapse behaviour if the banners are inside the {{WikiProjectBannerShell}}, thus making the "nested=yes" parameter unnecessary. (See his link above.) So it seems doable to make code that auto-collapse in {{WikiProjectBannerShell}} but not in {{WikiProjectBanners}}. But frankly, I have always disliked the collapse functionality for any use, I am not a "scroll challenged" user. So I am not going to spend any coding time on the collapse functionality, since there are plenty of other things that I actually care about that I can spend my time on. The rest of you guys have to take care of that. Oh, and I should perhaps mention that MediaWiki talk:Common.js seems to be "owned" by some users, so good luck with trying to add anything to that file...
--David Göthberg (talk) 07:27, 20 September 2008 (UTC)
It's not the 100% wide I think they'll complain about, it's the collapsing inside WPB. As long as WPBS keeps working about the same, I don't particularly care what happens. Anomie⚔ 15:08, 20 September 2008 (UTC)

Some history might be useful here. WPB was created first, as would be expected from a simpler template. The system is, as noted, not very efficient or elegant, probably leading to the creation of WPBS and the pioneering of the |nested=yes system by Kirill. WPBS is, as suggested, preferred by the majority of users, and used on the majority of pages. I think that Anomine might be right in suggesting that the majority of support for WPB comes from a dislike of the banner system in its entirety rather than a genuine preference for it over WPBS. That's why efforts to merge the two templates have been so difficult.

I agree with the concerns above that having the banners always display headers is a poor solution. While the actual implementation using and abusing our existing features is rather ungainly from a technical perspective, the result is, I think, exactly what we want to see. Further, I don't think that always displaying a header actually solves the problem, as I don't think the existing functionality can be replicated without javascript by any means.

I'm very interested by Ms2ger's work, and I think we can develop that into something useful, although I'd prefer to come up with a more general adaptation of the collapsed functionality that can be applied to things other than wikiproject banners if desired. After all, we've pirated the collapsible table functionality for the banners, we should be trying to make any bespoke functionality usable elsewhere without such hijacking. The discussion for that probably needs to take place elsewhere. I think that by adding the functionality to expand nested tmboxes inside mbox-inner cells, we've done all that we can or should to support nested banners at the tmbox level. (also)Happy‑melon 10:32, 22 September 2008 (UTC)

Right, at the tmbox level we are now finished. Its CSS classes now handles the 100% width.
And I agree, any extensions to the collapsible tables should be made in such a way that they can be reused elsewhere, instead of being {{WikiProjectBannerShell}} specific. I suggest you do as we did with the 100% width: You could add CSS class names (just class names, no CSS code anywhere) that modifies the collapsible functionality. Something like "collapsed-inside" and "nocollapse-inside". And then you add the class "collapsed-inside" to the {{WikiProjectBannerShell}} so the javascript who handles the collapsing can know what to do with boxes inside that bannershell. Thus any other box that want to hold boxes inside it can use that class too to get the same functionality. But you need to add one bannershell specific extra thing: The javascript has to make the header cell show when inside a "collapsed-inside" area. But that should not hurt other boxes, since their headers probably already show.
--David Göthberg (talk) 16:09, 23 September 2008 (UTC)

Nested strikes back (section break 3)

My comment that "discussion for [this] probably needs to take place elsewhere" notwithstanding, I've decided to consolidate the discussion here, purely for the reason that most of it is here already :D. I've now added the necessary CSS and JS to the skin files, so their caching time is ticking. Assuming there are no objections, |nested=yes has just 31 days to live... mwahwahwawhaw :D! We can start changing things on 31st October. Happy‑melon 10:47, 29 September 2008 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Tmbox/Archive_2&oldid=1086802510"