Template talk:Imbox/Archive 3

Deploying on non-free licence tags

So far, I haven't seen a full discussion on deploying this on non-free licence tags. The problem is that there is a large amount of legalese on these tags, so when I try to put this on one of the long ones like Template:Non-free promotional, it is going to look like this (keeping the font size at 85%):

I would prefer that the Image:red copyright.svg image remain vertically justified at the top instead in the middle. Any other thoughts? Zzyzx11 (Talk) 16:09, 11 May 2008 (UTC)

I very much disagree: having images top vertically-aligned is something that has always irritated me wherever I find them. It's just a personal preference, but I much prefer the appearance of the box with the image centrally aligned - it makes the template look more balanced (and more professional: for some reason whenever I see a top-aligned image I instinctively assume it wasn't coded properly :D). Just my £0.02. Happy‑melon 17:04, 11 May 2008 (UTC)

I agree with Happy-melon that the central alignment looks much better. —David Levy 17:09, 11 May 2008 (UTC)

I agree that in general the central alignment is better, but in templates where there is a lot of boilerplate text, it probably would look better to change the layout somewhat. My inner designer says that perhaps we can find some tricks to allow the images to be center-aligned with respect to the first paragraph or so; such a solution would probably look better, in my humble opinion, while providing many of the advantages inherent in the standard layout. This might be achieved by adding an extra parameter to the template, say "{{{boilerplate}}}", that would add an extra table cell to the template, below the others, for the massive amounts of boilerplate text our image templates sometimes all too often use. Nihiltres^{t.l} 19:02, 11 May 2008 (UTC)

feature creep, in my opinion. KISS principle also applies. Since it essentially comes down to a personal preference, I can't see the point in bulking up the codebase of every page using these templates to fix such a trivial detail (assuming, of course, that one considers it currently 'broken' :D). Once we've loaded the styles into Common.css, of course, editors can override it with their own .css to top-align the images if they so wish. Happy‑melon 19:19, 11 May 2008 (UTC)

I agree with Happy-melon and David Levy, central alignment looks better. But from a technical point of view: I would really dislike to add more table cells and other such complex solutions. Instead we already have the "style" and "textstyle" parameters to handle other similar requests. So the simple way would be to add "imagestyle" and "imagerightstyle" parameters. And then you could set "imagestyle = vertical-align: top;". But I think even that would be function bloat. Instead, as I said before, if you need special functionality you should build those boxes with a table yourself and hard code the styles. When the CSS classes are available it will be pretty simple to build such boxes. By the way, I just tried, it doesn't work to set "style = vertical-align: top;".

--David Göthberg (talk) 20:43, 11 May 2008 (UTC)

I also feel that it is better in the centre; if it were at the top there would be too much white space below it. Waltham, The Duke of 03:32, 12 May 2008 (UTC)

David, you'd need to use !important to override the current inline styling, and it would only apply if that parameter affected the image cell (which currently has no css class or style parameter). Either that or you'd need some fancy CSS using table.imbox tr:first-child or something which doesn't apply right now. Waltham, the white space below the image can be solved using my alternate method with a separate table cell. For example, see my quick and dirty example, below, of the above template with my suggestion added. (if it's horribly broken, sorry, didn't bother checking code carefully, just hacked at it to make it look OK in Safari) Nihiltres^{t.l} 01:38, 13 May 2008 (UTC)

Sorry, Nihiltres, but that looks awfull in IE7 :D.

—Preceding unsigned comment added by Happy-melon (talk • contribs) 17:32, 13 May 2008

But it looks great in Firefox!...... Dendodge .. Talk^Help 22:01, 13 May 2008 (UTC)

That looks overwhelmingly verbose. Why not simplify some of that language? --  Denelson83  08:07, 26 May 2008 (UTC)

Colour code deprecated

As this code is not using the full colour wheel, I am not allowing it to show up on my screen. Add a use for green and I will reverse this. --  Denelson83  23:26, 13 May 2008 (UTC)

Yeah, we know. You refuse to accept the color code unless we invent a use for green purely for the sake of using green. Why should we care? —David Levy 23:33, 13 May 2008 (UTC)

Just add

table.imbox-featured {
border:3px solid #228b22;
}

to your monobook.css (or whichever skin you use) and the featured boxes will be green, completing the colour cycle. Nihiltres^{t.l} 14:26, 14 May 2008 (UTC)

Unfortunately, the way this template is coded now is circumventing my ban. Change the CSS to allow me to turn all the imboxes on my screen to green. --  Denelson83  23:43, 25 May 2008 (UTC)

