Template talk:Tmbox

From Wikipedia, the free encyclopedia

Talk page message box standardisation Here are some useful pages: {{ambox}} – For article message boxes. {{tmbox}} – For talk page message boxes. {{imbox}} – For image page message boxes. {{cmbox}} – For category message boxes. {{ombox}} – For other pages message boxes. {{mbox}} – Has namespace detection, for message boxes that are used on several types of pages and thus need to change style depending on what page they are used on. Wikipedia:Template messages/Talk namespace – Lists some of the message boxes that might use the {{tmbox}} when it is ready. Wikipedia:Talk page templates – The (old) guideline specifying the styles for talk page message boxes. Template:Tmbox/styles – Shows the different suggestions for new styles for talk page message boxes. Has a special talk page to discuss the different designs.

This talk page is automatically archived by MiszaBot II. Any sections older than 21 days are automatically archived.

Archives

Archive 1 Archive 2

[edit] 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. :)
Amalthea^Talk 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, Amalthea^Talk 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?
Amalthea^Talk 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. :) --Amalthea^Talk 23:08, 20 August 2008 (UTC)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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}}
}}

This article is within the scope of the following WikiProjects: Inner box 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>

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:

{{WikiProjectBanners
| 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>
}}
{{WikiProjectBannerShell
| 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>
}}
{{WikiProjectBannerShell
| 1 =
{{WikiProject Discworld|nested=yes|category=}}
{{KnotsProject|nested=yes|category=}}
}}

This article is within the scope of the following WikiProjects:

WikiProject Discworld      (Rated Template-Class) Discworld portal v • d • e This template is within the scope of WikiProject Discworld, a collaborative effort to improve the coverage of Discworld on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. Template This page is not an article and does not require a rating on the quality scale. WikiProject Knots v • d • e This template is within the scope of WikiProject Knots, a collaborative effort to improve the coverage of Knots on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.

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)

[edit] 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:

The same banners but without the bannershell:

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)

[edit] 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)

[edit] Nested strikes back (section break 3)

.wpb.th {display:none}
.wpbs wpb.th {display:inline}

.wpbs .wpb .wpb-header { 
    display: block;        /* For IE 7. */
    display: table-cell;   /* For other browsers. */
}

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)

[edit] Educational example

How would a box like the one at the top of Wikipedia talk:Administrators' noticeboard be converted to using {{tmbox}}? I can only use the "textstyle" parameter for the whole box, so I find it hard to convert that table-like box properly (I also couldn't use {{warning}}, as I couldn't enlarge the image from there). Waltham, The Duke of 16:06, 12 September 2008 (UTC)

Let me give it a try. MBisanz ^talk 16:12, 12 September 2008 (UTC)

Ok, I think I got it. MBisanz ^talk 16:16, 12 September 2008 (UTC)

Nicely done. Thanks; I'll use it as a template when I find similar cases (time I do something for myself, hehe). Waltham, The Duke of 17:24, 12 September 2008 (UTC)

[edit] Tmbox classes

I have now removed the hard-coded styles from {{tmbox}}. (From {{tmbox/core}} really.) Thus it now only uses the CSS classes in MediaWiki:Common.css.

Next planned update is to change to the simpler class names. Then "tmbox-text" becomes "mbox-text" and so on. Due to the 31 days CSS caching that can be done no earlier than 26 September. See Template talk:Mbox#Simpler to use class names for more on that.

(But "tmbox-small" can't be renamed to "mbox-small" since Internet Explorer 5 and 6 don't understand the CSS selector ".tmbox.mbox-small".)

--David Göthberg (talk) 13:58, 15 September 2008 (UTC)

[edit] User warning and block templates

This discussion was moved here from the talk page of David (me). --David Göthberg (talk) 14:54, 25 September 2008 (UTC)

Hello. The tmbox changes you made to {{uw-block1}} look good ... with one exception. Instead of being centered, the template should be left-justified to match the rest of the warnings/messages/block notices in the harmonized uw-scheme. Thanks, Kralizec! (talk) 01:28, 25 September 2008 (UTC)

Thanks. I just fixed some bugs. MBisanz asked me since he had trouble getting it right.

But left-floating? I think not. How talk page message boxes should look was standardised and made into a Wikipedia guideline in spring 2005. See Wikipedia:Talk page templates. We amended that standard with some coloured borders some month ago so the warning templates should be able to follow the guideline too. (It was a long process, see {{tmbox}}, its talk page and the examples at Template:Tmbox/styles and so on.) So I think it is the other way around. That is, it is time the warning templates catch up with the talk page message box standard.

--David Göthberg (talk) 02:05, 25 September 2008 (UTC)

Interesting. I wonder how the centering will look with the numbered layout as specified at WP:UW and WP:UTM. --Kralizec! (talk) 02:48, 25 September 2008 (UTC)

Also, I just noticed [1] that the admin .sig is no longer included inside the block template message box. Is this an oversight or another "feature"? --Kralizec! (talk) 03:36, 25 September 2008 (UTC)

Hmm, that is awkward, I do like the signature in the box. With my own tmbox implementations,I've always been able to move it inside, see User:MBisanz/MESSAGES. MBisanz ^talk 03:41, 25 September 2008 (UTC)

