Template talk:Mbox

Why this template?

The discussion that lead to the creation of this template is at Template talk:Imbox#Other spaces message boxes.

Some message boxes are used on several types of pages and thus need to change style depending on what page they are used on. Coding such namespace detection is rather tricky. This template packages all that in an easy to use meta-template that can be used to build such message boxes.

One example of such a style shifting message box is the {{notice}} box above. When {{tmbox}} is ready for use then {{notice}} should probably use it.

Note that this template should only be used for message boxes that really need to adapt their style. Most message boxes do not need this and should use one of {{ambox}}, {{tmbox}}, {{imbox}}, {{cmbox}} or {{ombox}} directly. Using those templates directly means that your template will look the same on its template page and at any other place you show it, which makes it clear on what kind of pages it is supposed to be used. It also gives you access to any extra features those templates offer, and it saves some server load.

--David Göthberg (talk) 09:50, 30 May 2008 (UTC)

This is an excellent start, but it appears that some Types unique to talk messages need to be provided for (see also Template talk:Tmbox):

• Feature (used for Barnstars, Feature Article, FA candidate and FA failed)
• Good (used for Class A, Class A candidate, Class A failed,, Good Article, Good Article candidate, Good Article failed)
• Project (used for WikiProject banners; WPBannerMeta (beta) to include color blocks for Class and Priority)

Several classes of talk-page message, e.g. Peer Review, Consensus, Conclusion, FAQ, &c., may default to Notice for purposes of this Template. Warnings default to Notice, Content, Delete or Speedy; Blocks to Delete or Speedy, depending on level. Once a consensus is reached on all Types needed, in addition to the Format of this Template, this Template will probably be ready for standard. B. C. Schmerker (talk) 06:13, 26 June 2008 (UTC)

B.C.Schmerker: I think you have misunderstood the purpose of {{mbox}}. A message box that uses a talk space specific box type like say "type=feature" obviously is only meant to be used on talk pages, since that box type has no defined style for other kinds of pages. Thus such a message box should not use mbox, but instead use {{tmbox}} directly. Directly using tmbox has the advantage that the message box will look like a talk page message box on its template page and also on any other page where it is listed or shown, like when listed at Wikipedia:Template messages/Talk namespace.

--David Göthberg (talk) 06:45, 26 June 2008 (UTC)

A minor comment about {{mbox}}

This discussion was moved here from the talk page of David Göthberg:

Hi David,

Just a minor comment I wanted to make about {{mbox}} in followup to the comment you left me:

And you should not change {{ambox}} usage to {{mbox|demospace=main}} even in the future. Since using mbox costs much more server load and it makes your code unnecessarily complex since you add the "demospace" parameter.

What about in the case where a template might be used in both mainspace and talkspace? The particular example I'm thinking of is {{Whole Day Edit}}, which is currently used in both.

Chris Cunningham (not at work) - talk 15:26, 12 July 2008 (UTC)

Right, templates that are meant to be used on several types of pages are exactly the cases that are meant to use {{mbox}} when it is ready. Then you don't need the "demospace=something" parameter so then it doesn't add code complexity. And then we have to accept the extra server load that mbox costs. And {{Whole Day Edit}} seems to be exactly such a case.

However, mbox is not yet officially deployed since we still have no consensus on how it should look on talk pages. (It calls the {{tmbox}} when on talk pages and tmbox is not ready yet.) So templates like {{Whole Day Edit}} in theory should use the old methods for now. But I won't revert to the old methods since they are messy and we are hopefully officially deploying mbox soon anyway. But I would not convert more templates to mbox for the time being.

You are of course welcome to come to {{tmbox}} and its talk page, to help us achieve a consensus so we can deploy...

--David Göthberg (talk) 15:41, 12 July 2008 (UTC)

Thanks. My understanding of the "demospace" parameter was that it was basically just for displaying the template in the defined livery on its own template page instead of always using templatespace - is this incorrect?

Anyway, yeah, sorry about using the template pre-emptively. I've been doing quite a lot of work on templates recently and I'll try to pitch in on development discussion. Chris Cunningham (not at work) - talk 16:00, 12 July 2008 (UTC)

Right, the "demospace" parameter is meant to be supported by the message boxes that use mbox. Like this:

{{mbox
| demospace = {{{demospace|}}}
| text = Bla bla
}}<noinclude>

{{documentation}}
</noinclude>

Then in their green /doc box on their own template page they can show how they will look on different pages. Like this:

The {{tl|something}} template looks like this when on article pages:
{{something|demospace=main}}

And on talk pages it will look like this:
{{something|demospace=talk}}

I am going to explain all that with examples in the documentation for mbox, when it is being deployed. But it is not ready to be deployed yet...

--David Göthberg (talk) 16:11, 12 July 2008 (UTC)

We do not need this in a way

On Wikibooks, we are experimenting with an alternate method for namespace changing message boxes. Instead of using the namespace switching template {{switch}}, to flip between the existing metatemplates, we've modified the CSS classes THEMSELF to do this for us.

For example, here's some CSS classes we're testing out, modified versions of our Ambox and Imbox (our imbox has a thicker bottom border)

