Template talk:Fmbox

From Wikipedia, the free encyclopedia

[edit] About this template

I created this template since we now have a number of system messages that have this look. Keeping them up to date and in a unified look will be easier if they all use this meta-template. For instance, up until recently they had slight differences in their margins and padding which looked somewhat messy. Fixing that meant editing a number of MediaWiki messages. (And we haven't even fixed all of them yet.) Also, the system messages need to use full XHTML code since MediaWiki does not parse and convert HTML in system messages the same way as it does for normal pages. Thus having a central meta-template makes it easier to keep things correct and well documented.

Also, we now have the brand new editnotice system. Editnotices are header message boxes that are shown above the edit window when you edit a page. People are now making a lot of editnotices for a lot of pages. Currently there is a new template named {{editnotice}} for making such header message boxes. However I think that box should use the same margins and padding and perhaps even the same colours as the other system messages. Thus I think that box should perhaps in turn call this box.

And this template uses the same parameters as the other mboxes such as {{ambox}} and {{ombox}}, which is an interface that now is well known to many users.

Some of the system messages that could use this template are MediaWiki:Sharedupload, MediaWiki:Sp-contributions-footer, MediaWiki:Sp-contributions-footer-anon and MediaWiki:Anontalkpagetext.

Here is how some of them look when they use the {{fmbox}}:

This is a file from the Wikimedia Commons. The description on its description page there is shown below. Commons is a freely licensed media file repository. You can help.

$1:  Subpages · Edit and action count · Interiot · Edit summary usage · Images uploaded · Articles created · SUL accounts · Global contribs

This is the contributions page for an IP user, identified by the user's numerical IP address. Some IP addresses change periodically, and may be shared by several users. If you are an IP user, you may create an account or log in to avoid future confusion with other IP users. Registering also hides your IP address. [WHOIS · RBLs · Traceroute · Geolocate · Tor check · Rangeblock finder · Global Blocks] · [RIRs: America · Europe · Africa · Asia-Pacific · Latin America/Caribbean]

--David Göthberg (talk) 00:13, 9 September 2008 (UTC)

[edit] The name of this template

This template is for system messages that are either header or footer message boxes. Some users also have similar headers or footers on their user pages. Thus I called this box the "header and footer message box". The "correct" short name for this box then perhaps would be {{hfmbox}} or {{hmbox}}. But both those names are not very readable and hard to pronounce, so I choose the name {{fmbox}} as in "footer message box" or if you will "footer and header message box". Remember, many languages don't even have an "h" thus people from those parts of the world can not even pronounce an "h". And the boxes we make here at the English Wikipedia tend to be transwikied to many other languages.

I would like to hear any points of view on the name of this template.

--David Göthberg (talk) 00:13, 9 September 2008 (UTC)

When choosing the name for {{ombox}}, we narrowly avoided the "hour-format" am–pm pun. The radio waves got us this time, though. :-D

In any case, I find the template a good idea and have no problem with the name, which is indeed intuitive and easily pronounceable. Waltham, The Duke of 16:57, 9 September 2008 (UTC)

Haha, yeah the radio waves got us this time. And thanks for your comment.

--David Göthberg (talk) 16:07, 1 October 2008 (UTC)

[edit] Transparent type?

We are still discussing the colours for the editnotices, but if we decide they should be transparent then I am thinking we should perhaps add a "type" parameter to this template so it easily can be used for editnotices. Just like the other mboxes do have different types that produce different colours. I am thinking of naming it like this:

{{fmbox
| type = system / editnotice
}}

That is, "type=editnotice" means transparent and "type=system" means the default system message colours. This is a slight breach with the tradition for the other mboxes to name the default style "type=notice". But I think in this case "type=system" is probably more clear. And besides, if anyone uses "type=notice" out of habit then the template will automatically fall back to the default "system" colours, which is the colours the user wanted.

--David Göthberg (talk) 11:29, 13 September 2008 (UTC)

Sounds good. Waltham, The Duke of 21:22, 13 September 2008 (UTC)

I myself have now become used to the transparent background for the editnotices. So I added the "type=editnotice" code to the fmbox. This means I think this template is ready to deploy. And people have anyway already started using it.

--David Göthberg (talk) 16:12, 1 October 2008 (UTC)

[edit] Add "id" parameter

I just looked at the MediaWiki messages that use the {{fmbox}}. That reminded me that fmbox needs an "id" parameter that can take a CSS id. Since CSS ids are often used in MediaWiki messages to tag them with the message's own name, to make it easy to detect the presence of the message from javascript. Since for javascript it is more efficient and simpler to detect a CSS id than to detect a CSS class. (But to allow individual skinning of a box it is better to use the "class" parameter.)

Since we refused to add such "id" and "class" parameters to the other mboxes I wanted to explain here before I do the addition.

--David Göthberg (talk) 15:46, 25 October 2008 (UTC)

I see that Happy‑melon agreed with me since he went ahead and added the "id" parameter to the template. And Happy‑melon: I don't mind at all that you "stole my edit".

--David Göthberg (talk) 19:43, 25 October 2008 (UTC)

[edit] New type?

This discussion is about adding an extra style to the {{fmbox}}, so it can be used for messages like MediaWiki:Editingold and MediaWiki:Protectedpagewarning. This also means we are standardising the style for such messages. --David Göthberg (talk) 15:12, 25 October 2008 (UTC)

Following on from this discussion, I think we should add a 'serious' type for important messages such as MediaWiki:Editingold and MediaWiki:Revision-info. These should use a standardised style to set a unified background colour and border. I recommend background:#FEE; border:2px solid #b22222;, the same styles as for the mbox 'speedy' series. However since this box doesn't seem to be following the conventions of the other xmbox type names, I don't feel any need to call the type 'speedy', etc. Thoughts? Happy‑melon 08:36, 25 October 2008 (UTC)

Here is a longer list of such warning messages: MediaWiki:Revision-info, MediaWiki:Revision-info-current, MediaWiki:Editingold, MediaWiki:Cascadeprotectedwarning and MediaWiki:Protectedpagewarning. A closely related message is MediaWiki:Semiprotectedpagewarning.

Considering what they mean and their text content I think we can call it "type=warning".

For comparison with my examples below, here is Happy-melon's example in full {{fmbox}} size:

To me a pink background with red border means "speedy delete". And it seems the current standard is to use a pink background and a thin border for the warning notices. So I prefer a simple grey border. Here are some examples, they all use the current default ombox/fmbox "border: 1px solid #aaa;":

Example 2 is too dark, it makes it hard to read the text. To me example 3 and 4 look almost the same. But I prefer example 4 since it is slightly lighter and it is consistent with the nuance we did choose for the cmboxes. I think example 5 becomes too light when it only has the thin grey border.

Another option might be to use the {{ombox}} "delete" style, since the fmbox to me kind of just is a 100% wide ombox. But I guess most people want the warning type to be more visible. Anyway, here is the ombox "delete" style for comparison:

I prefer examples 4 and 7.

--David Göthberg (talk) 11:30, 25 October 2008 (UTC)

I also like example 4 reasonably well, but I suspect it might not be eye-catching enough. How about a 1px red border?

I think this sets it apart from the normal editnotice styles without it being too garish, and it's also subtly different from the speedy type.  ?? Happy‑melon 13:16, 25 October 2008 (UTC)

Happy-melon: I find the red border in your example 8 too strong. If you want a coloured border then perhaps we can use something like the softer grey-red border used by some of the current warning notices? Like this:

I don't know if I prefer example 4 or 9.

--David Göthberg (talk) 14:09, 25 October 2008 (UTC)

Ooooh, me likes... I like the idea of a softer-than-speedy border; I think that's perhaps a little too soft. How about the middle position of those:

Nice compromise? Happy‑melon 14:35, 25 October 2008 (UTC)

Hmm, tough choice. I think example 10 is slightly too sharp. I still prefer examples 4 and 9. But let's wait a day and see what other editors think. I have announced this discussion in several places, including at the Wikipedia:Village pump (proposals).

And what about the name for this new type? You seem to suggest "type=serious" and I suggest "type=warning". As soon as we have agreed on the type name we can implement and start to use one of the styles above, even if we haven't reached a full consensus about the style. (Since most of the warning messages already use something similar to the styles above.)

--David Göthberg (talk) 15:19, 25 October 2008 (UTC)

|type=warning sounds good to me; I think the conflict with the deprecated 'serious' ambox type would be unhelpful. Happy‑melon 09:44, 26 October 2008 (UTC)

I saw the message on WP:VPR and I think I like Example 9 the best, although I have to look really close to see a difference between it and Example 10. -- Imperator3733 (talk) 06:39, 26 October 2008 (UTC)

I'm not a big fan of the changes: I've thought that the current version is pretty nice:

This version has the advantage of minimal change necessary, and incorporates both a red border (though less saturated than the others) and a pink background that shows up well. A null visible change for most pages is also less likely to provoke complaints. I agree that the name "warning" for the type is most appropriate.

Something that we may also want to consider, however, is that certain warnings are low-priority: should we be handling those separately? In particular, I think MediaWiki:Semiprotectedpagewarning might be a bit too bright if in a pink "warning" style, as the only ones who will see it are those who can edit semi-protected pages, where it should not be a big deal to make changes. I can understand how MediaWiki:Protectedpagewarning, on the other hand, should use a more drastic colour.

Another consideration, though it does go against my personal preference somewhat, is that we may want to match our warning colour to the new pink colour applied to edit-box backgrounds via MediaWiki:Sysop.css: specifically, sysops get .mw-textarea-protected {background:#FFEEEE;} applied, and that #FFEEEE may be something to consider. It might, however, be acceptable to make that an exception as the edit box colouring has to be particularly light for usability purposes. I myself override this setting anyway. {{Nihiltres|talk|log}} 18:49, 26 October 2008 (UTC)

This discussion in fact followed from the pink textarea discussion, as we realised that this was a good opportunity to improve consistency for warnings of this type. I don't think that less-is-best applies very strongly in this case, as these warnings are intermittent and none of them are reader-facing. I would be surprised if anyone even notices that they've been changed, let alone complains about it. The most important thing is to produce a usable and versatile scheme, which is why I think your suggestion is far too dark; as you say, it would not be appropriate to colour MediaWiki:Semiprotectedpagewarning in this colourscheme; I'd be rather more keen to have it in the colours of #9 or #10 above. A further advantage of using a lighter colourscheme is, as you note, that it can be synchronised with the background for the protected editscreens. Example 9 above actually uses the same colour background as the editscreen (now that I have restored the original colours FT2 implemented), which is an advantage. As you note, this precludes dark background colours like the one you propose. All in all, I don't think a dark background is a very versatile option. Happy‑melon 20:28, 26 October 2008 (UTC)

Nihiltres: Right, MediaWiki:Semiprotectedpagewarning is currently transparent like a plain editnotice. It is really just an informative notice or perhaps a "minor warning", so it should not be pink. But it could perhaps be yellow like the minor warning colour we use for other mboxes. But I think it is simpler to just keep it transparent. However, I took a look in Special:AllMessages (very heavy page to load): There are several messages I would call "minor warnings". So in the end we might need to add the yellow style anyway. But for now I think we should try to keep it simple and only use pink and transparent.

Regarding your example 11: As I stated before, I find that one too dark, which makes the text harder to read. And note that some warnings are currently using the much lighter pink as in example 3. The reason I instead suggested the very similar colour in example 4 is that that is the pink used in {{cmbox}}. The colours for the cmboxes were heavily discussed, tested and okayed by many users. So if we choose that colour and then if we decide to add the yellow "minor warning" colour, or even worse decide we need some of the other colours too, then we can reuse the cmbox colours as is, since those matches well with the pink in example 4, 8, 9 and 10.

Nihiltres and Happy-melon: Regarding synchronising the colour of these warning boxes with the pink edit window we get on protected pages: The colour used for the edit window was #FEE (same thing as #FFEEEE) and is the colour used in example 5. But now the edit window colour has been changed to #FFDBDB, as in examples 4, 8, 9 and 10. However, I don't think those colours need or even should be the same. Since the edit window should have a very light pink so it is easy to read and edit the code in it, while the warning box can have a more intense pink. Thus I think the edit window now is far too dark, while #FFDBDB (as in examples 4, 8, 9 and 10) is appropriate for the warning boxes.

--David Göthberg (talk) 01:56, 27 October 2008 (UTC)

FT2's original colour for the edit window was #FFD8D8. When I transferred the code to MediaWiki:sysop.css, I took the liberty of changing it to #FEE. So by changing it to #FFDBDB, I was essentially just restoring the original colour; the difference between #FFD8D8 and #FFDBDB is completely indistinguishable on my screen at least. I think that MediaWiki:Semiprotectedpagewarning definitely counts as a 'warning', and hence should have a pink colouring. Remember for non-admins, this is the only warning they can actually edit through, so there is no confusion with the warnings for protected pages. And for sysops, the similar warning for fully-protected pages is supplemented by the tinted edit window. So I think that the semi-protected warning should be pink, however I agree that it should not be as vibrant and overt as example 11. This is what I was getting at when I talked about versatility earlier. A more subtle colourscheme can be used in more places, reducing the need to use an extensive scheme. I think we can get away just fine with a transparent 'normal' scheme and a single pink 'warning' scheme, as long as the pink is still a reasonably subtle colour. Like examples 9 and 10 above.

Regarding the editwindow colour, I don't think that there's a problem with the slightly darker colour. I know that's an opinion that you don't share, but given the ease with which it can be overridden, if the majority of admins don't have a problem with the textarea being the same colour as the warning messages, then it would be sensible for the textarea to be the same colour as the warning messages. Since that way the whole edit window functions as a 'warning box'.

On that note, it seems clear that the type should be called 'warning', so we can certainly start implementing this with hardcoded styles. Happy‑melon 08:53, 27 October 2008 (UTC)

[edit] New type, section break 1

I have added the "type=warning" to the {{fmbox}} code and documentation. So people can test it and we can perhaps even start to deploy it. Changing the type name after people have started to use the type is messy, but changing the colour is easy. But the colours should of course continue to be discussed here until we get a proper consensus.

I see that the devs now have added a blue border around the protected page warning. If find that good since it connects together the warning notice and the protection log item. So here are the main colour suggestions inside such a blue border:

When there is the blue border I find example 4 to be too bland. I find example 9 to be just right, but example 10 is fairly okay too. But example 11 is much too intense and drowns out everything else around it.

--David Göthberg (talk) 17:25, 28 October 2008 (UTC)

Inside the blue box, I think I still like example 10 the best, although there's really very little in it between 9 and 10. Happy‑melon 19:53, 28 October 2008 (UTC)

Now I'm sort of liking example 10 the best. Example 11 is too dark and example 4 has too light of a border. The border on example 9 is a bit light with the blue border. -- Imperator3733 (talk) 02:41, 29 October 2008 (UTC)

Heh, the whole blue-box issue makes me wonder if we should appeal to the devs to use Common.css to just change the blue box style: that is, I think it might be preferable to remove the boxing around the inner note of protection, along the lines of the following:

Example 12:

Would that be a good idea? {{Nihiltres|talk|log}} 04:39, 29 October 2008 (UTC)

Nihiltres: Yes, you might be on to something. Here is an example using the actual paddings that we will get if we only set the colours. And I added a border-bottom to the inner {{fmbox}} warning message part, so it kind of becomes a horizontal ruler:

Example 13:

And since we seem split between the border colours from example 9 and 10, I here used a colour in between them for the borders: #BB7070.

The drawback with the examples 12 and 13 above is that it will involve code on several different pages to get that effect. But it does look nice.

--David Göthberg (talk) 16:24, 29 October 2008 (UTC)

Example 13 is just about what I was thinking. It would involve spreading about our efforts somewhat, but I think that the unity thereby produced would be worth the trouble. {{Nihiltres|talk|log}} 17:03, 29 October 2008 (UTC)

Oooh, very nice! I have been campaigning to try and get these messages united with the extra content that goes with them - see for instance bug 16111http://bugzilla.wikimedia.org/show_bug.cgi?id=16111. This visual unification goes a long way to achieving that. For that reason I don't like the horizontal line through the middle of the box; I think wrapping the whole thing as if it were one object is much nicer. Happy‑melon 22:11, 29 October 2008 (UTC)

I think it looks better with the horizontal ruler. But I just realised that example 12 without the ruler means much simpler code. It means the MediaWiki:Protectedpagewarning and MediaWiki:Semiprotectedpagewarning pages need no style code or box code at all, only plain text. All the style code would go into one single class "mw-warning-with-logexcerpt" in MediaWiki:Common.css. So I can live without the ruler.

Does everyone accept the new compromise border colour #BB7070 that I used in example 13 above?

--David Göthberg (talk) 23:21, 29 October 2008 (UTC)

I'm working on a MediaWiki codechange that would make the log entries parameters to the messages, so they can be styled individually. I've probably screwed up loads of other things in the process (I don't have a running copy of MediaWiki to test changes on!) so don't hold your breath too much, but if it goes through it'll bring us back to wrapping the whole message in an fmbox. Which is kind of the exact opposite of what's currently the easiest way :D Happy‑melon 23:27, 29 October 2008 (UTC)

 #BB7070 looks fine, I can live with that :). I was going to suggest, even before Happy-melon suggested that code unification was on the way, that given the simplification issues, it would probably be easier to not use the horizontal bar, or hey, we can always use <hr style="color:#BB7070; background-color:#BB7070;"> if we really want an hr. I don't really mind either way; without might be simpler, though. {{Nihiltres|talk|log}} 00:05, 30 October 2008 (UTC)

Since we can not know when Happy-melon gets his extension to the warning messages accepted I will deploy this style. Apart from MediaWiki:Protectedpagewarning and MediaWiki:Semiprotectedpagewarning, I have found two more messages that has log excerpts and will be using this style: MediaWiki:Recreate-deleted-warn and MediaWiki:Upload-wasdeleted.

--David Göthberg (talk) 05:21, 30 October 2008 (UTC)

Y Done - I have added the CSS code for this in MediaWiki:Common.css. And it looks very nice. See for instance this upload form for an image that was once deleted. Or try to create its description page, and you get the pink warning with a log excerpt. You may need to bypass your browser cache to see the new style.

--David Göthberg (talk) 06:51, 30 October 2008 (UTC)

Looking good! I've updated MediaWiki:Protectedpagewarning to reflect the new style. {{Nihiltres|talk|log}} 14:31, 30 October 2008 (UTC)

Hmn... try editing the main page. Yuck! I think that's just caused by the CSS hacks we use to tweak the rendering of the main page tho. Happy‑melon 14:44, 30 October 2008 (UTC)

I see that Nihiltres added an unstyled div around two of the four messages, with a CSS id named after the message. That's good since it enables user styling and allows javascript to detect the presence of the message on a page. So I added such "name tags" around the other two messages too. These are the messages involved: MediaWiki:Protectedpagewarning, MediaWiki:Semiprotectedpagewarning, MediaWiki:Recreate-deleted-warn and MediaWiki:Upload-wasdeleted.

Happy-melon: Haha, yeah that looks weird when editing the main page. It seems to have something to do with that the main page has no title and special padding. But it must have looked the same with the original blue border. And it probably only affects the main page. So I don't think we should add extra code just for that.

This reminds me that we probably should add the proper fmbox margins to the "div.mw-warning-with-logexcerpt" class. I just tested that in my user space and it currently causes no visible difference on any page I know of, not even when editing the main page. But I think we should add it anyway since a box should not rely on that all surrounding items have proper margins.

Everyone: Dinoguy1000 expressed over at MediaWiki talk:Common.css#Warning box with log excerpt that he "rather see the log entries visually offset from the rest of the message". Nihiltres and I wanted a horizontal ruler, and only Happy-melon objected to that. I take it that means 3 to 1 so far, so I added a hr tag to the messages. I added a class name to the hr tag so it is easy to style and hide. And I put the hr tag inside the surrounding div tag, so the hr tag can be individually styled for each message.

I tested to use a border-bottom on the surrounding div tag instead of using the hr tag. But that caused more complex code (even needed some padding adjustments) and was less clear.

--David Göthberg (talk) 15:23, 30 October 2008 (UTC)

I actually quite like the new line; it's the way it doesn't run so close to the edge of the box; it's more obviously just a line rather than two boxes stuck together... Happy‑melon 17:54, 30 October 2008 (UTC)

I like it as well, it looks quite clean, and the log items are now visually distinct, but not separate, from the warnings, so that rather than looking like two elements shoved together, as Happy-Melon also mentioned. And I won't have to code up a hack in my stylesheet, either, so it's all good. =) —Dinoguy1000 18:16, 30 October 2008 (UTC)

Yay! We are unanimous! Even though we are only four editors, since we are unanimous it is very likely that the majority of users out there will like it. And not only do we all like it, we are liking the version with the second simplest code. Thanks Nihiltres for coming up with the essential part of this style. (Me ponders if he should reveal to Happy-Melon that the deployed horizontal ruler still goes as close to the box border as in example 13 above. It is only the text that now has less padding. But me decides to keep that a secret, lest Happy-Melon will change his mind...)

--David Göthberg (talk) 21:06, 30 October 2008 (UTC)

Hehehe, colored text does no good if you read diffs... ^_^ —Dinoguy1000 21:39, 30 October 2008 (UTC)

[edit] Div based warning messages

I have taken a closer look at the warning messages that remains to be updated to use the fmbox warning style: MediaWiki:Revision-info, MediaWiki:Revision-info-current and MediaWiki:Editingold. I have come to some slightly unconventional conclusions how to handle them, so I want to explain here before I go ahead.

The first two of them probably can not call the {{fmbox}} since it seems from their code that they are the kind of messages that MediaWiki doesn't parse properly. And all three of them currently use a <div> instead of a table to create their border. Since they are just simple 100% wide boxes (thus no box flow problems) and have no images (thus no padding problems), then they don't really need a table, they work just as well with a simple div.

And we have already added all the colours and padding needed to the "mw-warning-with-logexcerpt" class in MediaWiki:Common.css to accommodate the div based MediaWiki:Protectedpagewarning, MediaWiki:Semiprotectedpagewarning, MediaWiki:Recreate-deleted-warn and MediaWiki:Upload-wasdeleted. So I figured out that all we have to do is to add for instance "div.fmbox-warning," to the existing declaration of "mw-warning-with-logexcerpt", to turn it into this:

/* Pink fmbox warning style for div based warning notices. */
div.fmbox-warning,
div.mw-warning-with-logexcerpt {
    clear: both;
    margin: 0.2em 0;
    border: 1px solid #BB7070;
    background: #FFDBDB;
    padding: 0.25em 0.9em;
}

That I prefix the "fmbox-warning" class name with "div" means that the declaration above will not interfere with the usage of the "table.fmbox-warning" class in tables. Since the div and table based warnings have the same looks and purpose I think we should use the same class name, even though that is a bit unconventional.

Then we can simply add class="fmbox-warning" to the div tags in MediaWiki:Revision-info, MediaWiki:Revision-info-current and MediaWiki:Editingold.

This only leaves the MediaWiki:Cascadeprotectedwarning which currently uses {{fmbox|type=warning}}. But like the rest of them we can just as well let that one use <div class="fmbox-warning"> instead. This perhaps means that we don't need the "type=warning" in the fmbox anymore, but let's leave the warning type in fmbox for now.

There are other ways to do this, but this seems to be the simplest and most efficient way to do it.

--David Göthberg (talk) 01:29, 2 November 2008 (UTC)

[edit] Sister project link templates

Should these templates be covered by the {{fmbox}}? They look pretty much the same and are placed at the bottom of articles. The smaller size could be achieved with something similar to {{tmbox}}'s small parameter. --Blooper (Talk) 21:25, 30 October 2008 (UTC)

Oh dear, thanks for the reminder. The amount of box flow problems they have caused... Yeah, it is probably time to fix them.

But the sister project boxes should definitely not use the {{fmbox}}, and we should not add code to the fmbox to handle them. The fmbox is mostly meant for system messages and editnotices that go outside the article area, so it has special code concerns like that it must be fully XHTML compliant instead of wikimarkup compliant. And the fmbox is not built to handle anything but 100% width. If you set it to other widths it breaks in some browsers. And I don't want to update the fmbox to handle other widths since that makes it more complex and it adds an extra 1px padding on the left or right side, that sometimes can be fairly visible.

Instead if you want a small box with those colours them we already have the {{ombox|small=yes}}. Yes, the {{ombox}} already has the code for that! Of course, we must first check if the sister project boxes have some special needs. If so, then we can perhaps add support for those needs in the ombox. This might end up being a little odd, since that would mean we would be using the "other pages message box meta-template" (ombox) in article space. But if the ombox already has the styles and code for it, then why should we upgrade the {{ambox}} to do it? Besides, some sister project boxes are used on category and other pages.

--David Göthberg (talk) 23:16, 30 October 2008 (UTC)

Ok, I didn't think that the {{fmbox}} would be the best for those. Now that you pointed that out, {{ombox}} does look like it's better for those. I just figured that since those usually appear at the bottom of the page that they would be considered footer boxes, and therefore fall under {{fmbox}}. I don't think it would be much of an issue to use omboxes on articles for the sister project templates. They aren't about content issues (which amboxes cover) and there is no need for a completely new template if omboxes already support their look.

That also brings up another thing. To prevent confusion (like what happened to me), wouldn't it be better to call fmboxes System Message Boxes, or smboxes? Like you said, they are specially coded to mostly be used on system messages and editnotices. It wouldn't really be appropriate to use them, for example, as part of the footer in an article because of their special coding. If the name were to change, now would be the best time to do it before fmboxes are rolled out. --Blooper (Talk) 00:23, 31 October 2008 (UTC)

From a code technical point of view the fmbox also works inside pages. And is actually meant to sometimes be used inside pages, in the rare occasion you need a 100% wide box. But we don't allow 100% wide boxes in articles. But users often have 100% wide boxes at the top of their user pages, and then they can use the fmbox.

And right, the fmbox is meant to be used for many of the light-grey system messages, the transparent user editnotices, the transparent official editnotices such as "This is a talk page...", and the pink system warning notices. Basically any box that is 100% wide. We can add more colour styles to the fmbox if the need arise.

Yeah, naming is always tricky. The 100% wide boxes usually are the topmost and lowermost boxes on a page, so I opted to call it the "footer and header message box". I put the word "footer" first since hmbox is not as readable and pronounceable as fmbox. To call it smbox as in "system message box" would be fairly correct too. But to me would feel a bit odd when it is used for user editnotices and for header and footer boxes on user pages. So I feel fmbox is the better name.

--David Göthberg (talk) 02:34, 31 October 2008 (UTC)

Don't forget DG's evil plan to take over wikipedia using a new meta-template for stub messages... :D Happy‑melon 08:55, 31 October 2008 (UTC)

Ah yes, I forgot about the inevitable evil stub meta-template. I rest my case then. --Blooper (Talk) 12:50, 31 October 2008 (UTC)

I'd actually oppose even using the ombox for those boxes, for one reason: semantic purity. One of the best parts of our regime of standardization is that each style is well-defined. All amboxes are for temporary messages on articles, whether for cleanup, deletion warnings, dispute tags, or mere notices. All tmboxes are designed for messages on talk pages, and all cmboxes are designed for messages on category pages. If we start using omboxes, which are for "other" namespaces, in the main namespace, we lose that semantic benefit. I'd advocate instead making a new meta-template for those boxes on a lower level than the main message boxes, particularly as those boxes aren't the typical messages that the *mbox series of meta-templates is meant to handle. {{Nihiltres|talk|log}} 15:13, 31 October 2008 (UTC)

Yes, that's true. I suppose we shouldn't mix around the mboxes if we can avoid it. I've also found that the ombox isn't exactly the same style as the link templates (although I think the vertically centered text without much spacing between the lines looks a little better). You can see a little example I made in my sandbox. --Blooper (Talk) 15:21, 31 October 2008 (UTC)

Template:Sister and Template:Sister project are both available; I agree with Nihiltres that a separate meta-template would be helpful. Since the opportunity for reuse and derivations are minimal, I don't think CSS would be particularly useful; hardcoded styles in the meta-template will be sufficient. Which name do we prefer? Once we've decided on that, we can spin out yet another template standardisation drive... we do seem to be forming a bit of a template cabal here, but all is well until the lynch mob approaches...! :D Happy‑melon 16:19, 31 October 2008 (UTC)

The latter sounds better. Long live the Cabal! :p {{Nihiltres|talk|log}} 16:44, 31 October 2008 (UTC)

As a side note, it's probably a poor sort of cabal that's public, open to all new members, and only controls things that most people don't worry about. That being said, we can all enjoy a few evil laughs. :D {{Nihiltres|talk|log}} 16:44, 31 October 2008 (UTC)

Cool, can I join? ^_^ —Dinoguy1000 17:11, 31 October 2008 (UTC)

Dinoguy1000: You already have joined. And now you can never leave. Mwahahaha!

Happy-melon: Hush, don't tell them about my cunning plan (well, it was a question from Chris Cunningham that started it) that we discussed over at Template talk:Mbox#Now we have a dmbox too. I have not yet investigated the matter further, so I don't know if the stub meta-template should be called {{smbox}} or {{stub-meta}}, or something else. But it has a very low priority in my to-do list, since the current stub templates aren't broken. While the sister project boxes do have some box flow problems, so they more need our attention.

Nihiltres: You have a point there. We need to think this over carefully.

Blooper: Nice examples in your sandbox.

Happy-melon: Yes, it seems the sister project boxes perhaps don't need CSS code in MediaWiki:Common.css, since they only have one style and as far as I know they are not being styled in the other skins. So if we do as we have learnt now to just add the class names in the template code, together with hard-coded styles, then users can simply use the "!important" keyword to style the boxes if they want. As I see it we only need to move styles to MediaWiki:Common.css when a box should be styled in other skins, or if we need to use the classes to hand-build special boxes instead of calling the meta-template.

But if a box uses the same padding as the other mboxes, for its image and text cells, then I do like if it is named "(something)mbox", so it can reuse the "mbox-image" and "mbox-text" classes in a logical looking way. Or at least that its classes are named in that way. Since that saves a lot of code in MediaWiki:Common.css if/when the box needs its styles moved to the CSS files.

Nihiltres: Right, one option could be to make a separate "sister project box meta-template", so it looks like we are not breaching our praxis. But internally it could perhaps use the ombox small classes. Of course, anyone looking inside the meta-template code might become namespace confused. But I am just brainstorming here.

Note that the portal templates have a similar look, and currently often use the meta-template {{portal}}. But I have to investigate this more before I have a point of view on if we should make a meta-template that supports both portal boxes and sister project boxes.

--David Göthberg (talk) 17:34, 31 October 2008 (UTC)

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

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

Blooper: I copied your last two comments above, to Template talk:Mbox#Now we have a dmbox too, and responded there. I hope you don't mind? Since your comment is more a part of the "stub template discussion", than this discussion.

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

Yes, that's fine. I suppose I should have just gone right to that discussion. --Blooper (Talk) 17:46, 3 November 2008 (UTC)

[edit] Merging "tmbox-small" and "ombox-small"

The comment below was moved here from my talk page, since it is kind of a continuation of the discussion above. --David Göthberg (talk) 14:07, 27 November 2008 (UTC)

I notice that these two declarations in MediaWiki:Common.css are in fact identical. Should we perhaps unify them? The background is that I am considering how to update templates like {{commons}}, which currently use a rather awkward set of nested divs. I was tempted to use the ombox-small classes as the appearance is very similar but I would prefer to avoid using styles in the mainspace that are really intended for use outside. However, the "ombox-small" class declaration actually only contains positioning information, so if we renamed this to "mbox-small" it becomes namespace-independent and hence acceptable to use in any namespace for a clean right-floating small box, to be manually styled as necessary. I don't think we need feel obliged to implement the complicated |small=yes functionality in other mbox templates as a result. Thoughts?

Also, although I do have reservations, do you think a symmetrical "mbox-small-left" style would be a good idea? Happy‑melon 11:40, 27 November 2008 (UTC)

End, comment moved here from my talk page. --David Göthberg (talk) 14:07, 27 November 2008 (UTC)

1: Short answer: Yes, I think we should merge the "ombox-small" and "tmbox-small" classes into a single class named "mbox-small".

2: Right, we should not and we will not be obliged to add the small functionality to the other mboxes just because we give the class for it a generic name.

3: I have nothing against an "mbox-small-left" class. But I don't think we should implement it until there is a need for it. And currently I am not aware of any need for it. The only related case I can think of is the left floating variants of the {{shortcut}} boxes, but those have special needs, so they would not have any use of a standard "mbox-small-left" class anyway. The same is true for the right floating {{shortcut}} boxes, they have no use of the "mbox-small" class. I checked right now by comparing their code (which I myself optimised some time ago) with the "mbox-small" class.

Long answer for point 1 above:

Yes, the declarations for ombox-small and tmbox-small in MediaWiki:Common.css are identical, and most likely will remain identical for a long time to come. And to merge them into one declaration would save some code in MediaWiki:Common.css, which would be a good thing. The question is if we should merge them by declaring them like this:

Example 1:

table.tmbox-small,
table.ombox-small {    /* For the "small=yes" option */
    clear: right;
    float: right;
    margin: 4px 0 4px 1em;
    width: 238px;
    font-size: 88%;
    line-height: 1.25em;
}

Or like this:

Example 2:

table.mbox-small {    /* For the "small=yes" option */
    clear: right;
    float: right;
    margin: 4px 0 4px 1em;
    width: 238px;
    font-size: 88%;
    line-height: 1.25em;
}

There are some minor reasons why I have not bothered to merge them yet:

• Merging them like in example 2 above, to the single "mbox-small" class, is the most efficient and flexible alternative. But just like you also seem to think, I think it will make it tempting for people to use the small style in other namespaces.
• The small class have to be placed after the table.ombox{} and table.tmbox{} declarations in MediaWiki:Common.css, since the small class overrides them. (Unless we increase their specificity, which usually is messy and causes problems in the future.) But if they have the name "mbox-small" it will be tempting for less CSS skilled admins to "clean up" the code in MediaWiki:Common.css by moving the "mbox-small" class to the top section where the other "mbox-*" classes are, which will break things. And I think it will be hard for those admins to figure out why things broke.
• Merging them like in example 1 is also weird, since as I said we have to place the class after all the other ombox/tmbox/*mbox classes, and then the tmbox-small/ombox-small declaration will not be inside the ombox or tmbox declarations. And that might be confusing and in the worst case might make it so some less CSS skilled admin moves the declaration into the tmbox or ombox section, again breaking things in a way that will be hard for them to figure out why it broke.

Of course, my concerns above are just very minor concerns, they were only enough to make me put off the merging for some later time. (I usually put off things for later if I have some doubts and it is no hurry, since sometimes I then realise worse problems or come up with a much better solution.) If we put a decent comment on top of the declaration like "Must be placed AFTER all the other tmbox/ombox/*mbox declarations", then we should probably be okay even if you and I are not around here watching things anymore. So I think we can disregard my concerns, since I now have had enough time to think about this. And as you point out, you now have a legitimate use for the "mbox-small" class for the sister project boxes like {{commons}}.

4: But you still would need a class similar to the table.ombox{} declaration, since the "mbox-small" class does not contain all things a box needs. But as I wrote in the previous section above: "It seems the sister project boxes perhaps don't need CSS code in MediaWiki:Common.css, since they only have one style and as far as I know they are not being styled in the other skins. So if we do as we have learnt now to just add the class names in the template code, together with hard-coded styles, then users can simply use the "!important" keyword to style the boxes if they want."

So, even if you hard code the styles, you should put class names in there too so the styles can be overridden. So what name are you going to give the main "sister project box" / "commons box" class? Perhaps "spbox"?

--David Göthberg (talk) 14:09, 27 November 2008 (UTC)

Thanks for your comment. I'm glad I asked you rather than just doing it, because I would have fallen foul of exactly the trap you describe and put them next to the "mbox-image", "mbox-text" declarations, which is above the "tmbox"/"ombox" styles. So that would have broken. However, from what I know of CSS specificity, wouldn't something as simple as making the declaration .mediawiki table.tmbox-small {...} be sufficient to make the -small declaration 'win' over "tmbox"/"ombox"? The "mediawiki" class is present in all namespaces, skins, and installations, so should be fully portable to all sites using standard MediaWiki, and of course, it's not possible to put tables outside the "mediawiki" declaration on each page, since it's applied to the HTML body. That would enable us to place it wherever we like in the Common.css without its location being important. Am I incorrect in that thought?

I had actually completely forgotten about this discussion, and had reinvented this particular wheel when looking at the code for {{commons}}. As the "mbox-small" declaration posesses only positioning attributes, you're right, DG, that the 'presentation' attributes (background, border, text styles, etc) would have to be applied separately. "sisterproject" is actually already styled in Common.css, so we could maybe justify expanding that (it would only be a couple of lines) but a meta-template would probably be more defensible, as noted above. The important point from this particular thread is that having a generic class for "make a small right-floating box that doesn't make a mess of everything" would have innumerable uses in all namespaces.

In terms of technical implementation, for continuity we need a 30-day period with all three declarations, so I would place code like this:

.mediawiki table.tmbox-small,
.mediawiki table.ombox-small,
.mediawiki table.mbox-small {    /* For the "small=yes" option (also used elsewhere).   */
    clear: right;                /* The "mediawiki" class ensures that this declaration */
    float: right;                /* overrides styles set in "tmbox"/"ombox"/etc below   */
    margin: 4px 0 4px 1em;
    width: 238px;
    font-size: 88%;
    line-height: 1.25em;
}

below the "mbox-imageright" declaration, simmer for 30 days, then convert the templates to use "mbox-small" and remove the first two lines. We should avoid making new instances of the "ombox-small" and "tmbox-small" classes in the meantime, naturally, or we'll just have to chase them out again. Happy‑melon 17:10, 27 November 2008 (UTC)

I've now done this; we can start deprecating the "ombox-small"/"tmbox-small" classes in the new year. Happy‑melon 21:08, 1 December 2008 (UTC)