I guess I would use the phrase "looks terrible" but "awkward" works just as well. While I would really like to support the {{tmbox}}, forcing newer (working) templates like the uw-series into the change without first addressing all the issues gives me great pause. It would be a different story if someone had said back in January 2007 "hey, make sure these new uw templates follow Template:Tmbox/styles" but 627 days later? --Kralizec! (talk) 12:22, 25 September 2008 (UTC)

He he, I bet Tmbox didn't even exist in 2007. I did fix the sig part of the Uw-block1 template. MBisanz ^talk 12:26, 25 September 2008 (UTC)

End section moved here from the talk page of David. --David Göthberg (talk) 14:54, 25 September 2008 (UTC)

Kralizec!: First of all, I was asked by MBisanz to come and fix those boxes, since he had made some mistakes that broke them when he tried to apply {{tmbox}} to them. User warning and block boxes are not and never have been any of my interests.

Moving the signature outside the box was just me being bold. I have always found it confusing with the signature inside boxes. Since when someone responds below a box then it looks like it was they who placed the box above the comment. I think signatures should come after the content, not inside the content. Anyway, that was just a suggestion and you guys have already reverted that part.

And right, centring of boxes doesn't work very well with numbered or dotted lists for several reasons. First of all it is weird to have a dot or number before something that is centred. Secondly there is a bug in the MediaWiki parser that means it doesn't allow any line breaks in the content in numbered or dotted lists. That means that any message box that has a line break (not a <br> tag, but an actual newline) anywhere in the code, be it in the div or table layout or in the text or even in data fed as a parameter to the box. Then MediaWiki breaks the box. This is not the fault of tmbox. But here is an example:

* {{tmbox}}

{{{text}}}

The reason your old uw boxes survive this is that they are coded as a single line, with no new lines what-so-ever in their code. Which unfortunately is messy programming, since it makes it hard to read their internal logic and thus causes human programming errors. Usually when people ask me to come fix a template that they can't understand why it is broken, then I do as I have always done as a programmer: First I indent the code to make it readable, then the bugs usually become visible and we can fix them.

Unfortunately there are good reasons why people don't use div layout in other boxes. The main reason is that it causes bad box flow in many browsers. For instance take a look at the {{Uw-voablock}}, it has a shortcut box placed before it. But that breaks in all the browsers I have. That is, right or left-floating boxes that comes before overlaps a div based box. If the box uses a table instead then that doesn't happen. Here is an example with a div based uw box:

{{shortcut|WP:SHORT}}
{{Uw-voablock}}

You have been blocked indefinitely from editing in accordance with Wikipedia's blocking policy because your account is being used only for vandalism. If you believe this block is unjustified you may contest this block by adding the text {{unblock|your reason here}} below.

(The example above has been substituted so it will look the same even in the future.)

Note that the above example will not look too bad in some browsers since the text will flow around the shortcut box in those browsers. But in some browsers the text will go underneath and be hidden by the shortcut box. This is not a fault of the shortcut box, this happens with any right floating box placed before a div based box like your uw boxes.

But with a table based box coded the right way it is no problem:

{{shortcut|WP:SHORT}}
{{tmbox}}

{{{text}}}

Kralizec!: And regarding which year what happened: As I wrote above, the styles for the talk page message boxes was standardised already in spring 2005 and written down as the guideline Wikipedia:Talk page templates. That is long before the "January 2007" date you mention for the uw boxes. Then in the summer 2007 we standardised the looks for message boxes in articles. And as a convenience I coded up the {{ambox}} to make it easy to build such boxes. Note, the article message box styles was not my idea, they had already been settled on before I joined in and packaged it into the {{ambox}} meta-template. After that people helped out and improved the code in the ambox to a level where it flows perfectly in all known browsers! The wiki process is so nice! And now during 2008 we have standardised the looks for the other types of pages. And again for convenience we packaged that as the {{imbox}}, {{cmbox}} and {{ombox}}. (The ombox mostly uses the pre-existing very old de facto "other pages" message box style.) To complete the set we also somewhat amended the styles for talk page message boxes and made the {{tmbox}}. So yes the tmbox is new, but the style guide it is based on is from 2005. These standardisation efforts have been repeatedly announced all over Wikipedia. Even several times as a watchlist notice.

And the reason to standardise message boxes is of course for pages to look less cluttered. To have a unified design for all boxes that goes on the same page. (This is especially important when many boxes are visible close to each other.) This is something that the uw boxes currently breaks.

The reason people did choose to have different styles for different types of pages were that they want to make it clear what page is what type and make it clear what kind of page a box should be used on. (Personally I would have preferred just three types: Article, talk and other. But the majority of users wanted to separate more types.)

--David Göthberg (talk) 14:54, 25 September 2008 (UTC)

All this is beyond me, but I'd like to say this: you have done well to substitute the example. I truly hate it when people discuss templates, images, and the like, and archives make it appear as if the something in question has been replaced by an identical something. Waltham, The Duke of 02:09, 26 September 2008 (UTC)

We really need to stop acting like message boxes are the same as the vast majority of tmbox situations. They are messages, not headers. I know there's some logic in standardizing the blocking messages, but that only makes sense in regards to other blocking messages, not other talk page header templates. --