<source lang="css"> /* Default "notice" blue */ .messagebox { width:90%; margin:0px auto; padding:0em; border:2px solid #1e90ff; background:#fbfbfb; color:black; } .messagebox img { border: none; padding:0em 0.5em; text-align:center; } .messagebox + .messagebox { border-top-width:0em; }

/* book/main namespace */ .ns0 .messagebox.notice { border:2px solid #1e90ff; border-left-width:10px; } .ns0 .messagebox.warning { border:2px solid #b22222; border-left-width:10px; } .ns0 .messagebox.serious { border:2px solid #b22222; border-left-width:10px; } .ns0 .messagebox.content { border:2px solid #f28500; border-left-width:10px; } .ns0 .messagebox.style { border:2px solid #f4c430; border-left-width:10px; } .ns0 .messagebox.merge { border:2px solid #9932cc; border-left-width:10px; } .ns0 .messagebox.growth { border:2px solid #228b22; border-left-width:10px; } .ns0 .messagebox.idea { border:2px solid yellow; border-left-width:10px; } .ns0 .messagebox.query { border:2px solid #ffb734; border-left-width:10px; } .ns0 .messagebox.move { border:2px solid #9932cc; border-left-width:10px; }

/* image namespace */ .ns6 .messagebox.notice { border:2px solid #1e90ff; border-bottom-width:0.4em; } .ns6 .messagebox.warning { border:2px solid #b22222; border-bottom-width:0.4em; } .ns6 .messagebox.serious { border:2px solid #b22222; border-bottom-width:0.4em; } .ns6 .messagebox.content { border:2px solid #f28500; border-bottom-width:0.4em; } .ns6 .messagebox.query { border:2px solid #ffb734; border-bottom-width:0.4em; } .ns6 .messagebox.free { border:2px solid #79CC55; border-bottom-width:0.4em; } .ns6 .messagebox.nonfree { border:2px solid #EF9132; border-bottom-width:0.4em; } .ns6 .messagebox.pd { border:2px solid #7E80A3; border-bottom-width:0.4em; } .ns6 .messagebox.move { border: 2px solid #9932cc; border-bottom-width:0.4em; } </source>

(yes, we use separate colors for free/nonfree/pd licenses, free have green borders, pd are dark blueish grey like down here, non-free has orange borders)

Theoretically, you could just redirect all the metatemplates over to one central mbox, and let the CSS classes do the work instead of weird template hacks. For demospace stuff (forcing to render it a different way than intended), you'd use something like <div class="ns-0">...</div> ViperSnake151 22:47, 11 August 2008 (UTC)

Yes, we are aware of this method. See for instance my example at Template talk:Main talk other#CSS namespace detection. However CSS based namespace detection has some drawbacks, so I am still studying it to see if we can solve all the drawbacks:

1: Up until two days ago it was messy to detect talk space, since there are nine different talk spaces on Wikipedia. That meant adding nine class names for each talk space colour class in the CSS code, which made the CSS code bulky. We have now solved that by updating the MediaWiki software to add a "ns-talk" class to the HTML body tag for all talk pages. See discussion at Wikipedia:Village pump (technical)#CSS talkpage detection.

2: Detecting "other pages" like for the {{ombox}} is messy since that involves six namespaces. We can solve that by making the "other pages" style the default (first) style in the CSS, and then override that style for the other page types.

3: Most message boxes are only meant to be used on one type of pages. When such boxes are demonstrated or discussed on other pages then they should not change appearance. We can solve this by adding two class names to each colour class in the CSS code. For instance like this:

<source lang="css"> .ns-talk .mbox-notice, .tmbox-notice {

   /* tmbox notice colours */ 

} </source>

And then having special non colour changing boxes for each type. Boxes that use the special class names like "tmbox-notice". That means the exact same code that we already have in for instance the {{tmbox}}. So we still need all the specialised mboxes.

4: Using the <div class="ns-0">...</div> approach to simulate the demospace option doesn't work for a number of reasons. First of all it means surrounding the box with a div when you want to lock its colours, which breaks the box flow, box sizing and box margins. Secondly if you are on say a talk page and want to show the "other pages" style then you can not achieve that, since the other pages classes have to come first and the talk page classes further down in the CSS file. (See point 2 above.) Since the div can not override to something further up in the CSS file, only to something further down. What we can do is if the mbox gets the demospace parameter then it can use internal parserfunctions to change from the style changing 'class="mbox"' code to more specific code like 'class="tmbox"'. However that gives you an mbox with way more complex code than the current mbox.

All this together means that CSS based namespace detection costs more CSS code (more class names, same amount of class content), just as many different boxes, and a much more complicated {{mbox}}. Of course, the demospace option is not that important, so we could simply drop that one, thus making the mbox code manageable. But that still means we need all the mboxes we have now, and an mbox with its own full code instead of just calling the other boxes, and it still means more CSS code than we use now. So at the moment I see no gain, just losses, in using CSS based namespace detection for the mbox. Sorry.

I think this all comes down to that CSS really is a very bad programming language, while Wikipedia template coding is a much more versatile programming language.

And ouch. I checked, you are actually using the code you show above at wikibooks:MediaWiki:Common.css. Your code contains this line: ".messagebox img {}". Shouldn't it be ".messagebox .img {}" (note the dot), or are you actually padding the images instead of the image cells? I don't think that will work well. And you use "width:90%; margin:0px auto;" for the whole box, instead of say "margin: 0px 10%". Your width+margin code makes the boxes flow left instead of centre in older browsers, and their box flow breaks in several modern browsers (boxes will overlap with other kinds of boxes).

Sorry to be so negativistic today. I really would like to see some neater approach than our current. (Not saying that our current approach is bad, but improvements are always welcome.) So I am still investigating and I am open for suggestions and discussions.

--David Göthberg (talk) 00:29, 12 August 2008 (UTC)

ViperSnake151: Thanks for bringing up the CSS classes and namespace detection. It inspired me to come up with what I think is an improvement. See the next section "Simpler to use class names".

--David Göthberg (talk) 10:13, 14 August 2008 (UTC)

CSS based namespace detection solved?

I have figured out how to make "CSS based namespace detection", complete with a working "demospace" parameter and very simple template code. Unfortunately it means fairly complex CSS code.

In the following examples the first two tables are a static ambox and a static imbox. The third table in each example is a "CSS based namespace detection" mbox. (When the namespace detecting boxes don't get a demospace parameter they do detection and adapt to the page type. The demospace parameter is only for demonstrating and testing the boxes.) I won't explain today how I would code this in CSS since that is somewhat messy.

Method 1

Fairly good class names, very good demospace parameter, but slightly weird to use a class name like "image". "demospace=image" gives an imbox. "demospace=portal" gives an ombox, which is right since that is the default mbox for portals.

<source lang="xml">

</source>

Method 2

Confusing "mbox-image" and "mbox-" class names, inflexible demospace parameter. "demospace=image" gives an imbox. "demospace=portal" gives error.

<source lang="xml">

</source>

Method 3

Very good class names, inflexible demospace parameter. "demospace=i" gives an imbox. "demospace=p" gives error.

<source lang="xml">

</source>

Method 4

Uses parserfunctions based namespace detection. Very good class names, very good demospace parameter. "demospace=image" gives an imbox. "demospace=portal" gives an ombox, which is right since that is the default mbox for portals.

<source lang="xml">

</source>

If you want CSS based namespace detection then I am leaning towards method 3. Since I think it is acceptable with a fairly primitive demospace parameter. And that naming is close to the class naming we are already using.

CSS based namespace detection like this gives very simple template code. And only two things to copy to other Wikimedia projects: The CSS code in MediaWiki:Common.css, and the template code for each message box. However the CSS code is pretty messy to understand and thus is likely to cause future mistakes. And it costs extra CSS code, thus it will cost more bandwidth to send the style sheets to the web browsers. (Remember, only some mboxes need namespace detection, while all visiting browsers download the full CSS code.)

Parserfunctions based namespace detection like in example 4 above means simple and efficient CSS code, but slightly more complex table code for the namespace detecting mboxes. And you have to copy three things to other Wikimedia projects: The CSS code, the template code for each message box, and copy and adapt the template code for {{mbox namespace detect}}. Adapting that template to a different Wikimedia project takes some work.

Unfortunately I think the CSS code for CSS based namespace detection is too complex so it will cause too many mistakes when others edit it. And it will cost more bandwidth. While converting and testing the {{mbox namespace detect}} template to other Wikimedia projects is not that hard, and is more or less a one-time operation for each project. The same goes here on the English Wikipedia: I think people will damage the CSS too often if it is too complex, while the {{mbox namespace detect}} hardly ever will have to be updated.

So I think I still prefer to use parserfunctions based namespace detection. Darn.

--David Göthberg (talk) 04:41, 18 August 2008 (UTC)

I think what you've shown here is that you can't have your cake and eat it: you probably have to have at least two out of (complicated-CSS , complicated code , high bandwidth costs , high processor costs ). Since we've been told to not worry about performance, the two we should probably plump for are the "high" ones. I still think there's value to be had from simplifying the 'Xbox-image', 'Xbox-text' and 'Xbox-imageright' classes, but probably this CSS stuff is best restricted to sites without the ParserFunctions extension. Happy‑melon 09:23, 18 August 2008 (UTC)

Happy‑melon: I assume you mean that we should choose method 4 above, right? (Which is the same thing as the method described in section "Simpler to use class names" below.)

--David Göthberg (talk) 05:29, 19 August 2008 (UTC)

Yes indeed - the others smack of the same style as the admittedly ingenious, but ultimately very messy, hacks we used to invoke conditional statements in the days before parser functions. If the tools are available, we should use them. Happy‑melon 20:52, 19 August 2008 (UTC)

Ouch, yeah I am happy I wasn't coding templates for Wikipedia back then.

I think Happy-melon already knows the rest, but for anyone else reading this:

I think I have investigated CSS namespace detection enough for the mboxes now, and shown that parserfunctions are better in this case. So for hand coded message boxes method 4 is the best choice. (But CSS based namespace detection is still nice in some other situations.)

Method 4 differs slightly from how the mbox meta-templates work now. I will update the CSS classes to method 4. (See next section "Simpler to use class names" below.) But I think we still should have the {{mbox}} calling the other mboxes since that keeps mbox simpler and means mbox will have the special fixes that the other boxes have (they differ slightly from each other).

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

Simpler to use class names

File:Yes check.svg Resolved.

I am thinking of changing the naming of the CSS classes for all the different kinds of mboxes. (This will not cause any change in looks, just an internal change in class naming.)

Some message boxes have special needs and can not use the mbox meta-templates such as the {{tmbox}}. Thus people sometimes hand code message boxes. I have noticed that people then often mix up the different CSS classes. For instance if someone has correctly coded a message box for the article space, like this:

<table class="ambox ambox-notice">
<tr><td class="ambox-image"> [[Image:Some image.svg|40px]]
<td class="ambox-text"> Message text.
</table>

Then when someone else copy and paste the code to make say a talk page message box they tend to miss to change all the class names, thus causing this faulty code:

<table class="tmbox tmbox-notice">
<tr><td class="ambox-image"> [[Image:Some image.svg|40px]]
<td class="ambox-text"> Message text.
</table>

So I am thinking of changing the naming of the CSS classes so the message boxes would be coded like this:

<table class="tmbox mbox-notice">
<tr><td class="mbox-image"> [[Image:Some image.svg|40px]]
<td class="mbox-text"> Message text.
</table>

Note how the namespace then is only determined by a single class name. All the other classes would then always be "mbox-something", no matter what namespace the box is for. The CSS code in MediaWiki:Common.css for the tmbox notice style would then look like this: <source lang="css"> .tmbox.mbox-notice {

   border: 1px solid #c0c090;

} </source>

This then also makes it easy to make hand coded namespace detecting message boxes, since then we only need to change one class name based on the namespace. Like this:

<table class="{{namespace detect 
| demospace = {{{demospace|}}}
| main      = ambox
| talk      = tmbox
| image     = imbox
| category  = cmbox
| other     = ombox
}} mbox-notice">
<tr><td class="mbox-image"> [[Image:Some image.svg|40px]]
<td class="mbox-text"> Message text.
</table>

I can make a special template for such mbox namespace detection making it even simpler, like this:

<table class="{{mbox namespace detect|{{{demospace|}}}}} mbox-notice">
<tr><td class="mbox-image"> [[Image:Some image.svg|40px]]
<td class="mbox-text"> Message text.
</table>

Sure, we could do the same with the current classes. But that would mean several transclusions of the rather complex {{mbox namespace detect}} template. Thus causing less readable code and causing more server load. Like this:

<table class="{{mbox namespace detect|{{{demospace|}}}}} 
{{mbox namespace detect|{{{demospace|}}}}}-notice">
<tr><td class="{{mbox namespace detect|{{{demospace|}}}}}-image">
[[Image:Some image.svg|40px]]
<td class="{{mbox namespace detect|{{{demospace|}}}}}-text">
Message text.
</table>

I am going to think about this a bit more, and I would like some comments from others before I do this change of the CSS class names. I can do the transition smoothly so that is not a problem.

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

When I was adding the tmbox CSS I noticed how similar the xbox-image and xbox-text CSS were in absolute terms, not just in usage. I can see how this would be easy to implement, and fully support it. I doubt the current classes are used directly outside the mbox series often enough for this change to cause too much damage, and it has numerous benefits that I can see. Happy‑melon 20:17, 14 August 2008 (UTC)

I can add the new class names (leaving the old ones too) in MediaWiki:Common.css, wait 31 days for the CSS caching to pass, then change the mbox meta-templates to use the new class names.

We can find many of the cases that use hand coded mbox templates by using the Wikipedia search function. I just did a search in template space and only found 7 cases for the ambox classes and 1 case for the tmbox classes, so they will be easy to fix. And I found no hand coded templates for the other mbox types. But in user space there seems to be a little more to fix, especially since some users skin the mboxes in their /monobook.css.

When we have fixed all the hand coded mbox cases and skin cases, then we can remove the old mbox class names from MediaWiki:Common.css. Thus I think we can do the transition perfectly smoothly without any damage at all.

Since the search was a bit tricky, here are the template cases I found, so that I/we can fix them when we get the time. Most of them can simply be changed to use one of the mbox meta-templates, so we can fix them already now: {{Move and semi protected}}, {{Pp-meta}}, {{Schooling late messages}}, {{Tcexpand}}, {{1632GGbook}}, {{24CleanupFlag}}, {{24Plot}}, {{Khmer}}.

I noticed that the search missed some cases that I know exist. So if/when we decide to do this change I will ask the nice people over at Wikipedia:Bot requests to do a full text-search of the database to find any remaining cases. Some of the bot owners do have local copies of the database and can do such full text-searches.

The drawbacks I see with all this is that the new CSS code in MediaWiki:Common.css will be harder to understand, and that might cost some future mistakes. And this change will cost some work. (But as I showed above the classes will be easier to use.) So I still want to think about this a bit more.

--David Göthberg (talk) 01:38, 15 August 2008 (UTC)

In the CSS code, the correct selector would be .tmbox.mbox-notice, not .tmbox .mbox-notice. The latter selects an element with the mbox-notice class inside a tmbox. —Ms2ger (talk) 11:44, 17 August 2008 (UTC)

Ms2ger: Ouch! Thanks for pointing that out. Scary that white space has meaning in CSS coding. As I've said before: CSS is a bad programming language. I gotta read up on those selectors again. Thankfully I test my stuff carefully before I deploy...

I took the liberty of correcting my example above so we won't be confused in the future. So it should be .tmbox.mbox-notice since they are both in the <table> tag, but .tmbox .mbox-text since the "mbox-text" is inside the table in the <td> tag. Tricky.

And this shows the risk with this new approach. The CSS code becomes complex, while the template code becomes simpler.

--David Göthberg (talk) 12:24, 17 August 2008 (UTC)

I have been testing the new "simpler to use class names". The code I suggested above doesn't work in Internet Explorer 5 and 6. IE 5 and 6 can not select on multiple class names in the same element. That is, IE 5 and 6 do not understand this: <source lang="css"> .tmbox.mbox-notice {

   border: 1px solid #c0c090;

} </source>

But they can select on class names for elements inside each other, so they do understand this: <source lang="css"> .tmbox td.mbox-image { /* The left image cell */

   border: none;
   padding: 2px 0px 2px 0.9em;
   text-align: center;

} </source>

So the best we can do is this table code:

<table class="tmbox tmbox-notice">
<tr><td class="mbox-image"> [[Image:Some image.svg|40px]]
<td class="mbox-text"> Message text.
</table>

But that is still pretty neat, since this will work:

<table class="{{namespace detect 
| demospace = {{{demospace|}}}
| main      = ambox ambox
| talk      = tmbox tmbox
| image     = imbox imbox
| category  = cmbox cmbox
| other     = ombox ombox
}}-notice">
<tr><td class="mbox-image"> [[Image:Some image.svg|40px]]
<td class="mbox-text"> Message text.
</table>

