User:ThinkBlue/Sandbox

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)

/* 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; }

(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:

.ns-talk .mbox-notice,
.tmbox-notice { 
    /* tmbox notice colours */ 
}

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.

<table class="mbox main mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

<table class="mbox image mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

<table class="mbox {{demospace|}} mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

Method 2

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

<table class="mbox-main mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

<table class="mbox-image mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

<table class="mbox-{{demospace|}} mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

Method 3

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

<table class="ambox mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

<table class="imbox mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

<table class="{{demospace|}}mbox mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

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.

<table class="ambox mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

<table class="imbox mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

<table class="{{mbox namespace detect|{{{demospace|}}}}} mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

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

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:

.tmbox.mbox-notice {
    border: 1px solid #c0c090;
}

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:

.tmbox.mbox-notice {
    border: 1px solid #c0c090;
}

But they can select on class names for elements inside each other, so they do understand this:

.tmbox td.mbox-image {            /* The left image cell */
    border: none;
    padding: 2px 0px 2px 0.9em;
    text-align: center;
}

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

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?

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)