Yes yes, and we of course do it on purpose! Actually, to accommodate the other 100 million or so users of Wikipedia (who don't know how to manually set or reload their CSS) we currently use hard coded styles while we wait the 30 days it takes for the CSS code in MediaWiki:Common.css to be reloaded into their web browsers.

Accommodating you, or the other 100 million users, now that is a tough choice...

But in about 30 days you will be able to skin the imboxes to your hearts content. Something you could not do at all with the old non-standardised image message boxes. So be happy, things are getting better.

--David Göthberg (talk) 00:17, 26 May 2008 (UTC)

That will not be necessary. --  Denelson83  00:32, 26 May 2008 (UTC)

What do you mean?

--David Göthberg (talk) 01:20, 26 May 2008 (UTC)

Isn't it obvious? He is planning a coup. Bye bye, Mr Göthberg... Waltham, The Duke of 03:02, 27 May 2008 (UTC)

Mbox differences

I believe that the only differences between ambox, imbox, and cmbox is: background colour; border; and border colour. (The "scheme" for each.)

(This is my understanding following several discussions with DG.)

Is this correct? - jc37 03:16, 24 May 2008 (UTC)

Not quite - each has some unique fixes that haven't (yet) been ported over to the other templates, although in an ideal world they would contain the same display tweaks. {{imbox}} has the "featured" type, which is not supported by the other templates. Each meta-template has its own set of default images. The current drive seems to be for a means of allowing {{imbox}} to take variable-sized images for the left image, which is not supported by the other two. {{imbox}} may also eventually include a "bottom text" parameter, which is not currently supported by the other two (although it may be in future). Happy‑melon 15:56, 24 May 2008 (UTC)

Happy-Melon's explanation is correct. But I certainly would not want a "below" parameter in ambox, that would be terrible. If article message boxes ever become large enough to need the below parameter then something is seriously wrong.

--David Göthberg (talk) 03:36, 25 May 2008 (UTC)

It sounds like all of those "extra" examples all (except "below") are things which should/could be merged to the other mbox templates.

(I think I've asked the next question previously of dg, but not sure.) So how evil is the notion of merging all the mboxes into a single "mbox" template, which has a "style" option for setting the "default" border/background colour scheme as a single entry in the template?

scheme = ab

(the ambox scheme - coloured border along the left side)

or

scheme = cb

(the cmbox scheme of coloured backgrounds, useful for any "bluespace" namespace.)

or

scheme = ib

(the imbox multicoloured border scheme)

I would presume that (once coded) this would thus be rather user friendly?

Or is such a thing not possible? - jc37 05:29, 25 May 2008 (UTC)

The different mboxes have slightly different needs and thus slightly different code. For instance since ambox doesn't need and shouldn't have large images it instead have a div in it that makes the text line up nicely when we stack such boxes. But all those differences could of course be handled in the same template using such a parameter as you suggest. (That would mean a single template with a LOT of code inside.) Now we use them like this:

{{ambox|...}}

Say we call your version "mbox", then it would be used like this:

{{mbox|scheme=ab|...}}

Which is simpler to type? Which causes the least template code to process for the servers? Which causes the simplest code in the box? Which is the easiest to maintain? Which does not cause that ALL message boxes on Wikipedia breaks if someone does a mistake with the code? Which does not cause 1.1 million pages to re-render each time we update it?

There is nothing to gain and a lot to loose from putting them all together to one template. So what would be the point in doing that?

--David Göthberg (talk) 07:46, 25 May 2008 (UTC)

Well, actually, the "scheme" could even be predetermined based on namespace through a parser call.

You latter point about "update" is interesting, which makes me wonder if even ambox/cmbox/imbox is each more complex than it needs to be. I would guess that a fair chunk of coding of all these templates could be put into a "core" mbox if we felt that such concerns were concerning. And if so, perhaps that's the better answer. But it's interesting to me that essentially these all are:

• "boxes"
• with an option for at least one image
• with text
• with a background
• with a border

Honestly, they aren't much different than userboxes, save for size and page placement.

So in looking at the above, what do you feel will have the most "tweaking" which would require such changes? Let's then put the "most stable" parts of this into mbox. If "change" and complexity of code is the actual concern. - jc37 22:30, 25 May 2008 (UTC)

There is some merit in your argument, and I really wish we'd never got into the groove of thinking that these templates attack the server with a baseball bat every time they're updated: I edited {{portal}} not that long ago, which is the silver-medalist with over 1,000,000 transclusions: no effect whatsoever. If it simplifies code and makes it easier to maintain the boxes and propagate updates across them, then we should do it; but we shouldn't do it just because we can - only if it has those advantages. It seems to me that {{imbox}} is deviating from the other standards (with flexible left-image sizes and |bottomtext=) enough to make combining it with the other boxes into a super-meta template difficult - everything that's not the same in all the boxes is something we can't move to the meta-template. Having a super-meta-template without the imbox functionality would be worse than useless; and I just can't see how we could easily merge together enough of the template code to provide significant advantages. Happy‑melon 22:38, 25 May 2008 (UTC)

Jc37: It seems we will have only 6 message box meta-templates: ambox, imbox, cmbox, tmbox, ombox/dmbox, and the namespace-detecting "style-chameleon" mbox. There are good reasons to not let the first five be "style-chameleons" but sometimes we need that functionality and then we have the mbox. And note that mbox just calls the others as needed, so it doesn't have much code in it. And for instance the tmbox is likely to get a lot of special features that the other boxes don't have. So putting together all those special features into one template would cause much more trouble than maintaining six different templates. When we come up with a piece of code that fits in several of those boxes the work to copy and paste the code to them is nothing compared to the work of creating that new code and testing it properly in one of them. If we had one single meta-template instead the work to code and test it properly would be WAY harder.

--David Göthberg (talk) 23:41, 25 May 2008 (UTC)

The "complexity" arguement would be nice, if it weren't for the fact that a "Template-mbox" "special coding" situations (for example) could easily be resolved by using a template which would call "mbox", while adding it's "special features", I presume?

I guess one of the things I keep noticing is that as these discussions progress, new (and good) ideas keep popping up for things which would be useful on all mboxes. So it would seem to make a heckuva lot more sense to have a "core" mbox to make the single change, than going around to all the mboxes to make the change. Else it seems like we're defeating the purpose of standardisation.

Also, in regards to "other": Let's just unite all the "bluespace" mboxes. I would presume that the "style" for category-space would work just fine for Wikipedia space. And the only difference I can see between ambox and cmbox is the "style" (colour/background/border), so it could be easily merged, with a parser of "namespace", as could "talk" space versions.

To give another example of why this could be useful: It could cut down on the number of actual templates necessary.

Imagine if someone only had to merely place an {{xfd}} template, regardless of the namespace, and the template would "do the work for them". We should be attempting to make precesses easier not more difficult.

Same goes for the various cleanup templates. I can imagine several which may be useful in more than one namespace. (Indeed, this was brought up a few times in the various mbox discussions, but was considered by some as potentially "too complex" - there's that arguement again - and so was "left by the wayside".)

I can understand the imbox is more complex. (Especially since there was a decision to merge all the licensing mboxes to it.) But that could be done (I presume) by a "call" to mbox (thus allowing the "core" to be changed with all the other mboxes), with "imbox" having the "additional" needed style, or whatever.

It just sounds like smarter, more intuitive, more adaptable, coding. And looking more to the long term than the short term.

However, if I'm missing something, please let me know. - jc37 21:32, 26 May 2008 (UTC)

Well, as we already have explained several times above: We are about to handle the examples you mention about templates that needs to be used in several namespaces. That is we are going to make tmbox and ombox/dmbox so we cover all namespaces and then make the {{mbox}} that calls the right box for the right namespace. Then the small number of message boxes that need namespace detection can use mbox. So we are going to supply the functionality you want, we just code it "backwards" to the way you are thinking of, since that is better.

Since you don't seem to understand the advantages of our approach even though we explained it in detail several times for you, then there is really only one more thing you can do to increase your understanding: I suggest you try to code up the "message box über-meta-template" you are thinking of. Since when you work with the code then you have to consider all the details and then things probably will become clear to you. Don't forget to handle all the special cases for all the different namespaces. Like that the boxes should only have the ".metadata" class when on articles. (See the Metadata class discussion below.) I suggest you try it out in your own user space, for instance at User:Jc37/mbox. There is of course a chance that what you build becomes better than the current approach and thus you prove me wrong, since you might be seeing something I am missing. Then we of course should use the better solution.

--David Göthberg (talk) 03:09, 27 May 2008 (UTC)

Ouch. Please pardon me for attempting to discuss, and attempt to offer some ideas concerning design, organisation, and implementation. I guess I just didn't see the problem with "talking through" the concepts together. If they turned out to be "undoable", fine. Or even if they were unwanted by consensus, fine. My teachers in programming languages always suggested to have top-down design, and build callable/loopable processes from the inside out. This would seem to be no different (to me at least). Build your "core", and build outwards. The stronger the foundation of your "core", the better use the implementation. And in the modern era of "portability" and "transclusion", I would presume that such lessons in programming would be even more important, preventing spaghetti code and logic. But, again, I won't come even close to claiming to be an expert in this type of coding, and was attempting to learn more. My apologies if my pedantic attempts at discussion hath wasted your invalued time. Personally, I think, and have thought you (plural) to be great. My opinion hasn't changed (mostly), just a bit of shock at being slapped, I suppose. I think it's best if I just bow out of this discussion and leave you to your regularly scheduled davidgothberg. I wish you (plural) well. - jc37 05:43, 27 May 2008 (UTC)

Oh, sorry, I wasn't meaning to slap you. And sorry if I tend to use too hard language. I can't even use the excuse that I am Swedish, since I tend to argue hard in Swedish too. I just don't understand the benefits of your approach. It might be that I miss something and I would be more than happy to be proven wrong. (Well, I might sulk for an hour but I usually get over it quick.) I like improvements, no matter who invents them. But I don't understand how I could implement your approach in an efficient manner. Thus I think you have to do it, since perhaps you know how to do it? If you code it up I can see two likely outcomes: Either you show me/us how to do things better (I'd love that!) or you discover that the current approach is simpler (which would be a boring outcome...). So what I mean is that more words doesn't seem to take our understanding further, but I think code can. (Kind of sounds geeky, but I think you have to speak to us through code in this case. :))

And regarding your teachers: Well, splitting up programs in modules is a very important thing too, which unfortunately often is skipped over since programming courses tend to focus too much on object orientation. Object orientation is meant to be used together with the older modular programming concept, not instead of. Modular programming = "divide and conquer", as opposed to "monolithic programming".

--David Göthberg (talk) 06:30, 27 May 2008 (UTC)

Metadata class

I was the one who added the metadata class to Template:Ambox, which has subsequently been added here. This is causing templates using Imbox to not be displayed when printing, due to .metadata being noprinted in MediaWiki:Monobook.css. This class should be removed the next time this template is updated, as we definitely want licensing tags to be printed. --- RockMFR 21:14, 26 May 2008 (UTC)

Oh, right you are. Thanks for pointing that out. (With many eyeballs all bugs are shallow. :)) I fixed it in {{cmbox}} immediately since that template is "only" used on 14,000 pages. I am copying this discussion to MediaWiki talk:Common.css#Metadata class in mboxes and will continue there since I have some questions about this.

--David Göthberg (talk) 02:11, 27 May 2008 (UTC)

Styling boxes on user pages

This discussion cut out of the above discussion.

Given the disparity between the User: namespace and all of the others listed above, I suggest that we create {{umbox}}; it should be geared toward customizability (given the fact that users are free to use whatever styles they please). —David Levy 06:09, 27 May 2008 (UTC)

Well, some of the uses of the "other spaces" ombox/pmbox/dmbox on user pages will be protection templates that are put there by the admin protecting a user page. Then the standard "other pages" style should be used I think, just as it is now. But yes, other uses will be when the user himself puts some cute box there. Then the user can use the "style", "textstyle", "image" and "imageright" parameters we have on our meta-template boxes to create a box in whatever style the user prefers. So our boxes already are very customizable. Actually, when we started out the imbox and cmbox the examples we put on these talk pages with the new styles were created by using ambox and feeding it style parameters. So the imbox examples you find in the first archive page are actually amboxes!

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

I'm aware that any of the mboxes can be customized in that fashion, and that's what concerns me. I'm thinking that we could establish a "friendly" means of doing this that's deliberately incompatible with any mbox other than the hypothetical {{ubox}}, thereby discouraging users from getting the wrong impression about Wikipedia and "having fun" in the non-user namespaces by taking similar liberties with the templates there. —David Levy 12:42, 27 May 2008 (UTC)

We added the style parameters since there are some situations when they are needed. I think the only way we can prevent those parameters from being misused is as usual by reverting bad edits and explaining to people why. Of course, we probably should add some comments in the documentation that use of the style parameters are discouraged and that the boxes are supposed to use the standardised look. I have not added such comments since I don't know how to say it in a short way, without it sounding too harsh. If someone knows how to say it in a compact and clear but still friendly way feel free to add it to the documentation. For the {{ombox}} we could add some comment that users are free to style the boxes any way they want on their user pages, but on other pages the standard look should be used. I think that should be enough, no need to have a special box for user pages.

Unless of course if you are thinking of a super pimpable user page box with parameters like "roundedcorners = yes" and so on. But that is outside the scope of this mbox project. Although of course this is a good place to announce such a box to get help with it. If someone makes such an "extra easy to style box" then it can just as well be misused by users using it on other pages. But that will of course have to be handled the usual way by reverting and explaining. Of course, such a user page box could include a little namespace detection and show a warning text if it is used on other pages.

--David Göthberg (talk) 21:32, 29 May 2008 (UTC)

New code

I have now updated {{imbox}} with most of the new code I have shown in {{imbox/test1}} for some days now. Here's the changes:

• I removed the "metadata" class, since imboxes should be printed.
• I removed an unneeded border style before the first switch case.
• I gave the "image=none" case better handling. The empty cell is now much thinner giving the text less left padding in that case.
• I removed the div, thus left side images can now be any size without using the "bigimage" parameter. That is, the bigimage parameter is no longer valid. Boxes that feed the bigimage parameter should not notice any difference. To accommodate this change I adjusted the padding in all the cells slightly.

I did not add the "below" parameter since that one seems to still be under discussion. Happy-Melon called that parameter "bottomtext" when he mentioned it in a discussion above. I don't know if that was on purpose, but I prefer the name "below" since that is the name used for it in {{navbox}}. Using the same name for it in different templates makes life easier for the editors. If anyone wants another name for it, this is the time to state so.

Since we now have several cases where text or another image message box needs to be inserted/nested into an imbox I think we need the below parameter. Having the below code a part of the imbox allows proper handling of the cell width. That is, when there are a right side image the first table row has 3 cells, otherwise it has 2 cells. And the below cell needs to know that to set the proper "colspan=2/3" to look right in all web browsers. Apart from that the below code is on its own table row and does not affect the coding of the rest of the box at all, thus doesn't make the rest of code more complex. The code I am suggesting and examples are available at {{imbox/test1}}.

--David Göthberg (talk) 05:05, 27 May 2008 (UTC)

I couldn't remember what the parameter was actually called (and it's |BOTTOM_TEXT= in "my" {{WPBannerMeta}}, so that rang a bell). No objection to |below=. Happy‑melon 10:07, 27 May 2008 (UTC)

I've deployed Imbox on Wikinews.

checkitout

yeah, we're not sure what we're doing about cc-by-nc/nd stuff yet so ignore it cause it looks a bit "slapped together". Anyway... ViperSnake151 21:45, 28 May 2008 (UTC)

Someone slapped the local equivalent of {{db-copyvio}} on it - that cracked me up!! Happy‑melon 13:34, 29 May 2008 (UTC)

Other spaces message boxes

This discussion was cut out of the sections above to keep different issues apart:

I have a bigger plan with this: I want to keep ambox, imbox and cmbox parameter-compatible. Since I intend to make compatible standardised message boxes for talkpages and for "other space", thus covering all namespaces. Because then we can make an ambox compatible "multibox" that can detect what namespace it is in and change appearance accordingly. The multibox should of course only be used for templates that are intended to be used in several namespaces.

--David Göthberg (talk) 06:35, 19 May 2008 (UTC)

I was thinking very much the same thing... {{mbox}} anyone? Happy‑melon 18:26, 19 May 2008 (UTC)

That one is taken... — Edokter • Talk • 19:06, 19 May 2008 (UTC)

It's an almost bit-for-bit clone of {{nowrap}} - I'm boldly clearing it. Happy‑melon 19:14, 19 May 2008 (UTC)

Happy-melon: Well, the name {{mbox}} is taken, but you are right that that one should be merged with {{nowrap}}. And considering the naming discussion we had about {{catbox}} / {{cambox}} / {{cmbox}} I think we could call it {{mmbox}} = "multi-namespace message box" or perhaps {{multibox}}.

--David Göthberg (talk) 19:57, 19 May 2008 (UTC)

I have to say I think the concept of {{mbox}} being the 'super-meta template' (although it's actually a level below {{ambox}}/{{cmbox}}/{{imbox}}) makes more sense to me. What do we do if we want to standardise the templates used in MediaWiki: ?? </devils advocate> :D {{mbox}} is now transclusionless, so it's available for our use if we want it. Thoughts? Happy‑melon 08:57, 20 May 2008 (UTC)

We'd end up with one super-meta template that gets transcluded on virtually every article, if not page, on Wikipedia. And then we'd have to correct an error... No, I'm not fond of one the super-template modem. In fact, Ambox already received suggestion to break it up in categories because the template is used so much. — Edokter • Talk • 12:21, 20 May 2008 (UTC)

That's not the idea at all: it's only supposed to be used for templates that are supposed to be used in multiple namespaces, of which there aren't that many. At the moment they either have to have individual code to switch their appearance by namespace, or they don't change appearance at all (which is obviously sub-optimal). One way or another, we need a method of switching which Xmbox template is called, and that code might as well be in a template for ease of maintenance (otherwise if we standardised another namespace, we'd have to update each multi-namespace template individually; which rather defeats the object of standardisation in the first place). It doesn't matter whether that template is {{mbox}} or an extended version of {{main talk other}} - it's still going to appear on every page where the multi-namespace template is used. But since we have relatively few templates which are 'legally' used in more than one namespace, over-transclusion is not going to be a problem. Anyway, the server load of high-use templates is massively overstated anyway - one day I'm going to do a null edit on {{!}} just to prove that the servers can take it... <evil laugh/> Happy‑melon 20:55, 20 May 2008 (UTC)

I've created what I hope is a reasonably clean-cut meta-template at {{mbox}}; it's got some tricks in it to retain the defined/undefined nature of the parameters passed through it (should work like that anyway - any undefined parameters are diverted to the null parameter so they don't corrupt live ones). In order for it to be able to work in all namespaces while maintaining clean code I need to create template wrappers for the 'coffeeroll' format used in talkspace (in normal, small and collapsed styles, I suspect) and the 'boilerplate' style used occasionally elsewhere (for the #default option). I doubt these will ever be called directly, it's mainly for the sake of competeness; I'm not suggesting that we change all the talkspace templates that currently use wikitables directly to use a talkspace meta-template. Any preferences on nomenclature? {{tmbox}} is an obvious choice, but that might lead to later problems if/when we standardise what Template: namespace messages we have. {{tambox}} might be usable, to allow {{tembox}} for templates if necessary; but it's out of line with the other names if we never end up doing the template templates (:D). It's a shame we've got two namespaces with the same first letter really - I think this is the only such conflict. Thoughts? Happy‑melon 11:40, 20 May 2008 (UTC)

I've now created {{dmbox}}, which is a 'default' based on the 'messagebox' css class. All the |type= parameter does is change the default image (it has one for all types supported by the other meta-templates, using the hierarchy ambox→imbox→cmbox to take images from), and I think that that's probably sufficient. Still interested to hear thoughts on the talkspace metatemplate (it seems {{tmbox}} was briefly a testbed for a Template: namespace metatemplate, but it's unused and inactive). Happy‑melon 12:30, 20 May 2008 (UTC)

Talking to yourself, are you? :-)

Although you have resolved the letter conflict quite nicely, I do not believe it ought to have troubled us. How many different message boxes are used on templates? I believe they are rather few; too few to necessitate the creation of a dedicated template.

PS: Please warn me in advance when you decide to edit {{!}} (but nobody else). Waltham, The Duke of 05:50, 22 May 2008 (UTC)

<plaintive wail>There was no one else to talk to!</plaintive wail> :D If you're confident that we'll not regret it later, I would prefer to use {{tmbox}} for the talkspace wrapper, for consistent nomenclature. Happy‑melon 09:05, 22 May 2008 (UTC)

I am not over-confident about it, which is why I require information on the matter. Is there no one here with knowledge of the template-namespace message boxes? For Unicorn's sake, we are supposed to live in the Age of Information. Do I have to start bribing around again to get what I want? So disappointing... Waltham, The Duke of 09:30, 22 May 2008 (UTC)

Template-namespace message boxes are, in a way, standardized: the standard is {{Documentation}}. Nihiltres^{t.l} 14:18, 22 May 2008 (UTC)

Clever. :-) What I meant, however, was something closer to {{intricate template}} and {{high-use}}. Waltham, The Duke of 15:06, 22 May 2008 (UTC)

Ouch, I shouldn't have mentioned my plan to make more mboxes... Anyway, here goes:

1: As Happy-Melon said above: The multibox (or whatever we are going to call the message box meta-template that will detect namespace and change appearance accordingly) should NOT be the basis for the others, instead the multibox should only be used for the small number of message boxes that are used on several types of pages. And I would like to call it "multibox" since it is different from the others. Although I could live with the name "mmbox" or "mbox".

2: Yes, we should do an ambox compatible box for talk space templates. And I think we should call that one "tmbox". And that one should of course use the standardised brown colours for talk space templates. See Wikipedia:Talk page templates for the official guideline. There are some reasons to make the tmbox: Easier to use than hand coding boxes with a table like people do now, if it is parameter compatible with the other mboxes it makes it easier to build the multibox, and it can use the same flow tricks that ambox has thus will look good in all browsers. (The current talk space message boxes do look strange in some older browsers and do have box overlapping problems even in some modern browsers.)

3: We also should do an ambox compatible box for all the "other pages". I see that Happy-Melon likes to call those boxes "default" but I would like to call them "other" as in "other namespaces" and "other pages message boxes". Thus I want to call that box "ombox", not "dmbox". And that box should use the standardised grey colour and one pixel border already used for such message boxes. With grey border for normal boxes, and perhaps coloured borders for the more urgent boxes. Of course, that old standard is not set in stone, consensus can change.

4: I think we should NOT make any new message box designs for any other namespaces. For instance I see no reason to make a new standard for template pages. The big green documentation boxes should be more than enough to make it clear that you are on a template page. Thus template message boxes like {{intricate}}, {{high-use}} and {{pp-template}} can continue to use the "other pages" style. The reason we made special standards for category and image pages was that there already were kind of de facto standards for them. Those de facto standards are what we now have formalised into the {{cmbox}} and {{imbox}}. (Personally I think we could just as well have used the same design for both those namespaces, but popular demand seems to be to keep them apart.) There's also some technical reasons to keep the number of styles low: Adding these styles costed a lot of new CSS code in MediaWiki:Common.css, which makes Wikipedia even slower to load for modem users. Add a little more and I don't think modem users can really use Wikipedia anymore. Modem users already have to turn of javascript loading to be able to visit Wikipedia without having to wait for ages for the first page load since the javascript pages are about 250-500 kbytes to load now! (Of course, there are technical workarounds the developers could add to handle that, but currently they have not added those workarounds.) Also, I think we might be running out of good looking styles to use...

5: Waltham: Yes this is the "age of information", as usual the problem is just to find the information: The list of template namespace message boxes is just some clicks away: Help -> Templates -> Template = Wikipedia:Template messages/Template namespace. As you can see there aren't that many template message boxes. If anyone know any other just add them to that page.

6: Happy-Melon: I have already made the new extended über-version of {{main talk other}}, it is called {{namespace detect}}. I think you will like that one.

--David Göthberg (talk) 23:11, 22 May 2008 (UTC)

I do not place much trust on the relevant categories, and perhaps that has spilled over to template lists; the categories are often convoluted and scarcely maintained, and editors who actually use the templates can sometimes be more reliable in this sense. But I've never really thought there were many of theses templates, and I have mentioned that again. Waltham, The Duke of 00:00, 23 May 2008 (UTC)

I'm not fussed over {{dmbox}} vs {{ombox}}, but I feel quite strongly that the switch template should be at {{mbox}}; there's no all-powerful reason why, it just seems to make sense to me. I agree with the comments above vis the template namespace; which frees up {{tmbox}} for the talkspace meta-template. How extensively do we want to implement that? Given that it should produce no visual changes, there shouldn't be any objections to us converting talkspace templates to use it. However, there are a few caveats we'd have to work through (I assume we'd change between "normal", "nested" and "small" using the |type= parameter, but the "nested" boxes need to be passed header text in a separate parameter...). Thoughts? If we're concerned about the length of common.css, there are various things we could (and should) be doing to optimise it. Apart from cutting out some of the more egregious comments, a number of the classes are either duplicates or deprecated: we should be trying to get those classes removed from use thoroughly so we can remove the code. Happy‑melon 11:24, 23 May 2008 (UTC)

Well, I think the name "mbox" makes it sound like that is the one to use in the normal case and the others like imbox and ambox are just special cases, when it really is the other way around. While "multibox" tells that it is special in some way, different from the others.

Regarding {{tmbox}}: I don't know if the "small" talk page message box type is used anymore, I haven't seen it for a long time now. (For those that don't know the small type, look at the example close to the end of Wikipedia:Talk page templates.) But if it still is used I think then tmbox should support it. But I am partial since I think the small type is cute.

Happy-Melon: What is a "nested" talk page message box? Can you link to some example?

Also, I think we should not use the "type" parameter name to switch between normal, small and nested talk page message box style. Since that means tmbox will not be parameter compatible with the other mboxes and then multibox/mbox can not use tmbox at all. See for instance the templates {{notice}}, {{caution}} and {{warning}}. Those templates will use the multibox/mbox and need to feed the type parameter to all the different mboxes to set the type as in how urgent the message is. And {{notice}} currently has the parameter "small=yes" which works fine.

The first concern should be to make a tmbox that is compatible with the other mboxes so that multibox/mbox can use it. Adding the other talk space specific functions can be done later, since message boxes that are used on several namespaces will probably not use the talk space specific functions anyway.

--David Göthberg (talk) 02:58, 24 May 2008 (UTC)

I'd have thought it would have the opposite effect: surely the higher up the template tree it appears to be, the less likely it is to be used? If the perception was that {{mbox}} was an all-powerful meta-template, of which {{ambox}}, {{imbox}} etc were derivatives, then the instinctive reaction is to use one of the lower-level templates if possible. In the {{db-}} template series (for CSD templates), for instance, we have {{db-meta}}, the over-arching meta-template which is not supposed to be called directly, then we have an instance for each CSD criterion (eg {{db-a7}} for WP:CSD#A7); that template itself has a number of derivatives like {{db-corp}} and {{db-web}}, which are for more specific instances - those templates for specific instances of CSD#A7 are instances of {{db-a7}}, not directly to {{db-meta}}. I think this perception of a template hierarchy is well ingrained into a large number of editors' wiki-knowledge, along with the perception that new templates should be 'hooked' onto the tree as far down as possible while still doing the job effectively. Although {{mbox}} isn't a higher template than {{ambox}} etc in terms of code flow, it is in its usage, so I don't think we have to worry about new templates using it when a 'lower' template would suffice. {{multibox}}, on the other hand, suffers from obscurity: it doesn't sound like it's connected to the messagebox standardisation program at all, which I think is likely to lead to it just being forgotten, and people either adding the code by hand or not adding it at all, neither of which are optimal solutions.

The "nested" type is used very widely: all WikiProject banners, for instance, have an option to specify it. It's basically just an implementation of collapsible tables - the problem is that if we want to get a {{tmbox}} that's at all useful, we'll need to provide a separate parameter for what displays when the box is collapsed, which has to be sent to a header cell of the table (I'm also not sure how to code that in raw HTML, although I'm sure there's someone else who can). I certainly know people who are still fond of the small types - personally I think they're horrible, but that's just me. I don't think using |type= to switch between "small", "nested" etc would affect portability: neither "small" or "nested" are acceptable types in any other mbox, and if we were to precisely mimic the current implementation of talkspace messages, there are no other 'types' to switch between - there isn't a different appearance for deletion templates or content templates in talkspace, although perhaps there should be a different appearance for what we'd recognise as the "delete" and "speedy" types. The problem with using |small= and |nested= is that we'd have to ensure that every template which used {{tmbox}} passed those parameters with |small={{{small|}}} etc, which would be over the heads of many template writers. More food for thought. Happy‑melon 16:44, 24 May 2008 (UTC)

Yes, many things to consider.

1: You got some good points about the mbox name. So to get things going I'll agree to the name {{mbox}} then.

2: Seems everyone likes the name {{tmbox}} so that name is clear. I think we should continue the discussion about the details of tmbox on its talk page. But as I said above: I suggest we first make it a "simple" mbox compatible meta-template so we can use if from mbox as soon as possible. It won't be usable for all talk page message boxes then, but will be usable for the boxes that need to go on several pages since they won't anyway use the talk page special features. Then we can extend tmbox later.

3: We need to decide on the naming for the message box for the other namespaces. (The one that will be used on "Wikipedia:", "Help:" and "Template:" pages.) I prefer the name {{ombox}} as in "other spaces message box" and Happy-Melon seems to prefer {{dmbox}} as in "default message box". To decide this we need input from more editors. So what do the rest of you think?

--David Göthberg (talk) 04:00, 27 May 2008 (UTC)

I've always favored {{pmbox}} as a name for a message box used in the project (Wikipedia:) namespace, and pages in the Help: and Template: namespaces are also thought of as project pages (as opposed to parts of the encyclopedia proper). As an added benefit, "pm" (pmbox) is memorable as the opposite of "am" (ambox). —David Levy 04:16, 27 May 2008 (UTC)

Yes, I also think of those three and some of the other as "project space". (Although in strict MediaWiki naming "project space" is only "Wikipedia:".) But the "other spaces box" are going to be the "default box" for all the namespaces not covered by ambox, imbox, cmbox and tmbox. Thus it should/may be used in these namespaces: User, Wikipedia, MediaWiki, Template, Help, Portal and any new future namespaces.

Oh, haha, now I see your wordplay, "am" vs. "pm". Well, for me as a Scandinavian the word "om" is a very old and very powerful word. In this case similar in meaning to the Latin word omni meaning "all". Perhaps that's why I like "ombox" so much. Of course, the true "omnibox" will instead be the mbox.

Anyway, I am not so sure that "project message box" feels like a good name for a box used in user space, but perhaps not worse than "other message box" or "default message box". So the suggested names so far are: pmbox, ombox and dmbox.

--David Göthberg (talk) 05:51, 27 May 2008 (UTC)

Given the disparity between the User: namespace and all of the others listed above, I suggest that we create {{umbox}}; it should be geared toward customizability (given the fact that users are free to use whatever styles they please). —David Levy 06:09, 27 May 2008 (UTC)

The PM at the dispatch box

I am also unsure about "pmbox"; it is not very accurate and, in any case, it doesn't necessarily evoke in everyone the am–pm contrast. "Dumbox" is probably out of the question, for obvious reasons. (You say there is no u in the proposed name? Well, it won't take long for someone to add it.) Waltham, The Duke of 06:16, 27 May 2008 (UTC)

I'm not clear on how "pmbox" is inaccurate, and please note that I mentioned "am"/"pm" only as a cute mnemonic device (not as something intended to be obvious to everyone).

The "dmbox" option is my least favorite, but I have to say that your "dumbox" objection is a bit of a stretch. I don't see how that's inherently implied, and it certainly didn't cross my mind. —David Levy 06:28, 27 May 2008 (UTC)

Ok, I was mostly joking about the am–pm thing, but I believe that using "project" in this sense might cause confusion with the Project namespace. I shouldn't make such a mistake myself, but on Wikipedia I have learnt to pay more attention to the dumbness of many of its users. Which brings me to the other name... It might be a stretch to you, but it wasn't to me, and I am sure that it will be as easy for many other people to make this association. It might have to do with how "phonetically" people think, and whether English is their mother tongue, but I assure you that, in the end, it will look silly. Waltham, The Duke of 06:45, 27 May 2008 (UTC)

I doubt that most users are aware that Wikipedia: is our local name for the Project: namespace, and those of us who are also are knowledgeable enough to know that pages from many other namespaces are commonly referred to as "project pages." My suggested template name is based upon the latter meaning.

I really don't see how the "dumbox" issue would be a problem, even if this does seem obvious to some people (which it doesn't to me). What harm would this silly joke cause? —David Levy 07:04, 27 May 2008 (UTC)

I don't know how I feel about "umbox", except that it sounds like "ambox". Waltham, The Duke of 06:19, 27 May 2008 (UTC)

True, but so does "ombox." —David Levy 06:28, 27 May 2008 (UTC)

Not quite as similar, I'd say. :-) Waltham, The Duke of 06:45, 27 May 2008 (UTC)

To me, "ombox" seems more similar (given the fact that "ambox" could carry the same pronunciation in some English varieties).

I don't regard this as a major issue, however. —David Levy 07:04, 27 May 2008 (UTC)

Neither do I, and dumbox would not really be harmful (it might even result in a popular in-joke). This whole exchange (and here I unite the two sub-threads) probably shows how I tend to rule out options when there aren't more serious reasons to help me make a seletion. :-D For those who haven't noticed, this entire debate falls squarely under the category minutiae. Waltham, The Duke of 07:38, 27 May 2008 (UTC)

Okay, fair enough. And as I said, "dmbox" is my least favorite of the options presented thus far (because I don't regard "default" as an accurate description). —David Levy 07:47, 27 May 2008 (UTC)

In the interests of compromise, I'll support {{mbox}}, {{tmbox}} and {{ombox}}. From my reading of the discussion above, that kills {{dmbox}} dead :D, bringing us back to two options. Given that this box is also going to be used in the Template: namespace and potentially the Transwiki: pseudospace as well, "other" seems a more comprehensive description than "project". Thoughts? Happy‑melon 10:17, 27 May 2008 (UTC)

For the same reasons, I'll support {{ombox}} as well (so we can eliminate {{pmbox}} as an option). —David Levy 12:42, 27 May 2008 (UTC)

Great. I've moved {{dmbox}} to {{ombox}}, updated its only transclusion, and deleted the redirect. Since this discussion is getting very tangential to {{imbox}} itself (and the number of colons here is getting ridiculous!) I propose we continue the various threads of this discussion on Template talk:Mbox, Template talk:Ombox and Template talk:Tmbox. Happy‑melon 13:31, 27 May 2008 (UTC)

Indention is not a problem if you unindent occasionally.

I have now coded fully working draft versions of {{ombox}} and {{tmbox}}. Thus the mbox series of meta-templates now cover all namespaces. Everyone please have a look at them and discuss their design on their talk pages. This should also make {{mbox}} fully working, but I haven't tested that yet.

--David Göthberg (talk) 07:45, 30 May 2008 (UTC)

Imbox-inside

Note that since this was written the code of imbox has been updated so the example below now shows 100% width even for the default styles.

Just in case anyone wants to know what is going on and for future reference:

I have updated the CSS code for imbox in MediaWiki:Common.css. The main reason is that I needed to add proper padding for the image cells since we have changed the image-cell code in the template. That is, I copied the new hard coded styles from {{imbox}} to Common.css.

But I also added automatic handling of when imboxes are placed inside other imboxes or other templates. Otherwise they will be 80% wide and that looks bad. This can be manually fixed by using the style="" parameter, but it is much better if it is automatic. Here's an example:

File information

Description	Testing imboxes inside the {{information}} template.
Source	With the default imbox styles.
Date	2008-06-01
Author	David Göthberg
Permission (Reusing this file)	With 'style="margin: 4px;"'. This can also be done automatically with CSS.

If we add the "below" parameter to imbox I intend that the below cell will use the class "imbox-text", since it will in some cases contain text and thus needs the same padding as the normal imbox text cell. The first class in the code below fixes the margins of the inner imbox when inside an imbox-text cell.

Imboxes will also be placed inside some other templates, such as {{information}}. If those templates do not have a class name of their own then imbox can not detect that it is inside them. Therefore I have invented the class name "imbox-inside" that I will add to those templates, thus making it possible for imbox to detect that it is inside those templates. The second class in the code below uses that approach.

Here's the code I have added to MediaWiki:Common.css to handle imboxes inside other boxes:

.imbox-text .imbox {      /* For imboxes inside imbox-text cells. */
    margin: 0 -0.5em;     /* 0.9 - 0.5 = 0.4em left/right. */
}
.imbox-inside .imbox {    /* For imboxes inside other templates. */
    margin: 4px;
}

I have of course tested it in some sandbox pages.

--David Göthberg (talk) 13:09, 1 June 2008 (UTC)

Gah! Just as I had finished it all I realise that "imbox-inside" should perhaps instead be called "mbox-inside" so we can use it for {{tmbox}} and the other mboxes too. Since tmbox will be placed inside some different talk page templates and most of them lack their own class name. Seems simpler to have one single class name for this, among other things it might decrease human mistakes and only needs one class documented at Wikipedia:Catalogue of CSS classes and so on. I'll wait a little before I update Commons.css again. Just in case someone has some comments or advice.

--David Göthberg (talk) 13:30, 1 June 2008 (UTC)

I updated the imbox classes and the mbox-inside class in MediaWiki:Common.css on the evening 1 June. If no more big changes are done to the classes then we can change imbox to use the CSS classes on 2 July.

--David Göthberg (talk) 16:40, 17 June 2008 (UTC)

The 30 days CSS caching time is up. I have now updated {{imbox}} to use the CSS classes in MediaWiki:Common.css. This means imbox now is fully skinnable. And imbox now automatically detects when inside another imbox or any template that is tagged with the "mbox-inside" class and then gets full width instead of 80% width.

I also added the "below" parameter. See documentation and example in the {{imbox}} documentation (the green /doc box on the template page itself).

--David Göthberg (talk) 22:03, 3 July 2008 (UTC)

Rounded edges

Well, now that this "OMG IMBOX IS GFDL! DELETE DELETE!" nonsense has blown over, I could use some help trying to implement our version of Ambox to have rounded edges. Check out my testbed version of Imbox along with my test page (well...actually, the "this is my unique login box" is the one you wanna watch if you try and help me). In order to easily progress from my hacked up Roundbox, mine (which is based off the hardcoded one) has a custom color scheme option (you can specify a custom border/background by not having a type in). Ultimately, I'm going to be redirecting my old template over to Imbox on Wikinews... ViperSnake151 22:23, 4 June 2008 (UTC)

Egad, not that horrible "moz-border" effect with no anti-aliasing and no compatibility with non-Gecko browsers! What's wrong with straight corners? —David Levy 22:30, 4 June 2008 (UTC)

Believe me, that box is, and will remain, resolutely square-edged on IE7, which means that for 70% of all viewers, whether or not the box is supposed to have rounded edges is very much irrelevant. I recommend that, whatever you do with it, you keep checking that it looks OK in IE, because that's your biggest target audience. Happy‑melon 09:54, 5 June 2008 (UTC)

Indeed, the lack of compatibility with non-Gecko-based browsers is a good reason to avoid this nonstandard, experimental code (because relative uniformity across all major browsers is desirable). That it looks very, very ugly in the browsers with which it is compatible is another. —David Levy 10:55, 5 June 2008 (UTC)

I ended up not doing it. ViperSnake151 11:12, 5 June 2008 (UTC)

Missed templates

In rolling out Imbox, it appears several image tags were missed, since I don't know the hooks and variables well, could someone standardize these:

• {{Orphaned fairuse not replaced}}
• {{No source no license}}
• {{No copyright information}}
• {{AutoReplaceable fair use buildings}}
• {{AutoReplaceable fair use people}}
• {{Orphaned fairuse replaced}}
• {{Replaceable fair use 2}}
• {{WP Trains fair use}}

Thanks. MBisanz ^talk 20:40, 5 June 2008 (UTC)

The striked ones already use imbox through the {{Deletable image}} meta-template. — Edokter • Talk • 14:36, 6 June 2008 (UTC)

Also: {{retouched}} -- penubag  (talk) 22:52, 5 June 2008 (UTC)

Tossing in {{Non-commercial from license selector}} MBisanz ^talk 17:19, 6 June 2008 (UTC)

I fixed a couple of these and redirected a couple of the deletion templates (as they are unused and their usage instructions actually had you using another template through subst). There's actually several templates on Kelly's pages that have yet to be converted. - AWeenieMan (talk) 17:50, 6 June 2008 (UTC)

Two more {{Fu-na-in-why}} and {{Fu-re-in-why}}. MBisanz ^talk 07:30, 9 June 2008 (UTC)

And {{Non-free use disputed}}, {{ImageRound-Nosource}}. MBisanz ^talk 09:12, 9 June 2008 (UTC)

{{Hangon}}

The above template is used in both image and article space - needs modification to use the Imbox format in image space. Kelly ^hi! 17:18, 7 June 2008 (UTC)

I made it use {{mbox}} instead of {{ambox}}, which should solve the problem. {{Nihiltres|talk|log}} 18:04, 7 June 2008 (UTC)

Another one

{{No copyright holder}} needs conversion. MBisanz ^talk 22:36, 21 July 2008 (UTC)

It's only transcluded on 3 pages and linked from another 101 pages. So I unprotected it so anyone can help out with it.

--David Göthberg (talk) 00:18, 22 July 2008 (UTC)

Namespace detection

Since this template range is designed for Image pages and Image Talk pages, shouldn't it have somesort of namespace detection so if people try to use it on article talk pages it gives a message something like "Stop: this template is designed for Image and Image talk pages only!". Peachey88 ^{(Talk Page | Contribs)} 07:05, 9 November 2008 (UTC)

It is designed for Image pages, not for Image talk pages. For templates that could be used on both, use {{mbox}}. —Ms2ger (talk) 10:28, 9 November 2008 (UTC)

Ms2ger: Right, the {{imbox}} should only be used on "Image:" pages and not on "Image talk:" pages. For any kind of talk pages we have the {{tmbox}}. And right, if a message box should be used on two or more kinds of pages then you can use the {{mbox}} that automatically changes style depending on namespace.

Peachey88: I have been thinking about adding such a warning message to the imbox and the other mboxes. But I have hesitated for a number of reasons:

1. It adds some code complexity.
2. The style of the boxes already is a signal to most editors for what type of page they are supposed to be used.
3. Until recently I was not sure how I wanted such a message to look, and I have seen that people have been arguing a lot about the design of such messages.
4. When we build message boxes from the imbox we have been using the {{image other}} template to make the boxes not categorise pages when they are shown/discussed on for instance talk pages and "Wikipedia:" pages. While doing that we often add a message saying: "This template should only be used on image pages." If you want to see examples of how that looks see many of the message boxes listed at Wikipedia:Template messages/Image namespace. Adding that message enclosed by the {{image other}} template makes it clearer that the categorising will only be done in the other case, when the template actually is on an image page. See for instance the code of {{Cc-by}} to see what I mean. Of course, that is not enough of a reason to not build the message into the {{imbox}} itself.
5. It makes it harder to test and demonstrate the looks of the imbox, since the message will be visible in the template's documentation and on most test pages. That could of course be fixed by adding a parameter that turns off the message, but that adds even more code complexity. And such a parameter probably has to be described in the documentation too, thus adding documentation complexity too. :((
6. We allow users to use any kind of mbox on their user pages. That is, they have great style-freedom on their user pages. (Which I think is a good thing, since then they can experiment and learn there.) And many users do use for instance the ambox or imbox on their user page. If we add such error messages to the mboxes then the users can only use the rather dull {{ombox}} on their user pages. Unless of course we add a parameter to the boxes to suppress the message, and we document it, and the users actually read that part of the documentation. Or we add even more code complexity by making it so the mboxes do not show the error message when on "User:" and "User talk:" pages...

Anyway, now that we have used such messages for a time I have some conclusions about how I want such a message to look. Remember that the message will be visible on the templates' own pages, and when the templates are legitimately demonstrated in discussions on talk pages and when they are listed for instance at Wikipedia:Template messages/Image namespace. Thus I think the message should not be too strong. Also, too strong messages are rude, and can perhaps even be scary for new users. So I don't want the message to be bold or big or red, or contain words like "error" or "stop". Instead a simple message like this is enough:

This template should only be used on image pages.

Also, I think the message should be placed beneath the message box, not inside it. Because when inside the box it isn't enough visible. If we place it inside then it has to be big and red to be seen, and then it destroys the look of the message box when it is legitimately demonstrated in discussions on talk pages and when listed on "Wikipedia:" pages.

But I still hesitate to add such a message to the {{imbox}} and the other mboxes. Sure, I would like such an error message, but it causes too much problems for too little gain. Instead adding it in the boxes we build causes much less problems, at the same time as we fix the categorising as I described above. (Even though that means that most message boxes probably won't have the error message.) So I think I am somewhere between "weak oppose" and "oppose", provided we make the message the way I explained. If the message is made stronger then I will "strongly oppose" it.

--David Göthberg (talk) 20:32, 9 November 2008 (UTC)

I also dislike the idea of prescribing the use of the mboxes in this fashion. As DG says, it is aggressive and possibly scary to have a warning message appear unexpectedly; the issue of it appearing in places where the imbox is legitimately used outside the Image: namespace makes it not particularly useful. It's such a trivial 'mistake' to fix, and there are such tangible downsides to implementing it, that I don't think it's a good idea. Happy‑melon 17:21, 10 November 2008 (UTC)

Category proposal

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

Editprotected to add alternative attribute

{{editprotect}} Please add blank alt attribute and link attribute, |alt=|link= to all file embedding syntax, such as Image:Imbox speedy deletion.png and Image:Imbox deletion.png, as per WP:ALT# Blank alt text problem for image-disabled browser or screen reader users because those icons are purely decorative. Thx. -- Sameboat - 同舟 (talk) 09:12, 14 April 2010 (UTC)

 Done where possible. Two cases were GPL images, of which i'm not sure what the licensing and attribution requirements are, but i'm guessing they will require the link to the description page. —TheDJ (talk • contribs) 15:42, 14 April 2010 (UTC)

Broom image

{{editprotected}} Would it be possible to swap the png broom image File:Imbox style.png to the svg version File:Broom icon.svg ? A local version of File:Broom icon.svg could always be uploaded (like the current png one) if possible vandalism is an issue. /129.215.149.98 (talk) 13:40, 13 January 2010 (UTC)

What is the advantage of the SVG version? — Martin (MSGJ · talk) 16:46, 13 January 2010 (UTC)

It's perfectly scalable if the image size is changed. But since there's no option to alter the size without redefining the image, I'm not sure that that's an issue. IIRC there's some compatibility reason why we use pngs; maybe background transparency? Happy‑melon 17:04, 13 January 2010 (UTC)

IIRC, the idea was that the hand-tweaked png would be better quality/smaller size. (It's just 63 bytes smaller though, so I don't know if that's a good argument.) —Ms2ger (talk) 17:56, 13 January 2010 (UTC)

The "Technical details" section in the documentation of this template explains it:

The default images for this meta-template are in png format instead of svg format. The main reason is that some older web browsers have trouble with the transparent background that MediaWiki renders for svg images. The png images here have hand optimised transparent background colour so they look good in all browsers.

And the image description page of File:Imbox style.png also explains it:

This PNG version of this image has a special hand optimised transparent background so when used in the English Wikipedia {{imbox}} it looks right, even when viewed with older web browsers. See the talk page for more about that.

I have an old Internet Explorer that I use for compatibility testing, so I see that the PNG looks better. So we should not change to the SVG image, the PNG image is the better choice for the imbox.

--David Göthberg (talk) 20:15, 13 January 2010 (UTC)

• Regarding PNG vs. SVG, I would just like to point out that MediaWiki uses librsvg to convert all SVG images to PNG for displaying for all browsers (including IE6). Librsrvg does a pretty good job of creating transpartent PNGs so I have my doubts there is a significant difference, but I don't have an old browser handy. For those intrested, I have created a side by side comparision at: File talk:Imbox style.png. Cheers --Svgalbertian (talk) 15:30, 4 June 2010 (UTC)

The problem is not our PNGs, it is the capabilities of IE 6. —TheDJ (talk • contribs) 15:48, 4 June 2010 (UTC)

What is the issue that effects IE6? I see absolutly no difference when I render the comparison http://en.wikipedia.org/wiki/File_talk:Imbox_style.png in IE6 using http://ipinfo.info/netrenderer/ --Svgalbertian (talk) 15:57, 4 June 2010 (UTC)

There is a slight difference, the background is rendered as a particular color in IE6, it is not transparent. The modified PNG was tweaked to show the same color as the textbox. The PNG has a background of #FBFBFB. The SVG-rendered-as-PNG has a background of #FFFFFF. That is the only difference. In my opinion, I suggest that we stop explicitly codling the IE6 users. IE6 usage at Wikimedia is down to 7.5% of page loads as of May 2010. [1] --ChrisRuvolo (t) 18:44, 4 June 2010 (UTC)

Thanks Chris that explains it perfectly. I can see why these images were created, but the difference between   and   is so subtle I didn't notice it in IE6. I do not think going forward we need to impose such backwards compatibility, but for these existing images I have no preference.--Svgalbertian (talk) 19:09, 4 June 2010 (UTC)

Change Style Image

{{editprotected}} Could the style image be changed from

[[Image:Imbox style.png|40x40px]]

to

[[Image:Edit-clear.svg|40x40px|link=|alt=]]

so that it matches the image used in {{ambox/core}}, {{cmbox}}, {{tmbox/core}} and {{ombox/core}}. Thanks -- WOSlinker (talk) 07:06, 18 July 2010 (UTC) WOSlinker (talk) 07:06, 18 July 2010 (UTC)

 Done —  Tivedshambo  (t/c) 07:22, 18 July 2010 (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:22, 29 November 2011 (UTC)