As you can see we don't need to change the "mbox-image" and "mbox-text" tags to be able to change the styles. I intend to add the CSS for this in MediaWiki:Common.css in a day or so.

--David Göthberg (talk) 23:05, 23 August 2008 (UTC)

I have now added the new "simpler to use" mbox class names to MediaWiki:Common.css. We can change the mboxes to use them 31 days from now when the CSS cache in the web browsers have timed out. That is we can do the change on 25 September 2008.

--David Göthberg (talk) 17:19, 24 August 2008 (UTC)

The 31 days CSS caching has passed. I have now updated all the mbox meta-templates to use the new simpler class names as described above. What remains now is to search for and fix any remaining hard-coded use of the old class names. And then to remove the old class names from MediaWiki:Common.css. That is to remove any usage of "ambox-text", "ambox-image" and "ambox-imageright" and the same for the other mboxes.

--David Göthberg (talk) 20:23, 27 September 2008 (UTC)

I believe that this is now done - certainly neither I nor MelonBot can find any instances of 'a/c/o/t/i-mbox-text/image/imageright' anywhere (except when talking about the conversion process, like this page!), through either wikisearch or googlesearch. Happy‑melon 20:28, 29 September 2008 (UTC)

Sorry but not all done. Wikisearch shows me a small number of cases for most of the mbox types that still needs to be fixed. And then I also found this case that might interest you. :))

And you edited a number of code examples and discussions on talk pages and in talk page archives. You should not have done that. That was not running code but old discussions and examples. They should not be changed. Especially those cases that now show broken CSS code. I will have to revert them.

But I'll do that tomorrow or so, since I really need to get some sleep.

--David Göthberg (talk) 06:28, 30 September 2008 (UTC)

Where? I can't see any (apart from one ombox-image that was a substituted {{ombox}}). Remember that if the page appears in the search results, but doesn't have any text extract underneath it, it doesn't actually contain the string. I've just wikisearched all 10 classes, and only found that one template, Wikipedia:Catalogue of CSS classes, and this page. My googlesearch last night also flagged your talk page and one of your sandboxes, which I ignored. Everything else got changed.

I made a conscious decision to change everything (bar comments on this conversion process itself) to reduce confusion and the possibility of people learning techniques from old discussions that now do not work. I was not aware that it was possible to produce broken code from the transition - please extrapolate so I can see what I need to correct. If the differences were more blatant, perhaps there would be no disadvantage from having left the old discussions using obsolete code, but since they could, IIRC, be overlooked, it's, IMO, best to have coherence. There is precedent in updating links and shortcuts, etc. In discussions like this, for instance, I'd much rather the code and examples had been kept up to date, as it makes reading it in hindsight incredibly confusing otherwise. Just my £0.02. Happy‑melon 08:12, 30 September 2008 (UTC)

First of all, sorry if my comment above was a bit cranky. I have been a bit cranky lately for a number of reasons. (You are not to blame for any of those reasons.)

Okay, after now looking through your edits I see that I was mostly wrong. The grand majority of your edits were very nice. But I found two that caused broken CSS code in the examples so I reverted them: MediaWiki talk:Common.css/Archive 4 and MediaWiki talk:Common.css/Archive 3. And now that I thought about it I agree it perhaps is best to show the new working code when possible to avoid future confusion.

And regarding the internal Wikipedia search: Yes, I know that when one fixes a page one still gets "hits" for that page for a day or so, but one can see that it is a false hit due to not seeing any red text below it. However I did find some actual cases. I have noticed this before, it seems different people get a different "view" when they search. It's very weird, since each time a person searches he gets the same view. Perhaps we are connected to different search servers based on our IP-number or so? (Load balancing that is.) And I know the searches are not complete since I do not always find all cases I know are there. Anyway, I will take care of the cases I see. I'll report back when I am done. It's just a handful of cases.

--David Göthberg (talk) 22:25, 30 September 2008 (UTC)

I have now fixed the remaining cases that mattered. Most cases were in user space, but I also found this case: Template talk:Helpme (diff).

For the time being I skipped some cases of ambox-text/image code in three users' /monoboook.css that do not have any effect. That gives you something to search for if you want to test the Wikipedia search. The cases are User:Mscuthbert/monobook.css, User:Ilyasishak/monobook.css and User:Balloonguy/monobook.css.

Happy-melon: Since both you and I have searched and fixed the cases we can find I now agree that we can deem this done. I will remove the old mbox classes from MediaWiki:Common.css later tonight or tomorrow.

--David Göthberg (talk) 23:49, 30 September 2008 (UTC)

Y Done - I have now removed the old mbox classes from MediaWiki:Common.css. All seems to work.

--David Göthberg (talk) 17:14, 1 October 2008 (UTC)

Minor issue - bullet point as first line

File:Yes check.svg Resolved.

On my talk page, I use {{notice}}, which was updated about two weeks ago to call {{mbox}}. I'm all for standardization; but it did produce one unintended slight change in how this template handles the first row. If you have bullet points as the first line of text, the bullet does not format correctly. Here's an example:

 {{notice| 
 *First bullet point
 *Second bullet point
 *Third bullet point}}

Which is now equivalent to:

{{mbox|text=
 *First bullet point
 *Second bullet point
 *Third bullet point}}

Displays as:

This did not happen in the original structure of the "notice" template. I can do a work around by coding it to be:

{{mbox|text=  
 *First bullet point
 *Second bullet point
 *Third bullet point}}

But that inserts an extra blank row at the top of the notice, which displays as:

Is there a better solution for this available - or is it simply no longer an option to have a bullet point as the first line in these boxes? --- Barek (talk • contribs) - 16:17, 29 August 2008 (UTC)

Yes, the standard solution when feeding bullet lists and similar as a parameter to any template is to surround it with a div tag. Like this:

{{notice
| <div>
* First bullet point
* Second bullet point
* Third bullet point
</div>
}}

The div tag adds a slight extra top and bottom margin, but that is hardly noticeable. We kind of have documented this div trick for the mboxes that {{mbox}} calls. But we haven't had the time to fully document mbox yet.

I am surprised that not using the div tag worked for the old version of {{notice}}. I remember we investigated this last year for the {{navbox}} and it had something to do with the table cells and spaces and stuff, but that we couldn't fix it for more advanced templates. So the best solution was to use the div tag for the navbox too.

--David Göthberg (talk) 16:57, 29 August 2008 (UTC)

Thanks for the speedy reply ... I should have followed the link to {{tmbox}} and I would have seen the documentation for this. Sorry to cause the extra time to need to explain it here, but it is appreciated. --- Barek (talk • contribs) - 17:04, 29 August 2008 (UTC)

No problem. Our fault for not documentation what we know. Thankfully we have talk pages to ask and answer at! :))

--David Göthberg (talk) 20:17, 27 September 2008 (UTC)

Small non-talk messageboxes?

File:Yes check.svg Resolved.

We've had this for a long time, with .messagebox.small (which screws up the font size). After the introduction of {{Ambox}}, it was implemented again in {{current sport-related}}. Should we make it possible to use small messageboxes easily with the *mbox-classes? We already have tmbox-small, so it shouldn't be too hard to port this to the other namespaces. —Ms2ger (talk) 20:51, 13 September 2008 (UTC)

Hi Ms2ger. I have noticed that you are doing excellent work in converting old message boxes to use the new mboxes. Thanks for that!

In MediaWiki:Common.css there currently is the "ambox-mini" class. I did a search some week ago and as far as I could see that class was not used anywhere. Not even the {{current sport-related}} template uses that class, but instead uses hard coded styles for its small version.

{{tmbox}} as you say have the "small=yes" option that uses the "tmbox-small" class. And that option is used somewhat frequently. (It is or should for instance be used for archive boxes.)

If we are going to add the small functionality to some other namespaces then I have some things to say about that:

1: Personally I don't want the "small=yes" functionality for any other mboxes than the tmbox. It adds a lot of code complexity and increases server load a lot since it involves using two templates for each mbox. If you look at the tmbox it now has the Template:Tmbox and the Template:Tmbox/core.

2: For the ambox I have only ever heard this request before for one single template, that is the {{current sport-related}}. Should we really add this option when there is no demand for it? Or do you have some usage in mind for it Ms2ger? If the demand is that low then I think that special case should stay hard-coded.

3: Just adding the class so it can be easily hard-coded in some templates is a much more low impact solution than adding it to the mboxes' code. Still, I wonder when and where it is needed?

4: If/when used in other mboxes it should use the same parameter name as for {{tmbox}}, that is "small=yes". Since that is a well established parameter name for that function and is much older than the tmbox itself. And we should have the same class naming as for the tmbox. Thus for ambox we should change the class name from "ambox-mini" to "ambox-small" instead.

5: I think that the "ambox-small" perhaps should use the same width as the {{infobox}}, not the same width as the "tmbox-small". At least as far as I remember one reason for the small {{current sport-related}} was so it would stack neatly on top of the infobox. And we probably should ask the infobox people why they set the width the way they do.

6: We are currently in the middle of a renaming of the mbox classes. The "subclasses" such as the "ambox-text" and "tmbox-text" will all instead be called the neutral "mbox-text" instead. Thus the "tmbox-small" will also be renamed to "mbox-small". (And I see now that I have missed to prepare that one in MediaWiki:Common.css.) And thus the "ambox-mini" really should be renamed to "mbox-small". This doesn't mean the class will automatically work for all the different mboxes. We still have to decide for which mboxes we will add such CSS code.

Ms2ger: But since you have been working a lot with the message boxes you probably know about cases and needs that I don't know about, so I am looking forward to your comments about this!

--David Göthberg (talk) 02:39, 14 September 2008 (UTC)

One of the main reasons I brought this up was that I found it strange that this old feature didn't get added to mbox, and I remembered that it had been discussed for amboxes. The other uses I remember off the top of my head are {{Archive box}} and {{Autoarchivingnotice}} (before I made it use mbox). That, indeed, is quite rare, but I think that might be because it isn't that easy to implement it right now. For me, just adding the class is enough, but then it would be useful to add a class parameter to the mbox-metatemplates. The exact width isn't that important to me, making it align with infoboxes makes sense. I suppose that, if we'd add CSS for this, we could limit it to amboxes and omboxes. Thanks for your extensive reply, I appreciate it. —Ms2ger (talk) 13:06, 14 September 2008 (UTC)

Ms2ger: Ah, you are right. The archiving boxes need a small class when on "other pages". So I think I will add the "ombox-small" class to the MediaWiki:Common.css today, since it seems to be a clear case. And adding a new class doesn't change anything old. And it makes the ombox classes kind of backwards compatible with the old message box classes, which they are meant to supersede. (But we have to wait 31 days due to caching of the CSS pages in the web browsers before we can use the new class.)

And a correction, regarding my point 6 above: I did some testing and reading up on this again. And rediscovered why I had not prepared the renaming of "tmbox-small" to "mbox-small". It's because Internet Explorer 5 and 6 don't understand the CSS selector ".tmbox.mbox-small". I had forgotten about that. So the small classes will have to stay named "tmbox-small" and so on. That makes it slightly trickier to make hardcoded boxes that can detect and adapt to different types of pages.

So I checked, the {{ombox}} is "only" used on 12,000 pages. So we perhaps should add the "small=yes" option to that one. Since then it doesn't hurt so much if it is a bit more server costly. But it will add code complexity and make the doc for the ombox much longer...

But I still don't want to add the "small=yes" option to the ambox. Since I have been thinking of this for some hours, now I remember: The "ambox-mini" class was added without consensus and only to satisfy one very vocal editor. And then he didn't even bother to use it in his template {{current sport-related}}, since someone helped him hard-code the small function instead. Actually, I think it is time we remove the "ambox-mini" class since it isn't used anywhere. (I searched for it again, no hits.)

--David Göthberg (talk) 17:44, 14 September 2008 (UTC)

I went ahead and did the changes and additions:

• I removed the ambox-mini class from MediaWiki:Common.css since it has never been used.
• I added the "ombox-small" class to MediaWiki:Common.css. Due to the 31 days CSS caching we can use that class no earlier than 17 October 2008.
• I added the "small=yes" functionality to {{ombox}} by using hard coded small styles. Thus we can use it immediately. And that means it works from {{mbox}} too. See the examples to the right.
• And I bloated the ombox doc with the full explanation of the small parameters. I hope that won't scare people. :))

So, I think this is Y Done.

--David Göthberg (talk) 21:31, 15 September 2008 (UTC)

Now we have a dmbox too

I was asked to solve a problem with the disambig and set index boxes. (There are a whole bunch of them.) And while solving that problem I realised it would be better if they used a single meta-template. And they have pretty much the same needs as the other mboxes. So I made the {{dmbox}} which works like the other mboxes but looks like a disambig or set index box.

--David Göthberg (talk) 15:09, 12 October 2008 (UTC)

ROFL! We really have let the genie out of the bottle now! Not that I have any objection to a move towards increased sensibility in template structure and naming... Happy‑melon 17:31, 13 October 2008 (UTC)

Awesome. Are there many more varieties left? Do hatnotes have a standardised base class? Chris Cunningham (not at work) - talk 19:56, 13 October 2008 (UTC)

Happy-melon: Yeah, I was laughing when I coded up the {{dmbox}}. I first called it {{disambigbox}}, but that caused hideous class names such as "disambigbox-image" and "disambigbox-text", and I kept misspelling those long names. And the template should be used for both "disambiguation" and "set index article" boxes. And it can partly reuse the "mbox-image" and "mbox-text" classes, thus saving some CSS code. So I resorted to using the shorter "dmbox".

Chris Cunningham: First let me misunderstand you on purpose: No worries! We have 19 more characters left in the English alphabet, so we are not running out of short mbox names just yet. :))

And slightly more seriously:

I don't know if there are any other mbox similar templates out there that might gain from being converted to use mbox compatible code and parameters. Well, there are the stub notices... Should we call that one {{smbox}}? :))

I took a look at the "hatnotes". That is, the "see also" and "main article" links that goes on the top of pages and sections. And yes, they do have a CSS class, a whole swarm of templates and a meta-template. But I have always found it strange to use templates and CSS for that when all one have to do is to use this code:

:''See also bla bla.''

That's just five characters of well known wikimarkup to handle all the formatting.

--David Göthberg (talk) 04:48, 14 October 2008 (UTC)

By using semantic classes we can do things like hide the text when the page is printed, mark it as disambiguation for spoken-word preparation and restyle every instance at once should the project suddenly find that there is consensus to make the text a couple of points smaller, for instance. Never know when it can come in handy. Chris Cunningham (not at work) - talk 10:09, 14 October 2008 (UTC)

Chris Cunningham: Oops, I think you just proved me wrong!

Yeah, considering your arguments it seems it might be a good thing that the hatnotes have a base-template and a CSS class. Although I still don't like all the sub-templates they use for it, they are confusing. From now on I will probably use the base-template {{dablink}}, since that means the full text of the message gets visible and editable in the edit window.

--David Göthberg (talk) 15:38, 14 October 2008 (UTC)

There are three sets of templates that I consider to be abominations in the eyes of the Template God: the Citation templates, the 'User' templates, and the hatnote constellation. All these collections are just crying out to be consolidated, cleaned up and generally straightened out. However, I don't really think any of them would benefit from an -mbox template - they are after all not actually boxes!! Ditto for the stub templates. I think we should restrict ourselves here to the genus of wikipedia templates that are actually box-shaped :D Happy‑melon 17:33, 14 October 2008 (UTC)

Happy-melon: Right, those template sets you list are a mess. And right, they are not mbox related. But the stub templates are somewhat mbox related, see my explanation below.

Everyone: This is probably stating the obvious for those who have been taking part in the mbox project for some time, but for everyone else: To me, the mbox templates have some common features, but they of course doesn't have to have all these features:

• Mboxes usually look like boxes.
• Mboxes are meta-templates, used to build many other message boxes.
• Mboxes have a left side image thus needing the "image" parameter. And that parameter takes an image with full wiki notation, thus can take any object or even two images on that side.
• Mboxes have a text cell in the middle, thus needing the "text" parameter. Using the "text" parameter is often better than using an unnamed first parameter, among other things since it forces the user to write "text=..." which solves the problem that unnamed parameters can not handle equal signs "=" in the parameter data. (Unless they feed it like "1 = bla=bla". But people don't know that, even if we document it properly, so they waste lots of time trying to figure out why their templates break.)
• Mboxes usually have several types, thus needing the "type" parameter. (Actually, the type parameter mostly helps us to keep the number of mbox meta-templates low. We could have used one meta-template for each type...)
• And when needed the mboxes have some other standardised parameters like "imageright", "style", "textstyle", and some other.
• When we build an mbox meta-template we apply the box flow tricks and other things we learnt when we made the ambox. Thus we package very well tested and working code.

A good thing with standardising on the mbox syntax is that lots of template coders now are used to the ambox parameter names and know how they work. And the more meta-templates that are standardised to this syntax the more people will get used to it.

So, let's take a look at the stub templates:

1: They are many and thus could have good use for a centralised meta-template.

2: They usually have a left side image and a text cell. So the meta-template could have good use for the standardised mbox "image" and "text" parameters.

3: They are messages put in articles, but they don't look like boxes.

4: They don't have different types as far as I know. They all look the same.

So I think they could need a somewhat mbox compatible meta-template, but it is not necessary to call that an "mbox". So perhaps some day when one of us is bored we can code up a {{stub-meta}}, or whatever the preferred name for it will be. And it should perhaps have the "stub", "stub-image" and "stub-text" CSS classes or so.

--David Göthberg (talk) 08:40, 15 October 2008 (UTC)

Now we have a dmbox too (section break 1)

I moved the comment below from Template talk:Fmbox#Sister project link templates to this discussion, since it really is a part of this discussion and not the "sister project box" discussion. --David Göthberg (talk) 10:36, 3 November 2008 (UTC)

I just came across a *box meta-template for stubs that already exists: {{asbox}}, or Article Stub Box. --Blooper (Talk) 05:24, 1 November 2008 (UTC)

After further research, it seems that a stub meta-template isn't particularly liked among the editors of the stub sorting Wikiproject, seen by these discussions. I'm not still really sure why they think that subst-ing a template is better than a meta-template, though, when a meta-template has so many advantages. --Blooper (Talk) 06:14, 1 November 2008 (UTC)

End of comment moved here from Template talk:Fmbox#Sister project link templates. --David Göthberg (talk) 10:36, 3 November 2008 (UTC)

Blooper: I hope you don't mind that I moved your comment here?

Thanks for finding the {{asbox}}, I was not aware of that one.

I took a quick look at that template and the discussion you linked to. It seems that he who made that meta-template made the mistake of mixing several things into the same meta-template. He mixed style, text and categorisation.

1: He added category handling to the meta-template. I have sometimes considered adding category handling to meta-templates, but so far I have always come to the same conclusion: It makes the meta-template too complex and instead of helping the editors it makes it harder to build templates with it. And that seems to be what happened with {{asbox}}, people disliked its category handling. I didn't see any complaints about the style. (But I just took a very quick look.)

2: He let the meta-template handle the text. He has several parameters just to insert the words for the one to two sentences of stub message. That is just unnecessary complication.

I would instead make a meta-template that normally only needs two parameters: The image, and the full text to display. As simple as this:

{{stub-meta
| image = [[Image:Some image.svg|30px]]
| text = The message body text.
}}

The stub-meta meta-template would take care of the width, margins, padding, and make the text italic. And it would add the proper CSS ids and classes for a stub message. It would not mess with the text (apart from making it italic), and it would not handle the categories at all. Since the formulation of the text and the category handling is unique to each stub template that is built from the meta-template. Thus that handling should be done in the templates, not in the meta-template.

--David Göthberg (talk) 10:36, 3 November 2008 (UTC)

Given the current holy war over the styling of the uw- templates, you'd be surprised how many people feel that consistency is the Great Satan. :) I'd support this of course. Chris Cunningham (not at work) - talk 11:47, 3 November 2008 (UTC)

Sounds like a good plan. The only thing I would suggest is putting the last sentence (You can help by expanding it.) in the meta-template, as that probably wont change from stub to stub. --Blooper (Talk) 17:50, 3 November 2008 (UTC)

Blooper: Oh no, the meta-template should not automatically add any text, no matter how standardised that text is. Since then it would get tangled into the text content discussions. It is easier and clearer if the entire text content is visible as one item in the templates that call the meta-template.

Chris Cunningham: Well, thankfully there doesn't seem to be any warring about the looks for stub templates. They seem to have a simple and unified look. Actually, as I have stated before, it seems the stub templates are in a pretty good shape. Thus there is no hurry to make a meta-template for them.

The same was true with the disambig and set index templates: Thanks to their good shape and unified look I think most people didn't even notice that I changed them to use the {{dmbox}} meta-template. Since there were hardly any change in looks at all. It was mostly a convenient packaging of the proper code, especially to handle the behind the scenes code for the difference between disambig and set index boxes.

And for that reason I haven't even bothered to convert all the disambig templates to use dmbox yet. It's no hurry to convert the remaining ones. It was just the set index templates that needed to be converted in a hurry, and that I have done.

Of course, there are some discussions about the text content for the disambig templates. But dmbox does not interfere with the text content, thus it doesn't get affected by the text content discussions.

--David Göthberg (talk) 18:09, 3 November 2008 (UTC)

I disagree, DG, often it can be useful and productive to include text in metatemplates. It depends entirely at what level you are pitching the metatemplate: for the mbox series, it would have been crazy to even consider adding default text. For a meta-template like {{db-meta}}, however, incorporating customised sections around standard text has significant benefits. The stub-meta template would be closer in position to db-meta than to, say, {{ambox}} and therefore some default text, where it genuinely is unified across the template collection, is a sensible idea given that it ensures standardisation of the edit-this-page link, and general style. My philosophy in meta-templates is that anything that would otherwise have to be hardcoded into every one of the instance templates should instead be coded at the meta level. Simplicity is still key, and so only one 'text' parameter should be utilised, but there is no reason, in my opinion, to duplicate a sentence (and some moderately complicated link code) a thousand times when it could be trivially coded into the meta template purely for the sake of "cleanliness". Happy‑melon 20:39, 3 November 2008 (UTC)

Happy-melon: And I disagree with your disagreement. Consider what happens if/when some WikiProject wants the "You can help" link for "their" stub template to link to a page explaining how to expand their kind of articles. Then it becomes a big problem if the meta-template adds a standard text.

--David Göthberg (talk) 22:14, 3 November 2008 (UTC)

That is only an issue if we decide to condone such a deviation; obviously if that's the case then the 'ubiquitous' text is not, in fact, ubiquitous, and indeed shouldn't be meta-content. However, if, as is highly likely, no deviations from the standard form are permitted, it remains ludicrous not to meta-code it. You are considering a somewhat different issue to me, I think; my immediate reaction to a WikiProject saying that they wanted their stub template to say something different to the heaven-knows-how-many other templates is to say "what's your very very very good reason for it? Oh, you don't have one that can outweigh the advantages of not having to edit a thousand templates? Then tough." :D Happy‑melon 23:59, 3 November 2008 (UTC)

Why should a link to a message about how to edit a page to a WikiProject's standards go on an article, especially an article that doesn't have much content and needs anything it can get? If that is necessary (which it really shouldn't be), it belongs on the talk page. Also, I doubt the stub sorting wikiproject would like that. --Blooper (Talk) 01:06, 4 November 2008 (UTC)

Happy-melon and Blooper: Well, that is exactly the kind of reasoning that causes unusable meta-templates, and forces people to code up their own special solutions. Which often ends up with the styles also differing.

It is fairly common that some templates need to have different text than the majority of templates of the same type. Some disambig boxes have slightly different text than the generic one just for grammatical reasons! Since the standard part of the text would otherwise not work with the unique part of the text.

And that a WikiProject has a separate page that explains well how to expand their type of articles would probably be a good thing. If we force them to not link that page would then be a loss. Anyway, that was just an example that I came up with. What I mean is that we can not know in advance what text needs the templates will have in the future.

If the text is not part of the meta-template then we will not have to resort to weird solutions, when some of the templates that use the meta-template have special text needs. And the standard text can of course be a part of the examples in the meta-template documentation, so it is easy to just cut and paste that part of the text when creating a template.

--David Göthberg (talk) 01:40, 4 November 2008 (UTC)

If you insist on it so badly, why not code it with an optional parameter to replace the "you can help by expanding it" sentence? --Blooper (Talk) 02:48, 4 November 2008 (UTC)

Or, it's the kind of reasoning that results in a cohesive set of templates that obey sensible standards. You're used to working with metatemplates that have an awe-inspiring range, used in every namespace for a myriad of different tasks. This isn't one of those templates; its instances are intended to do just one thing. There just isn't the same need for complete flexibility and adaptability here as there is with the mbox series. There isn't even a need to incorporate a 'style' parameter IMO, although we might as well add one since it's so trivial to do so. Really the only things that vary among stub templates, and the only things that should vary among stub templates, are the image and the first sentence. Anyone who wants to alter anything else needs to have a damn good reason why. Happy‑melon 08:54, 4 November 2008 (UTC)

I'm deeply skeptical of the alleged merits of having a metatemplate that'd be transcluded into about half the article space. (And yes, I'm also pretty skeptical about WP:PERF and the level of helpfulness of our dev cadre in such matters, before I'm pointed at either of those.) That there's a similar template already in significant use seems to be the results of its creator going on a kite-flying exercise by "piloting" it on several hundred unsuspecting exercise, as part of a "consultation exercise" that had a response someplace between "tepid" and "opposed", rather than being a sign of any popular uptake, as far as I'm aware. Given that those seem to be getting tweaked on a semi-regular basis, I'm really not sold on the benefits of them vs. leaving well-enough alone.

On the other hand, I do think that the format of stub templates should be as standardised as possible. There's a long-standing set of guidelines on what format they should be in, and there seems to have stabilised a consensus that there should not be WPJ links and such like, in light of these being transcluded into the articlespace. (Following a rash of such additions a while ago, that seemed to progressively get removed subsequently.) Having pointers from otherwise-innocent articles into exotic regions of the project space could have undesirable (and presumably unintended) connotations of article ownership, or just be entirely confusing to the passing reader and casual editor.

There are, however, a couple of special cases, such as stub categories with multiple upmerged templates, where a template sort key is handy, and templates that are upmerged to multiple stub categories. (Which might be arguments against the approach that asbox takes, as an editor above appears to argue.) Alai (talk) 04:51, 6 November 2008 (UTC)

Alai, just before posting this message I made null edits to Template:!, Template:Portal and Template:Stub-Class, which are the three most-used templates on en.wiki, having between them over five million transclusions. As you can see, we're still here; a set of edits that would have crashed the site a year ago is now inconsequential thanks to improvements to the MediaWiki software. We are in a position where we genuinely can not worry about performance; the rendering and caching backend of MediaWiki is so efficient and load-balanced compared to the rest of the software that it is only unrestrained editing that causes problems. If you believe that "the format of stub templates should be as standardised as possible" then I'm not sure how you can rationalise that with a disinterest in a meta-template. One leads inevitably to the other, IMO. If there are a clear set of guidelines, then it's a simple as rewriting them in template form and linking to it! I agree with your comments about cross-namespace links, and am pleased that there seems to be opposition to this; as I've said above, it will make our lives easier. I agree with you and DG that the major failing of {{asbox}} was trying to do category links; these should be handled separately. Happy‑melon 12:41, 6 November 2008 (UTC)

Any progress on anyone taking a look at a stub-meta? It's a great idea to get them all standardised. —Borgarde^talk 05:16, 20 November 2008 (UTC)

Recycling WP templates

This discussion was moved here from my talk page. --David Göthberg (talk) 22:50, 13 November 2008 (UTC)

Hi, David I note from the template talk pages, that your a template expert. I wonder if you could assist me or point me to the relevant info as I'm attempting to recycle (copy) Wikipedia templates to a Wikia project I started. The Msg box, Ambox and {{ombox}} templates display the Icon and characters outside the box border My version Here. I got a working Navbox look alike but it has faults (i.e. edit buttons centre and don't function correctly and if 2 added to apage they have a space of about 5 lines between them) Example here on my Caterpillar inc. page. Another problem i have is that after {{template}} in text the text jumps to a new line indented like this Example. Is some code missing from other files Like CSS & JS (I Dont fully understand how these work) but have seen these mentioned and an editor on the Wikia site did help a bit to fix Navbox for me?

I want to create a simpler version of Infobox companies, as thats non functioning (it displays loads of makup characters) and is over complex for my needs. Can you point me to a helpful guide to writing Wiki template code and understanding how to follow parameters used. (is there an online editor to help write them ?)

Thanks in anticipation BulldozerD11 (talk) 17:07, 13 November 2008 (UTC)

End, discussion moved here from my talk page. --David Göthberg (talk) 22:50, 13 November 2008 (UTC)

Hi BulldozerD11. I took a look at your Wikia code:

1: First of all you have gotten much farther than most, since you have correctly hard-coded the CSS styles into the templates. Good work.

2: You should be careful with newlines and whitespace. They have meaning in template programming and wikitext. For instance in your comment above you had a spurious newline followed by a space before the next word, that caused a dotted box around parts of your text. (I fixed that.) You have similar problems in several of your templates over at Wikia. And you also moved some stuff outside the noinclude tags in some of your templates, causing even more whitespace problems. I fixed it for your {{tl}} template. But it needs fixing in your {{t1}} template too, and likely in some other places too, since that is a mistake you seem to repeat.

3: Your Ombox problem with the visible <td> tag was tricky. There are a whole bunch of different HTML parsers available for MediaWiki. Unfortunately none of them comes enabled in the default MediaWiki installation. So the sysadmins have to pick one. Wikia seems to use another HTML parser than Wikipedia. And that one is bad, since it doesn't understand HTML inside #ifeq and #if cases. So I had to move the if-cases inside the td tag to fix it. That also means you can not put templates inside templates on Wikia. At least not if they use HTML tables. It might work if you use wikitables instead, but then you get all the nasty problems to escape all many pipes in the code. Then you have to use the {{!}} template all over the place... And in wikitables whitespace and newlines have meaning, so you will have an even harder time than most of us to use wikitables for complex templates. Since handling whitespace is not your strong side, yet.

4: I did not look into your navbox and other templates, but I expect some or most of their problems is of the same types as I just described above.

I recommend that you contact the Wikia system administrators and ask them to change to the better HTML parser that Wikipedia uses. I don't know the name of that one but they probably know how to check that. If they fix that it will save you and lots of other Wikia users a lot of problems.

And regarding guides to writing template code: Unfortunately we don't have any good such ones. The ones that exist are messy and often partly outdated. Several of us experienced template programmers have it on our to-do lists to write a good handbook for template programmers. Or rather, to update and rework the existing help pages. But we seem to never get the time to do that.

To learn about template programming you can start to read most of the help pages that are linked to from Help:Contents/Editing Wikipedia. And study the template code of others. And study the history of existing templates to see what changes people made and look at their edit comments that sometimes explain why they did those changes. And of course, you need to experiment a lot. The problem is if you work alone on another wiki it will be very hard to find out all the quirks in MediaWiki template programming. If you code templates here at Wikipedia and something doesn't work then usually someone else comes along and help you with it, and thus you learn.

And note, most of us don't have the time to help people on other wikis, since we are already working full time with template programming here at the English Wikipedia. All we can do is to try and code good templates here and document them well so it will be easier for people to reuse them elsewhere. And that is also why I moved this discussion to this talk page, so others can learn from it.

--David Göthberg (talk) 22:50, 13 November 2008 (UTC)

Thanks for taking the time to look David. I've spent quite abit of time looking at the template code on wikipedia and trying to get what does what and why. Hence sussing out after copying loads of PP related bits that the solutions to remove / disable the code on copying across.

1. The CSS was just copied (the bit I did) some was modified IIRC by one of the other Wikia editors or was it the JS code ? (I had a period when i was trying to fix code then i left it for a bit, but now its annoying me as i try to tidy up the pages and build up the content to not be a wikipedia content clone with new material and Images) And feel that I need to fix the templates before having too many pages to add them to.

2. The space was deliberate in the message to replicate the effect I'm seeing after {{Template example}} in a line of text, as it breaks the line. Most of the Templates I've copied and pasted straight in, only removing inter wiki code, or changing W: to Wikipedia: to save copying all the pages called across in the docs. But I may have introduced space then when trying to spot the diff in a couple of ones were i've found another wikia with something similar. This white space issues obviously a tricky problem. I made amess of the side menu early on trying to put comments in with <!-- Comment --> bits to break the section up. So how do you spot the Blank spaces ?

3. Will look have a look in detail at your solution in Ombox, Thanks.

4. I'll try your advice of getting an upgrade to the Parser function then. I become aware that not all media wiki based wiki's are the same. Some of the other bits your on about I'm not total sure i understand them (escape all the pipes) ?, hence the Guide question, as seen some mention of these things is in the documentation and talk discussions i've looked at but didnt quite make sense. Hence asking in the end.

4. I can look and try some of the fixes you suggest.

5. Appreciate you are busy on Wikipedia and writing code for other projects is obviously not productive to progress on wikipedia. I know how deviating off soon takes up all evening. A quick check on my watch list soon turns into a couple of hours once you start fixing things.

6. I need to find time to follow the WikiProject MetaTemplate discussion / upgrades as I modified the one for WikiProject Lincolnshire as it was using priority instead of importance for the output catorgries, but the input parameter was Importance in the banner. Plus a stack of Ideas project in sandboxes.

7. As you say experimenting helps and I'll have another look t the help pages, as it may make more sense now. I thought I'd as after coming across one of your talk page discussions and seeing that you were the originator or major editor/coder of some of the templates involved. As it could have just been some very simple thing id missed (he said in hope) but no such luck then.

New Q Can you point me to the template bits that generate the edit buttons and show hide bit on the collapsible navbox, to create a page like the transcluded /doc pages but in my article pages to carry some big wikitables as using a link above them on the page to get to the template page to edit them. Thanks again I'll look at the Ombox code tomorrow.

Cheers - BulldozerD11 (talk) 03:45, 14 November 2008 (UTC)

2: Learning to spot the newline, blank space and noinclude/includeonly errors took me about a year of template coding practice. And I was already used to whitespace issues from other programming languages. There's no shortcut to learning that, sorry...

3: You almost only need to escape the pipes "|" when you use wikitable markup, not when using HTML table markup. I am not sure if we have any decent help page about how and when to escape the pipes, it involves using the {{!}} template a lot, and is tricky even for us experienced programmers. (I know that there at least is some example on one of the template help pages, but I don't remember where. Unfortunately the {{!}} template has no decent explanation in its documentation.) The pipe problem is one of many reasons why I stick to using HTML tables. Of course, since Wikia uses such a buggy HTML parser then you might have to use wikitables.

8: The v-d-e links in the top left or right corner of some boxes are usually built with the {{tnavbar}}, or one of its sister templates.

9: The [show/hide] buttons are usually built using the collapsible tables system, although there are another systems for that too. Note that this involves a lot of javascript and here at the English Wikipedia that javascript has just been rewritten to add even more functionality. Since the code is now brand new, it might have new unknown bugs. And even before the change this show/hide system caused so much problems that I usually advice against using it.

--David Göthberg (talk) 07:24, 14 November 2008 (UTC)

Had a look at {tl} now, looks like I'll have to work through all the imported templates then systematically to find the ones with the PP code which i comment out and moved out side the code in some cases.

See Tmbox has moved to Tmbox + Tmbox/core so swapped (trying to spot the nested if loops looks like its another practice thing.) Was never brilliant at 'Basic' coding so will keep out of javascript, But looks like will have to learn HTML & Wiki code which appear to be like English (a mix of allsorts of other bits and each other.

8.&9. Thanks I study them when I fixed some of the other issues. The current navbox I have collapses OK (but is just simple version. The main issue is the 3 blank lines between them if 1 put multiple ones on a page. The issue must be in the header as there appears to be blank space above as they are all used after the External Links section.

Thanks, I'll go and read up a bit and Trawl through the list of imported templates (several 100>1000+) as {{Convert}} has upwards of 2500 sub bits, most of which are called for by the Doc page examples(so I stopped importing them). Cutting the doc pages and linking to the WP version may be a better solution (Bodge)for now. Recycling is not as straight forward and time saving as it looks at first !!.

- Thanks for assistance BulldozerD11 (talk) 13:11, 14 November 2008 (UTC)

Indent out Hi David, some more Comments on Wikia -v -Wikipedia and shared code use.

2. Still appeared faulty on some pages braking text after the {{example}} onto new line at first ?. But {{tl}} Appears to work now (Wikia have a version called {{T}}, since discovered). Some WP & WikiMedia stuffs on Wikia central but a lots older code & poor ducumentation.

3. Can not get other versions of 'Ombox' group to work, can see you moved the <td> tag out but also added a new "if" bit and moved ">". Some boxes are showing <Div> tags which moving them abit slightly cured then ended up with abox inside another one ???? (Obviously broke a nested bit of code).

8. The v-d-e buttons from Navbar also act up in PP-meta box that appears in some of the documentation pages. Also got some rouge </span> tags on the Page here. ?

10. Template {{Convert}} has been partially fixed by moving the notes I added outside the <noinclude></noinclude> tags. Its associated pages have a mix of {{documentation}} and older versions, Just a note on the page or some on talk page.

Eventually fixed a problem with the top line of the Transcluded doc page dropping "]] (edit) (talk)" onto a new line. It was down to the <!-- pp disabled comments --> which I'd added outside the <noinclude></noinclude> Tags. The pp messages are a devil to track down (transcluded through multiple pages) Tip: remove from pages at start, going backs tricky. (David a lot of the pages had spaces inside the Noinclude Tags any way ? Some pages have the code inside 'includeonly' and others dont have any at all ?

Note: Do not recommend anyone attempts to export {{Convert}} to other projects at all. (Definitely dont use the List of functions in the documentation pages, just disable it as it call so many functions and example pages). Hope some of these notes make sense and help anybody thinking of using WP code on a Wikia, not make the same mistakes and waste days sorting it out. -- BulldozerD11 (talk) 02:50, 19 November 2008 (UTC)

Left-aligned small box

Porting the heavyweight technical stuff from Template talk:Expand-section#Correct code to implement desired change

It seems that we need to implement some form of left-aligned small messagebox, certainly for amboxes. To avoid the Bad Thing of specific templates hardcoding the styles, we clearly need to work this into the meta-templates. And since this needs to be applied to, at least, ambox and ombox (and I don't see why not tmbox as well) we're also probably looking at CSS classes. Of course, step 1 is to restructure ambox in the same fashion as tmbox and ombox to allow the use of a small parameter at all.

Loathe though I am to admit it, I think that the best way forward is to rename the small class again, to .mbox-small-right, and add a new .mbox-small-left class with similar, but mirrored, declarations, using the same .mediawiki .mbox-small-left trick in Common.css to get the correct specificity. We still need to work out the actual styles for this class: I assume, for instance, that unlike the right-floating box we don't want content to wrap around the left-floating box (IIRC this wreaks havoc with unordered lists, among other things).

Then we can redefine the syntax of the |small= parameter to be:

• "left" → left-aligned small box
• "right"/"yes" → right-aligned small box
• default → normal 80% width box

With the "yes" being initially retained for backwards-compatibility. If we want to deprecate the use of |small=yes we can add a tracking category to pick up instances of that that make it through to the metatemplate and use the new supercharged job queue to find the offending templates and change their code from

{{ambox
|type=notice
|small={{{small|}}}
...

to

{{ambox
|type=notice
|small={{#ifeq:{{{small}}}|yes|right}}
...

or "left" as desired. I personally think that we should retain the metatemplate handling of |small=yes for ease, but templates should be encouraged to specify which side they want to 'go small' onto rather than just passing the parameter through, or we'll get petty little disputes between editors who want it on different sides (and the inconsistency of seeing the same template on opposite sides of the screen). If we code it carefully we should be able to use the same structure and syntax on all the mbox templates, without having to necessarily enable the |small=left functionality on all of them - I can't see any immediate need for this on tmbox, for instance, although there might be such in the future. However, for consistency it still needs to accept |small=right.

So in summary, the roadmap as I see it:

1. Changes in MediaWiki:Common.css: .mbox-small-right as an alias for the existing .mbox-small
2. Decide basic styles for left-floating mbox
3. New class in Common.css: .mbox-small-left
4. New implementation of |small= contraction, accepting |small=left, |small=right and |small=yes with selective availability
5. Apply new code to {{ambox}} and {{ombox}}, probably with hardcoded transitionary period
6. Announce deployment
7. Decide and resolve use of |small=yes
8. Deprecate and remove .mbox-small
9. Break out the champagne on another smooth transition (assuming everything actually works)

Does this make sense? Happy‑melon 12:23, 4 March 2009 (UTC)

Thanks for moving the technical discussion to this page where it belongs. Well, either here or the talk page of {{ambox}}. But since it in the long run affects all the mboxes this page is the best. And we should probably discuss most mbox related things on this talk page anyway, to keep all discussions in one place.

Yes, your technical suggestions make sense. But I don't think we need to take it as far as you say.

1: I agree that the new class should be called ".mbox-small-left".

2: I agree that the new parameter should be named "small=left".

3: I agree that the left aligned boxes should not be floating, but just aligned. Thus text following them should not wrap around them, but start after them.

4: But I think that we so far only need the "small=left" for the {{ambox}}. While the other boxes only need the right floating small. I don't see why ombox needs it? Or are you thinking of multi-namespace message boxes that need to be tiny (that is left aligned)?

5: Also, I think we should not add a right floating ability to the {{ambox}}. That is, I prefer left aligned boxes in articles over right floating boxes. And we have only had requests for right floating boxes on 1-2 article message boxes so far.

6: Thus I think we don't need to change the parameter for right floating to "small=right". For now we can keep calling that "small=yes". Thus making it simple for the {{ombox}} and {{tmbox}}.

7: This also means that I think we don't really need to rename the old right floating class. We can still call it ".mbox-small". At least for now.

8: Actually, if we decide to only have left aligned small boxes in articles, and only right floating boxes in all the other namespaces, then we could simply always call the parameter "small=yes". But that might become messy in the future. We could even make it so the same class name automatically chooses the right side depending on if it is inside an {{ambox}} or one of the other mboxes. But it is slightly simpler to have two different classes, and it will save us some trouble in the future if we decide to allow both sides in some kind of box.

--David Göthberg (talk) 14:58, 4 March 2009 (UTC)

Thanks for the quick response. When I said that we should be applying it to ombox as well, I was mainly thinking of my work on {{listen}}, which uses the {{side box}} meta-template, which in turn uses (so I thought) ombox classes or even ombox itself. Actually my memory failed me: I wrote that meta-template instead to use purely the mbox-small class; note the nasty hack to implement left-alignment. This is another situation where an mbox-small-left class will be invaluable, but in fact it does not require modifying ombox. This issue is in fact currently restricted to ambox. Incidentally, Template talk:Ambox, which was my first choice location for this thread, is actually a redirect, which threw me a bit, I admit.

With this in mind it becomes less necessary to make the more drastic changes I proposed earlier, but I still think they would be beneficial in the long run. Certainly overloading |small=yes by mbox type would be a Bad Thing; it would be nasty in templates using {{mbox}}, quite apart from anything else. But then again we do have to consider how such templates will handle the 'left-small' functionality in any case.

Perhaps your suggestion is less disruptive: create the mbox-small-left class and deploy it on ambox only; triggered on |small=left. Then see how things play out from there, and whether there is any call to deploy the functionality more widely. As long as we don't do anything stupid to impede our ability to provide that wider deployment if it's requested (and I think overloading either |small=yes or the mbox-small class itself would both fall into that category) then we shouldn't have any issues, and we can cross any bridges involved as and when we get to them.

Thoughts? Happy‑melon 22:33, 4 March 2009 (UTC)

Right, I think we understand each other fully. But just to be extra clear:

My point 8 above was just some reasoning to show why we should not use "small=yes" to mean different things in different mboxes. And why we should not use the same class name to mean different things in the different mboxes. Even though it at first might seem neat. (But it would cause problems in the future.)

And I should perhaps explain my two reasons to not change "small=yes" to "small=right": It seems we don't need to do that change, at least not for the time being. And as you point out we can just as well do it later. So we can simply be lazy and not do it now. And my second reason is that if we make it "small=right" and also rename the class to ".mbox-small-right", then people will think that "small=left" and "small=right" is equally okay to use in all namespaces. And then we will see lots of cases where people will build for instance left aligned boxes in tmbox style. Or at least they will start asking for us to hard code such boxes using the classes. And then we might end up with an ugly mix of left, centre and right aligned boxes at the same time on some pages...

--David Göthberg (talk) 03:06, 5 March 2009 (UTC)

There's certainly merit in your points there. So step 1 is definitely to create a stable mbox-small-left class. What are we looking at? Happy‑melon 22:10, 5 March 2009 (UTC)

1: I'm in a hurry so I haven't properly tested this (my dance partner is waiting :). But based on the style discussions over at Template talk:Expand-section#Correct code to implement desired change, this is how I think the class should look:

<source lang="css"> .mediawiki table.mbox-small-left { /* For the "small=left" option. */

   margin: 4px 1em 4px 0;
   width: 238px;
   border-collapse: collapse;
   font-size: 88%;
   line-height: 1.25em;

} </source>

That is, no "float" or "clear", so it is left aligned instead of left floating. The margin code "mirrored" so margin-right is 1em. And the same box width and text size as for the right floating mboxes.

2: The class above works as is with all the mboxes except the ambox. For the ambox we need to adjust the image and text cell margins for small amboxes, since ambox has special margin CSS since it has the 52px DIV image cell hack. That is, the small amboxes should not have that hack (since it looks bad when small, I have tested), instead they should have the same image and text cell margins as the other mboxes. That takes a little more coding to fix, I'll probably have time on Monday or so to code up and test the CSS for that. (But you probably know how to code that too.) When that is done we have all the classes for simple "hand coded" boxes.

3: And then we must make it so the {{ambox}} template does not use the 52px DIV in the image cells when it shows as a small box.

--David Göthberg (talk) 14:57, 6 March 2009 (UTC)

I have now created the hand coded small left-aligned {{expand-section/sandbox}} and done some testing over at {{expand-section/testcases}} and it showed me some things:

1: The small amboxes should have "border-collapse: collapse;", just like the other mboxes have both when they are large and small. Otherwise the small amboxes get too much padding. (I tried fixing the padding without collapse but it was messy.) So I added collapse to the code above.

2: The tighter image padding (compared to the other mboxes) that the small amboxes get if using the default ambox image CSS (and not the 52px DIV hack) is pretty nice. So I think we don't need to "fix" that. This keeps the CSS code in MediaWiki:Common.css simple.

--David Göthberg (talk) 00:30, 10 March 2009 (UTC)

That's so cute! I love it!

I've coded up an {{ambox/core}} and rewritten {{ambox/sandbox}} to do what it should to implement this; extra testcases at the bottom of {{ambox/testcases}} look good to me on FF3 and IE7. How do things look from your end? Happy‑melon 14:52, 10 March 2009 (UTC)

Yeah, I love it too! Finally a non-intrusive message box design that doesn't totally ruin the articles it is put in. I'm very happy people suggested it and received a consensus for it.

Hehe, you beat me to it. I was going to do the "/core breakout" today. :)

I see you haven't yet done all the image handling fixes to the code in /core, but I guess you just haven't had the time yet. Tell me when you are done with your code changes (or when you want me to do the rest) and I'll proofread the code and run more tests.

Your seven test cases over at Template:Ambox/testcases shows perfect box flow in all three of my browsers. (I have a very old IE 5.5, a slightly old Opera 9.02 and a Firefox 2.0.) For anyone else reading this: Those test cases do not yet show the proper 20px sized images, since the small image handling is not coded yet.

I will deploy the hand coded small version of {{expand-section}} today. I think we should perhaps wait some day after that before we deploy and document the small=left feature to {{ambox}}, to see what reactions we get from deploying the small {{expand-section}}. Or am I just too careful as usual?

--David Göthberg (talk) 17:16, 10 March 2009 (UTC)

Ok, I've done the image sizing code, as best I can determine. Take a look and tell me what you think. Happy‑melon 17:42, 10 March 2009 (UTC)

I gave the code a work over. Here's my comments:

In {{ambox/sandbox}}:

1: I removed the invalid "class" parameter, since {{ambox}} and /core do not support that. I guess you missed that when copying and pasting from {{tmbox}}, right? I don't think we should add support for the "class" parameter in ambox.

In {{ambox/core}}:

2: You changed to the {{td}} which broke the left cell when no image. I restored to the proper <td> styles. The "border: none;" is needed when ambox is placed inside some tables, otherwise the image cell gets a border. The "padding: 0px;" is needed, otherwise the empty cell becomes 3px wide, instead of just 1px wide.

3: You removed the "image=blank" feature. I assume you removed it on purpose? I did not restore that since I too think it is time we get rid of that.

4: The left image padding was broken also for the large version of {{ambox/sandbox}} before I changed the code. That was a sneaky bug and took me quite some time to figure out why my changes fixed it: That is because you didn't use "#default=" in the switch-case for the DIV and the DIV contained a "=" thus breaking the switch-case. I think I once read that is the very reason they added the "#default = Default text" statement to switch-cases in MediaWiki, instead of just "| Default text". So it is a good habit to always use the "#default=" notation.

5: There are several "small=left" switch-cases where we won't use special behaviour for "small=yes" if we ever add that. I would like to use "#ifeq:" statements there instead, since I think that means neater code. Is it okay if I change to that for those cases? Oops, wrong. Tricky stuff indeed... :))

6: You removed the right image 52px DIV, which broke the right image's padding. I restored that, and made it so the DIV is not used when "small=left". If we should get rid of the DIV for the right image, then we need to change the padding in the CSS classes accordingly. But I don't think we should get rid of that DIV.

Happy-melon: Don't feel I slaughtered your code. This is tricky stuff. If I had done the /core breakout you would probably have found a bunch of bugs in my code instead.

I have ran a bunch of tests and I think the code in {{ambox/sandbox}} and {{ambox/core}} now is fully working. (That two of the /testcases have a {{shortcut}} box as rightimage threw me off for a moment. But those boxes are supposed to have padding problems since the shortcut box is more than 52px wide, and imageright in ambox may only be tops 52px.)

--David Göthberg (talk) 05:49, 11 March 2009 (UTC)

1. Yup, hangover from tmbox.

2. You might want to have a look at Template talk:WPBannerMeta/Archive 3#Weird display error with collapsed section; the {{td}} template was originally an exact copy of the (tmbox I think) empty cell, with both width and padding at minimum; but we found that it was causing WikiProject banners to 'explode' vertically on some browsers. I'm not sure why or under what circumstances, but if it's something that could recur with ambox you might want to have a look. That's why {{td}} doesn't have the padding declaration, anyway.

3. Yes, I've never really understood that feature (IIRC it was a little trick you put in but never properly 'released'?).

4. Gah :D

6. Did I? Oops! I copied that code from tmbox/core because it had the |imageright=none functionality that we now need; I guess the div got overwritten in the process.

All your tests in /testcases look good to me. Happy‑melon 08:48, 11 March 2009 (UTC)

2: Yeah, I know that the [hide/show] javascript causes all kinds of weirdness with the mboxes. But the mboxes are very robust when not using the hide/show. Thus I think it is probably the hide/show javascript that needs fixing, not the mboxes. As far as I know we are not using any hide/show on amboxes, thus I prefer to use the best padding code we have for the amboxes.

But I have a slightly hackish workaround idea that might work: I have now marked the empty image cell with an "mbox-empty-cell" class. Thus the hide/show javascript can find those cells and modify the padding in them when hide/show is used. But we should perhaps not add that class to MediaWiki:Common.css, since the class name is just a marker. Or we could use CSS in MediaWiki:Common.css so that cells with the "mbox-empty-cell" class automatically get extra padding when inside hide/show areas, which would be more efficient than having the javascript doing the cell padding modification. (If using CSS then we need to use the !important keyword to override the hard coded styles, or we need to move the default styles into MediaWiki:Common.css too.) Or something like that. But you know more about the hide/show stuff than I do.

3: Eh? The "image=blank" feature is properly documented in the {{ambox}} /doc, with examples and all. As far as I remember I have almost always been opposed to that feature. (But I think I thought it was nifty during the first month or so.) But some editors wanted it, so we added it to ambox already from starters. And every time we have tried to remove it a small number of editors have protested and other editors have said something like: "Ah well, leave it in to keep them happy, it doesn't do any damage". But I think it is time to remove it, since I think it is slightly ugly and goes against our design praxis to use it, and as far as I know it isn't used at all now. And nothing will break when we remove it, even if some box is using it.

7: So, if you agree on my point 2 above then I think we are ready to deploy. Should we wait some more day for reactions on the small version of {{expand-section}}, or should we boldly press ahead? Or perhaps you want some time to investigate point 2 above?

--David Göthberg (talk) 21:09, 11 March 2009 (UTC)

I've taken a look at the new styling on an article and I think it looks great! I see no reason to hold back. I like it so much that I even went and updated the sandbox of {{Cleanup-section}} with the new look. :P --Blooper (Talk) 02:27, 12 March 2009 (UTC)

Blooper: Oh, thanks for the enthusiasm! I took a look at your /sandbox code, it looks fine. So I think you should deploy your sandbox version to {{cleanup-section}} right away. Thus more people will see this new design and have a chance to react. Technically that means those boxes will use the wrong style when used on for instance "Wikipedia:" space pages. But that is only a handful of cases and it is only temporary. Since we will deploy this "small=left" feature to {{ambox}} within some day and then you can change over to use {{mbox}} and then those boxes will have the right style on all pages. But they will be large when not on articles, unless we add the "small=left" feature to {{ombox}} too.

--David Göthberg (talk) 12:25, 12 March 2009 (UTC)

Section break

I have now deployed the "small=left" feature to {{ambox}}. We also removed the "image=blank" option at the same time. I didn't wait anymore for the following reasons:

• Some days have passed and I have only seen positive reactions on the deployment of the small {{expand-section}} and {{cleanup-section}}.
• Happy-melon's talk page says he is on a trip and won't be back until March 22, so I won't wait for Happy-melon's answer to point 2 above. And I am pretty sure my solution to point 2 above is a good solution.

I added some handling of the removed "image=blank" parameter to ambox: That is, I made it so if "image=blank" is fed it renders as "image=none", but it also error reports into Category:Wikipedia message box parameter needs fixing so we can find and fix any such cases.

And then there's a related issue: What should we do with templates like {{expand-section}} and {{cleanup-section}}? They are also used in "Wikipedia:" space and on category pages. Should they become large when displayed there, or should we add the "small=left" feature to {{ombox}} and {{cmbox}} too? Or should we make it so they instead display as small right aligned boxes on those other types of pages where we support small right aligned boxes?

--David Göthberg (talk) 20:01, 15 March 2009 (UTC)

Looks good! I've added the mbox-small-left declaration to Common.css, so we can start the decaching clock on that: 23 April assuming we don't change anything in the meantime. I'm not keen on adding the small=left feature to ombox or cmbox unless there's call for it; I don't see it as a particular problem that the same template has different appearances in different namespaces: that's the whole point of the mbox template!

I'll put the mbox-empty-cell issue on my list of things to do on a rainy day, but I'm not confident of an elegant solution. It's not a particularly important issue.

Keep up the great work! Happy‑melon 17:40, 22 March 2009 (UTC)

Thanks for adding the mbox-small-left class to MediaWiki:Common.css. And yes, that means we can remove the hardcoded small-left styles from ambox on 23 april.

Yes, technically and graphically it is not a problem that boxes that use the {{mbox}} with small=left becomes large in non-article space. So yeah, seems we are done here for the time being.

The collapsible stuff is scary stuff. Good luck with that if/when you try to fix that...

--David Göthberg (talk) 13:11, 23 March 2009 (UTC)

Mboxes with incorrect type

Could someone have a look at these mboxes?

• Mediawiki:abusefilter-disallowed
• Mediawiki:abusefilter-blocked
• Mediawiki:abusefilter-degrouped
• Mediawiki:abusefilter-autopromote-blocked

They don't seem to be about (speedy) deletion. —Ms2ger (talk) 19:24, 22 March 2009 (UTC)

Fixed They should (and now are) using {{fmbox}}. Happy‑melon 22:27, 22 March 2009 (UTC)

Stubs

Working on cleaning up the stubs a bit. Please see Template_talk:Asbox#mbox and Wikipedia_talk:WikiProject_Stub_sorting#Yes_please_.21 —TheDJ (talk • contribs) 14:25, 4 May 2009 (UTC)

Category proposal

Please see Wikipedia:Village pump (proposals)#Message box categories. Thanks. Dragons flight (talk) 07:00, 3 June 2009 (UTC)

Classes

Please see centralised discussion at Wikipedia talk:Manual of Style/Article message boxes#Classes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:21, 29 November 2011 (UTC)

New meta-template:{{hmbox}}

I've created {{hmbox}} (hatnote mbox) for the likes of {{resolved}} and others in Category:Image with comment templates, which previously all used copied code. If there are any bugs or suggestions please let me know. Cheers. Chris Cunningham (user:thumperward) (talk) 10:39, 14 December 2011 (UTC)

Title parameter

Some instances of {{Mbox}}, for instance {{Botcats}}, have a faux title. Can we add an optional title parameter? It should probably also have a |titleclass= and |titlestyle=. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 25 February 2012 (UTC)

Proposal to merge all the mboxes

I'd like to explore merging all the mbox templates into one. I've been doing a lot of work on {{ambox}} by adding new functionality, and it is not ideal that it does not share the same syntax as the other templates anymore. The advantages would include:

• Centralising code, so that it is not necessary to keep maintain several copies of similar code;
• Avoiding usage of wrong template in namespaces, by always using namespace detection unless |demospace= used to deliberately force a certain look;
• Improve ease of use, so that editors do not have to remember all the different templates to use.

I'm not sure if it would be practical to use a common core template for all, or whether separate subtemplates might be used. — Martin (MSGJ · talk) 08:09, 11 July 2012 (UTC)