Template talk:Fmbox

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

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

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)

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)

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)

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)

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:

• 08:16, 27 September 2008 Davidgothberg (Talk | contribs | block) protected Template:Fmbox [edit=sysop] (indefinite) [move=sysop] (indefinite) (This box...) (hist) (Change)

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:

• 08:16, 27 September 2008 Davidgothberg (Talk | contribs | block) protected Template:Fmbox [edit=sysop] (indefinite) [move=sysop] (indefinite) (This box...) (hist) (Change)

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)

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: <source lang="CSS"> /* 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;

} </source>

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)

The following question was moved here from David's talk page:

fmbox-warning in Common.css

Re this, I'm a little confused. Why would we have divs with the fmbox-warning class? We have messages created using {{fmbox}}, which uses a table, and we have messages that are already wrapped inside divs, which we explicitly name and style. I'm not aware of any messages that are wrapped in divs that we can assign classes to, without being able to use fmbox; can you give examples? Even if div.fmbox-warning is needed, is there any reason not to have table.fmbox-warning too? I'm not really sure why all the mbox styles have the table. prefix anyway: is there a reason for that high specificity? Happy‑melon 13:43, 8 April 2009 (UTC)

1: I did use "div.fmbox-warning" in several of those messages for quite some time, but then another admin changed that to {{fmbox}} instead. I didn't revert him immediately since I had to ponder which was best. I was actually already using {{fmbox}} in two of the messages.

However, I now think it is slightly better to use "div.fmbox-warning" for these reasons:

• It works just as well, since those messages are 100% wide and have no images.
• It is more efficient (less rendering work both for the servers and the web browsers).
• It is more robust since it means directly using a single class in MediaWiki:Common.css. Instead of using the template {{fmbox}} that in turn uses several classes in MediaWiki:Common.css. That means less things that can break.
• As I mentioned in my message above, having the class "div.fmbox-warning" in MediaWiki:Common.css only costs one line of code, since the content of that class anyway have to exist for the "div.mw-warning-with-logexcerpt" and "div.mw-cascadeprotectedwarning".

There might seem like there is one drawback: If using a div then we can't use "What links here" for {{fmbox}} to see which MediaWiki messages use the warning style. But we can just as well use Special:Search for that. The Wikipedia search function nowadays is very good.

2: Next thing is, do {{fmbox}} then really need the warning style? Yes, since fmbox is already used elsewhere with that style and an image at the same time. Then the table based {{fmbox}} is much better. For instance, today for the first time I saw the MediaWiki:Abusefilter-disallowed message when I was trying to do some good work... :))

3: Note that the code in the "div.fmbox-warning" class can not be directly reused for a "table.fmbox-warning" class. Since the div class has its padding directly in the div class, while the table class has its padding in the "td.mbox-text" class.

4: But it probably isn't necessary to have the "table.fmbox", "table.fmbox-warning", "table.fmbox-editnotice" and "table.fmbox-system" classes in MediaWiki:Common.css. Since I don't think the fmbox will be styled in other skins, and I don't think people will build hand coded fmboxes. And users that want to style them in their own user /monobook.css can use the !important keyword.

5: There are some reasons why the mbox classes use the "table." specifier:

• People were often trying to use the mbox classes in divs and complained when it didn't work as they expected. We even had admins that tried to "fix" (edit) the mbox classes so they would work in their divs. Adding the "table." specifier made it clearer how they are supposed to be used.
• For the fmbox we sort of need to use the "table.fmbox-warning" to disambiguate from the "div.fmbox-warning" class.

6: Of course, since people will continue to ask why we use a div, then it might be easier to simply instead use {{fmbox}} everywhere...

--David Göthberg (talk) 15:14, 8 April 2009 (UTC)

Thanks for the explanation. I don't think it's a good idea to have more ways of doing something than are strictly necessary, and this is an example of that. Yes it works, and yes it's slightly more efficient, but it's only more robust if people understand that it works that way. As it stands it's particularly confusing because, not only is it different from all the other mboxes, the class in common.css named "fmbox-warning" and also found in {{fmbox}}, isn't actually used in {{fmbox}}: even though the two classes have the same name, they don't correspond. That to me is Wrong. Either the styles in common.css should also apply to the table produced by {{fmbox}} (which you say is not possible), or the two classes shoudn't have the same name. But then we're creating a completely different structure, when we don't even need it (since we can just use {{fmbox}} on such system messages). Throw in the complication with finding such boxes - your search example isn't actually picking up the instances we know to be there, and regardless it's not pretty to have to look in two separate places to find all uses - and it becomes rather difficult to argue for its retention, IMO.

So if we deprecate and replace div.fmbox-warning with {{fmbox}}, we have no need for that line in common.css. Although as you note, we need the styles anyway for the other things we style the same way, I don't see a particular problem with having the styles both in common.css and fmbox, as long as they are obviously different. Right now, it looks like {{fmbox}} should be using the common.css styles like all the other mboxes, but isn't by accident, so you get silly admins trying to fix it so it does :D. If we have to have some warnings produced by hardcoded styles in {{fmbox}}, and some warnings styled by code in common.css, which we do, it saves much confusion all round if they at least look like different structures.

Rather rambling and much less informative than your post, but in summary my IMO: ditch div.fmbox-warning, replace all its uses with {{fmbox}}, and remove it from common.css to avoid confusion. Happy‑melon 15:57, 8 April 2009 (UTC)

Okay, my turn to rant. :))

So you are saying that we can't expect that the people that edit our CSS files understand the most basic CSS selectors and know the difference between a div and a table. Unfortunately you might be right about that. So, we have three options:

1: Be stubborn and keep the "div.fmbox-warning" class. Which you advice against. But we could add some more documentation in some places, and a longer comment in the CSS code. That class has been there since 2 November 2008, and you are the first admin that have tried to change it. And now you have learnt what that class means. So we have only had one incident in five months. I think the problem is not at all as big as you might think.

2: Rename that class to for instance "div.system-warning". But I think that will be confusing, since then there won't be much indicating that those divs are meant to have the same look as the {{fmbox}}. Of course, we can add a longer comment in the CSS that explains that.

3: Skip the class altogether and use {{fmbox}} everywhere. Which seems to be your favourite. But then experience has shown that we will at regular intervalls have Twinkle using admins all over the place trying to "fix" things. That usually happens every time someone has added a <br> instead of a <br /> in a system message, since Twinkle chokes on that. And they will for instance try to "fix" things by changing the code in {{fmbox}}. And Twinkle using admins are used to edit fast, so they don't ask or read documentation or read talk pages first, they just do.

Note that up until recently all those MediaWiki warning messages used divs with hard coded styles. And that worked well for many years.

--David Göthberg (talk) 18:23, 8 April 2009 (UTC)

I don't think the issue is people not understanding the difference. If they didn't know the difference they would assume that the styles in common.css are for {{fmbox}} and be happy and content. It's the people who know what they're seeing, and know the difference, that are the problem, they're the ones who are confident enough in their own knowledge to "know" when something is broken and try to fix it. A little knowledge is dangerous. Yes, I now know what's going on, but there are plenty of other admins who know just enough about the mbox system to spot a deviation ("error") and be tempted to fix it. Having exactly one mbox declaration not only different to all the others, but fulfilling a completely different purpose that actually has nothing to do with the mbox templates, is just asking for trouble. On the other hand, while we have indeed had our fair share of Twinkle users fixing system messages that use fmbox, we have exactly no edits to Template:Fmbox itself for that purpose, despite it being significantly more widely used than the div format. While you're right about the bull-in-a-china-shop approach that's often employed, I don't think that admins being rash with {{fmbox}} is a legitimate concern. It would be sensible to document the fact that correct XHTML should be used in system messages, perhaps in the namespace editnotice, and the particular bug with wikilists that affects fmbox should be documented on fmbox/doc. But I think moving system messages to use fmbox rather than div.fmbox-warning is a step to remove a point of confusion, not to create one.

We already have the infrastructure in place to deprecate the div.fmbox-warning style, and indeed it is almost completely done - a search of Special:allmessages shows that it's only in use on MediaWiki:Editingold - and removing it removes a source of confusion that's completely unnecessary. It'll take two edits, one to that system message and then one to Common.css. I just don't see why we shouldn't do it. Happy‑melon 20:13, 8 April 2009 (UTC)

Cascadeprotectedwarning

I just noticed that the devs have now added a thing I waited for in the MediaWiki page rendering. I can now make the MediaWiki:Cascadeprotectedwarning work the same as our MediaWiki:Protectedpagewarning message. That is, I can now surround both the cascadeprotectedwarning message and the list of links below it with a single pink box, with a horizontal line between. Instead of as now that the list of links below ending up outside the pink box.

To see what I mean: If you are an admin click the edit tab on for instance {{cmbox}} and see the two pink warning messages you get at the top of the editing page. (If you are not an admin: Well, these messages are only visible for admins anyway, to remind us to be careful when we edit protected pages.)

To fix this I will add one line of code to MediaWiki:Common.css. I will change this code: <source lang="css"> /* 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;

} </source>

To this: <source lang="css"> /* Pink fmbox warning style for div based warning notices. */ div.fmbox-warning, div.mw-warning-with-logexcerpt, div.mw-cascadeprotectedwarning {

   clear: both;
   margin: 0.2em 0;
   border: 1px solid #BB7070;
   background: #FFDBDB;
   padding: 0.25em 0.9em;

} </source>

And I will remove the pink box from within the MediaWiki:Cascadeprotectedwarning message and add a pink horizontal ruler instead.

I will do this some day from now, when I am not as tired as now. (Don't edit system files when you are sleepy...)

--David Göthberg (talk) 10:41, 6 February 2009 (UTC)

Y Done - And it looks very nice, when one's browser has loaded the new version of MediaWiki:Common.css.

--David Göthberg (talk) 09:30, 8 February 2009 (UTC)

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)

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:

<source lang="css"> 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;

} </source>

Or like this:

Example 2:

<source lang="css"> 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;

} </source>

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:

<source lang=css> .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;

} </source>

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)

CSS

Currently the only class in fmbox that is styled with CSS is the fmbox-warning class. Should we, in the interests of consistency with the other mbox templates (and code clarity in fmbox itself) put the other bits of styling from this template into Common.css? Happy‑melon 11:40, 8 April 2009 (UTC)

As I have stated before:

It probably isn't necessary to have the "table.fmbox", "table.fmbox-warning", "table.fmbox-editnotice" and "table.fmbox-system" classes in MediaWiki:Common.css. Since I don't think the {{fmbox}} will be styled in other skins, and I don't think people will build hand coded fmboxes. And users that want to style them in their own user /monobook.css can use the !important keyword.

So I think we can wait with adding them to MediaWiki:Common.css until someone has the need for it.

--David Göthberg (talk) 18:31, 8 April 2009 (UTC)

Here is the CSS code for fmbox:

<source lang="css"> /* For div based pink warning notices, like the fmbox warning style.

The "div.fmbox-warning" is for hardcoded messages using

tags. */

div.fmbox-warning, div.mw-warning-with-logexcerpt, div.mw-cascadeprotectedwarning {

   clear: both;
   margin: 0.2em 0;
   border: 1px solid #bb7070;
   background: #ffdbdb;
   padding: 0.25em 0.9em;
   color: #000;   /* Fixes the text color in some messages. */

}

/* Footer and header message box styles */ table.fmbox {

   clear: both;
   margin: 0.2em 0;
   width: 100%;
   border: 1px solid #aaa;
   background: #f9f9f9;     /* Default "system" gray */

} table.fmbox-system {

   background: #f9f9f9;

} table.fmbox-warning {

   border: 1px solid #bb7070;  /* Dark pink */
   background: #ffdbdb;        /* Pink */

} table.fmbox-editnotice {

   background: transparent;

} </source>

I have tested this code properly, it does what it should.

Happy-melon: As you can see I extended the comment above "div.fmbox-warning" to make it clear what it is for. I hope that will alleviate your worries?

I remembered a thing: Every now and then other admins have hard coded system messages that used the ambox or imbox styles, since they didn't want to be dependant on a template. But they did use the CSS classes. And since this is the fmbox, that might happen even more often. So we need to supply the classes for that, either the table based classes, or the div based classes, or both.

--David Göthberg (talk) 23:10, 8 April 2009 (UTC)

Do I take it from this that you're coming around to the idea of putting the fmbox CSS in common.css?? Or is this just a thought exercise :D?? I tweaked the comment a bit, I'm much happier with that. Even though it is unused, since I just converted MediaWiki:Editingold to fmbox. I guess we can keep an eye on it. Happy‑melon 09:25, 9 April 2009 (UTC)

Yes, now that I see that the fmbox table code isn't that much code, and I remembered that admins every now and then want to hardcode even complex boxes, then I think we should add the table code.

I like your tweak to the div comment, much nicer. But okay, if you still feel like it, remove the "div.fmbox-warning" altogether. (Then we don't need the "color: #000;" part, so don't add that to Common.css.)

--David Göthberg (talk) 18:04, 9 April 2009 (UTC)

That's all I needed to hear :D!! I've added it to common.css; and I did indeed remove the div.fmbox-warning. Thanks for sorting all that out! Happy‑melon 18:21, 9 April 2009 (UTC)

Ouch, I feel robbed, I really liked "div.fmbox-warning"...

Note to us: The fmbox classes will have decached on 10 May 18:20 UTC, after that time we can remove the hardcoded styles from {{fmbox}}.

--David Göthberg (talk) 00:01, 10 April 2009 (UTC)

If that's a joke, LOL, otherwise, do feel free to add it back; as I said I'm much happier with it with the expanded comment. I still don't think it's useful, but I don't have an active problem with it anymore... Happy‑melon 10:19, 10 April 2009 (UTC)

Requested edit

{{Editprotected}}

Click here to see my requested edit . I am requesting that this edit be made to allow a custom box type to be used. -- IRP ☎ 23:20, 18 April 2009 (UTC)

Why is this necessary? The individual parameters can be specified easily anyway, so this edit seems fruitless. — neuro^(talk) 08:32, 19 April 2009 (UTC)

Did it anyway. --Closedmouth (talk) 08:37, 19 April 2009 (UTC)

I have undone this edit. There is no need to specify a custom class, as you can use the |style= parameter equally well to set a custom appearance with the 'standard' fmbox-system class. There are actually no CSS style rules associated with that class, so it is completely identical to the proposed fmbox-custom in all but name. The addition was completely unnecessary. Happy‑melon 09:00, 19 April 2009 (UTC)

Happy-melon is correct. {{fmbox}} already can do what it seems IRP wants to do, and it can do much more. And the image and error reporting code you added had no effect. Sorry.

This stuff is tricky, even we who have worked for years with these boxes sometimes get confused when we edit that code... But using these boxes is actually pretty easy, if you read the documentation carefully.

So IRP, go read the {{fmbox}} documentation. And if the documentation is unclear, come back to this talk page and tell us what you want to achieve and we can help you do that.

If you want to override the styles in your personal /monobook.css then you need to use the !important keyword since fmbox still uses hard coded styles. See WP:DECACHE for more about how to use the !important keyword.

--David Göthberg (talk) 15:57, 19 April 2009 (UTC)

I made this request in order for this other request to work, and here's why. -- IRP ☎ 22:00, 20 April 2009 (UTC)

That can already be achived with the style parameter:

{{fmbox
|id    = talkpagetext
|type  = editnotice
|image = none
|style = background:#F8EABA; border:1px solid darkyellow;
|text  = This is a '''[[Wikipedia:Talk page|talk page]]'''. Please respect the [[Wikipedia:Talk page guidelines|talk page guidelines]], and remember to [[Wikipedia:Signatures|sign your posts]] by typing four tildes (<tt>~~~~</tt>).
}}

-- WOSlinker (talk) 22:20, 20 April 2009 (UTC)

Good. Can you implement that change on MediaWiki:Talkpagetext so we won't need {{uw-tilde}}. If it is noticeable, we won't need that user warning template anymore and we won't have any unsigned comments. -- IRP ☎ 22:42, 20 April 2009 (UTC)

IRP: Ah, so you want to make the namespace notice for talk space look like a talk page message box.

First a minor technical detail: According to the guideline for talk page message boxes, and the code and styles we use for {{tmbox}}, the correct default colours for talk page message boxes are:

| style = background: #F8EABA; border: 1px solid #C0C090;

It's not a very visible difference, but anyway.

IRP: I am truly sorry (I promise, I am, since I know this is going to hurt for both you and me), but since the change you suggest goes against the current (but weak) consensus, and will be very visible to all editors, I have to hit you with some bureaucracy:

A "namespace notice" is the notice that is shown above all pages in the same namespace when you edit them. Many of the namespaces have such a notice. There are also a whole bunch of other system messages that are shown on top of pages in different situations. For MediaWiki space the namespace notice is MediaWiki:Editnotice-8, which looks like this:

Note that the message says: "Please ensure that your revision reflects consensus. When in doubt, discuss first on the talk page and/or Wikipedia:Village pump." And note that that is the message we admins see for instance when we edit MediaWiki:Talkpagetext, which is the message you IRP want us to change.

So the question is, what is the consensus for the looks of namespace notices like MediaWiki:Talkpagetext and for other system messages that goes on top of pages?

Should system messages look like the default message box style for their respective namespaces? (For instance use {{ambox}} colours when in article space, and {{cmbox}} colours when in category space.) Or should they look like editnotices? (Transparent.) Or should they use the light grey system message colour? (Like fmbox type=system.) This question has been brought up every now and then in different places.

One thing is pretty clear, they should be 100% wide. Almost all notices that go above the edit preview area are 100% wide and have been so for a long time.

But their colours have been somewhat more varied. But mostly they have used either transparent like the fmbox type=editnotice, or light grey like the fmbox type=system. It seems lately the push has been towards transparent, and the light grey system colour is just used for some special messages. Although I have seen some requests for more colours.

IRP: I see what you mean with: "If it is noticeable, ... we won't have any unsigned comments." It's a good argument.

Personally I think I slightly prefer the light grey, with transparent as second choice. But I would be fairly okay with an exception to use talk page brown for the talk space notice. But there is the problem that we might get an arms race. Then people might want more colours for the other namespace notices, and for the page specific editnotices, and for all other kinds of system messages and notices...

So I think we must hear the opinion of more editors before we do any change. Note that we haven't really had any larger discussions about the styles for the namespace notices, so it is a very weak consensus, mostly based on what we admins have simply deployed.

(And why can I never learn to be short and succinct?)

--David Göthberg (talk) 01:35, 21 April 2009 (UTC)

That really is the million-dollar question, DG :D

I don't think it's either desirable or necessary to have different editnotice styles for different namespaces. The developers have always been at something of a loss to explain why we access the 'edit a page' interface through &action=edit rather than by going to some Special:EditPage/Foo, like Special:MovePage/Foo. Perhaps at some point that transition will be made, it makes things much easier for a whole host of reasons (search engine indexing, for instance, and caching). My point is that it's confusing and not entirely semantically correct to think of the edit screen as being 'part of' the page itself; it is a distinctly separate interface. For instance, you can edit an old version of a page through the same interface; if it was a version from before the page was moved, you could even be looking at a page 'from' a different namespace. If there's been a history merge, it gets even more confusing. The edit screen is distinctly separate from the page itself; while we see notices and information on the edit screen about the page we're editing, we are not actually in that page. As such, I think it is important to have a completely distinct set of styles for system messages that could be shown on the edit screen. The 'arms race' argument that DG raises is also valid; by keeping a simple set of unobtrusive colours, we avoid people taking more drastic measures: if editors find the fmbox styles glaring and intrusive, they might be tempted to simply hide all fmboxes in their personal CSS, which would be completely counterproductive.

All in all, I don't think that this change is constructive. Happy‑melon 09:40, 21 April 2009 (UTC)

I don't really see the "edits are not part of the page" argument as particularly significant for this question. I think I agree with the semantics you propose, I just don't think that leads to a foregone conclusion that all edit notices should look the same way, or that they should never look like something seen "on a page". • For that matter, one could argue that "message boxes" in general aren't really "part of the page". • I do think there's a benefit to making this change, in that it adds significant contrast to the edit notice. Contrast attracts attention in humans. So I like the idea. • But by the same token, people who find message boxes inherently annoying are likely to be all the more annoyed. I'm not in that camp, but it's worth mention. • Full disclosure: I'm one of those people who think the content now at {{talkheader}} should be on every page (via MediaWiki:Talkpagetext). • The "arms race" concern is real, I think. Mitigation: I expect it would be rare to have more than one edit notice displayed at once. So I think we'll avoid the problem of "banner overload" that often happens on talk pages and articles. —DragonHawk (talk|hist) 12:26, 21 April 2009 (UTC)

That's just it. The more you standardize the medium, the more likely people are to ignore the message. I know my mind has been tuning out everything that looks like this for a very long time now. — CharlotteWebb 18:41, 21 April 2009 (UTC)

I changed the edit notice on MediaWiki:Editnotice-7, the File talk namespace because I've had to delete over 1/7th of the namespace because of housekeeping, nonsense, etc posts and RecentChanges indicate a more subdued notice wasn't deterring it. Over at Wikipedia:Abuse_filter/Requested#File_talk:_clarification, it was suggested to make the notice more prominent before requesting a filter. MBisanz ^talk 03:24, 25 April 2009 (UTC)

MediaWiki:Editnotice-7 is the namespace notice for "Image talk" space. But you also changed {{visibility}} which is used as the notice for the MediaWiki talk, Help talk, Category talk and Portal talk namespaces. You made them 80% wide and talk page brown, with the orange major warning border and icon. You used {{tmbox|type=content}}, which looks like this:

But the proper style would be 100% wide. Most namespaces notices and editnotices etc. are transparent, but since you in this case want/need it to be a visible warning then use the pink system warning notice colour. That is, use {{fmbox|type=warning|image=none}}, which looks like this:

Or, to make it even more in line with our other notices:

But I kind of like the big centred "Attention" header, so I don't know which one I prefer. I guess it depends on how much attention this message needs.

MBisanz and everyone else: What do you think?

--David Göthberg (talk) 04:09, 25 April 2009 (UTC)

Ok, I've rolled back Visibility since those namespaces are not as problematic and altered the File talk page. MBisanz ^talk 04:25, 25 April 2009 (UTC)

I like both of them, but perhaps we should go with the second as it's a little less obtrusive. If it still doesn't work, we can 'upgrade' further to the centred header. Happy‑melon 12:44, 25 April 2009 (UTC)

Change to notice box on regular talk pages

I am requesting that the notice box on regular talk pages should look like:

Who supports or opposes this change? -- IRP ☎ 04:54, 25 April 2009 (UTC)

File:Fmbox coffeeroll.png

I don't see any particular advantage to using coffeeroll rather than the fmbox-warning style if you're determined to 'upgrade' the visibility of the notice. I also don't think this is going to lead to a decrease in unsigned comments, which appears to be the main argument, but I can't really support that; it seems to me that most unsigned posts are either by newbies (who, if they're legitimate, are likely to read the instructions carefully anyway) or simple forgetfulness by experienced users (who have developed acute banner blindness to coffeeroll anyway and so are likely to completely ignore it). Looking at a demo (right), it appears very out-of-place against the otherwise colourless interface; while I agree it's certainly more eye-ecatching than the current appearance, I don't think it's a 'nice' contrast. Happy‑melon 12:44, 25 April 2009 (UTC)

You could just go with something slightly more noticeable (but not too much) by adding a yellowish border (like there is around some of the tabs a the top of the page).

(not sure if I've got the correct shade of yellow though. :) -- WOSlinker (talk) 14:45, 25 April 2009 (UTC)

It's #fabd23. Happy‑melon 15:40, 25 April 2009 (UTC)

I dislike this idea: it would introduce namespace-specific differences where there was before a site-wide standard (varying for editnotices and warnings only). Also, the gains made by the change are highly dubious: people will simply acquire a new banner blindness. {{Nihiltres|talk|log}} 16:48, 25 April 2009 (UTC)

New users who are not experienced with Wikipedia will not be used to the banner. By the time a user gets used to it, that user would be aware of the talk page guidelines. It will be noticeable to new users, which is the goal of the change. -- IRP ☎ 17:09, 25 April 2009 (UTC)

That still doesn't address my issue that the change would add namespace-specific differences. If the standard is being ignored, doesn't it make more sense to adjust the standard than create some random other type for certain namespaces only? {{Nihiltres|talk|log}} 20:02, 25 April 2009 (UTC)

What about the bright red boxes displayed above? That's the same thing. The purpose of changing the style is to draw attention to the important information, making an exception to the "don't add namespace-specific differences" rule. -- IRP ☎ 20:23, 25 April 2009 (UTC)

The presence of important information is not limited to one namespace, hence this is not, per se, an exception. The pink "fmbox-warning" style boxes are not namespace-specific. Happy‑melon 20:28, 25 April 2009 (UTC)

Then should we make any changes at all? If so, which changes should we make? -- IRP ☎ 20:39, 25 April 2009 (UTC)

I'm not convinced we should, no. Happy‑melon 23:38, 25 April 2009 (UTC)

I think we should keep MediaWiki:Talkpagetext as it is. (Transparent with a simple grey border.) Since that message is shown on all talk pages, every time we edit a page, no matter how long we have been editors. So it would be annoying if it is too in our face. And since it is shown every time, new users will sooner or later notice it and understand its content.

The pink fmbox warning style would be much too strong in this case. And even if we had some softer minor or major warning style for editnotices, for instance yellow or orange border as WOSlinker suggested, then I wouldn't want to use it in this case. Since MediaWiki:Talkpagetext isn't even a minor warning, it is just an informative notice. In the other mboxes that would be "type=notice". And for the editnotices the corresponding non-intrusive notice style is the transparent fmbox "type=editnotice".

And I don't see the need for namespace specific editnotice styles. I think the editnotices should look different compared to the message boxes we put at the top of but in the pages. Since the editnotices are different, they are only shown when we edit the page.

But we should perhaps have some difference between "system messages" like the MediaWiki:Talkpagetext which is shown on many pages automatically, and the page specific editnotices. We could use the light grey "type=system" for MediaWiki:Talkpagetext. Like this:

But we are planning to add a little ^view link in the upper right corner of the page specific editnotices so that people easily can find the editnotice's page to see its code and edit it. So that link will probably be enough to tell the page specific notices apart from the "system messages". So having different styles for them perhaps is unnecessary.

--David Göthberg (talk) 10:13, 27 April 2009 (UTC)

My understanding of the fmbox setup was that 'fmbox-system' is to be used for system messages that don't appear above the edit window; like MediaWiki:Sp-contributions-footer-anon. And the 'editnotice' style was for all non-fmbox-warning messages that did appear above the edit/view-source window. Happy‑melon 12:06, 27 April 2009 (UTC)

How about using:

Who supports or opposes this change? -- IRP ☎ 23:41, 27 April 2009 (UTC)

• IRP, while I support giving certain, specific edit notices a more noticable appearance, I think that edit notices placed on thousands of pages (namespace-wide edit notices plus the two magic edit notices {{Disambig editintro}} and {{BLP editintro}}) should be as unobtrusive as possible, to prevent banner blindness with edit notices that matter far more. That includes both adding colors and icons. Amalthea 00:10, 28 April 2009 (UTC)

Question on style section

In the style part, just wondering if background: #f9f9f9; needs to be in there twice? Should the first one be removed? -- WOSlinker (talk) 18:14, 20 April 2009 (UTC)

Seems duplicate indeed. — Edokter • Talk • 19:47, 20 April 2009 (UTC)

I assume you guys are talking about the hardcoded style="" parameters in {{fmbox}}. Technically you are right, when setting type=system or not setting a type at all (thus using the default), then "background: #f9f9f9;" is declared twice. The reason we do like that is that those hardcoded styles are just temporary, they were a test of the CSS classes we then added to MediaWiki:Common.css. We usually code the styles exactly like the CSS classes will be, so we then can just copy and paste them into the CSS classes and know it will work. Thus reducing human mistakes, since it sometimes is weeks or even months between when we code and test the styles for a box and the day we add the classes to Common.css. (And for the fmbox it indeed was some months.) Note that the hardcoded styles must remain in {{fmbox}} until 11 May, since web browsers cache Common.css for up to 31 days.

If you look at the fmbox classes in MediaWiki:Common.css it might become clearer for you. But even when using the CSS classes the background for type=system is redundant, and even the whole class fmbox-system is kind of redundant. Since the main fmbox class itself already sets the system background. Since when you hand code a box, we allow this simplified notation:

<source lang="xml">

</source>

So the main fmbox class must set the default background. But we prefer if people set the fmbox-system class, since it makes it clearer what kind of box it is. Like this:

<source lang="xml">

</source>

So the fmbox-system class currently is just symbolic. So why do we declare it at all? Well, if the fmbox-system class is not declared anywhere, then people probably won't add it to their code. So we need the class to exist. But just having an empty class would be strange, so we of course add the background colour to it to make it clear what it means.

But there are some more reasons why we want people to use the fmbox-class: If we ever change the default type for the fmbox, say to the transparent type=editnotice, then boxes that use the fmbox-system class will still work as you expect, they will still get the light grey #f9f9f9 background. Or if we decide to even deprecate the system style, then we can do a search for "fmbox-system" to find those hand coded boxes and fix them. (Yeah, we are thinking way ahead.)

I hope this makes sense to you guys. It is more about how to make humans interpret the code correctly, than the actual technical aspects. Pedagogy really.

--David Göthberg (talk) 00:06, 21 April 2009 (UTC)

Category proposal

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

Dragons flight: We have a problem. You added automatic categorising to the {{fmbox}} making it so that any template built with or even just displaying the {{fmbox}} is listed in Category:Footer and header message boxes. That is, when an {{fmbox}} is transcluded into a page in template space it adds that category to that template page.

However, this is now causing a problem: When editing pretty much any template page we now see Category:Footer and header message boxes at the bottom of it, even if that template doesn't use that category and doesn't use an {{fmbox}}. For instance, take a look at {{search link}} and see what categories it lists at the bottom of its page, then open the edit view and see that it suddenly shows Category:Footer and header message boxes. When I noticed that I found it confusing. It took me a while to figure out the reason.

Look at the top of that page while still in edit view, there you will see this editnotice:

That's an {{fmbox}}, which is correct since the {{fmbox}} is the meta-template used to make editnotices, either directly or by using {{editnotice}} which in turn uses {{fmbox}}. And as you can see we also use editnotices on template pages. For instance that editnotice automatically shows on top of all template pages that have a /doc page. That editnotice is loaded from the top-level editnotice for the template namespace: Template:Editnotices/Namespace/Template

It is confusing that an unrelated category now is shown when editing pretty much any template, so we need to do something about it. My experience is that putting categorising into meta-templates usually causes nasty problems, so my first hunch is that we simply should remove Category:Footer and header message boxes from {{fmbox}}.

--David Göthberg (talk) 03:10, 25 October 2009 (UTC)

You mean that, when previewing a page that has an fmbox-based editnotice, the categories generated by that editnotice are being added to the preview? That sounds like a MW bug. Happy‑melon 10:52, 25 October 2009 (UTC)

Happy-melon: Yes, you understand it correctly. And you stated it very clear and succinct. And yes, I already noticed last year that editnotices can insert categories, which I agree they should not be able to, so yeah it kind of is a MediaWiki bug. They can do some other silly things in the preview too (some of which I fix in my more robust and user-friendly editnotice loader, but unfortunately I have been ordered not to install my loader for reasons unclear to me).

But anyway, I want to remove the auto-categorising from {{fmbox}}, since it causes problems.

I also have an alternative solution to at least minimise the problem if you guys disagree to remove the category. But I find this alternative messy:

I have added an explanation at Category:Footer and header message boxes so template coders that come there can find out the reason they see the category. And I made the category hidden, so most template programmers won't see it. And we can add a parameter to the {{fmbox}} that allows us to turn of categorising, so we at least can make it so the {{editnotice}} template does not cause categorising and so we can manually turn off categorising for those editnotices that use {{fmbox}} directly. Or we can make it so that "type=editnotice" turns of the categorising, thus making it fairly automatic. Of course, that means that any transparent header and footer mboxes will not get listed in the category, even if they are not used as editnotices. And that still means that any template that has an editnotice with "type=warning" still will show the category.

--David Göthberg (talk) 13:41, 25 October 2009 (UTC)

I don't think it's entirely a bug—certain interface messages are meant to carry categories, for example the ones that transclude {{broken ref}}. Adding the category to the meta-template is a bad idea, as David originally said. The only category code that a meta-template should carry is category code that could be satisfactorily transcluded on every page that the template (as opposed to the meta-template) is transcluded. For example, the only category handled directly by {{pp-meta}} is the error category Category:Wikipedia pages with incorrect protection templates—the individual categories are handled by each main-level template. The code can thereby become somewhat redundant, but generally it isn't worth it to make a second meta-template system that will handle just categories on a more fine-grained scale than the main meta-template. {{Nihiltres|talk|edits}} 16:05, 25 October 2009 (UTC)

I agree with your definition, but that's not what's happening here. The fmbox instance isn't transcluded on the page, it only appears as an editnotice when previewing the page. So the category doesn't appear when viewing the template page (and the category is never recorded in the categorylinks table), but it is displayed when you hit "preview". Any deviation between the preview mode and the saved page is a bug. Essentially the problem is that the parser output is being polluted by the other stuff that it's being asked to render: the same PHP object is used to parse everything on the page, but only the actual page content should be allowed to add to the parser output's collection of categories, etc. Intriguingly, the list of templates is not similarly polluted, so perhaps this is only a 'minor' issue, not a fundamental problem with the parser design. It might be interesting to check whether other 'peripheral' parser items, such as the tracking categories from __NOINDEX__ or the expensive parserfunction limits, are also polluted from editnotices. Happy‑melon 17:35, 25 October 2009 (UTC)

Yes, I understood that. I suppose what I meant to say with "not entirely a bug" was that there are instances where it's good for interface-inserted categories to be used, so a bug report shouldn't say "disable all interface-based categories, please", it should say "don't let editnotice content etc. insert categories, please". Sorry for the ambiguity. {{Nihiltres|talk|edits}} 18:31, 25 October 2009 (UTC)

I am going to remove this categorization from {{fmbox}}, and probably from {{dmbox}} and {{cmbox}} too. As described above, having the logging category in {{fmbox}} is confusing for template programmers. And having it in {{dmbox}} and {{cmbox}} can also be confusing, since templates that only use them in the documentation would get listed too. And for those three templates we don't need this categorization. Here's why:

The reason that Dragons flight stated for adding this categorisation was that he could not use the MediaWiki API to find the templates that are using {{tmbox}}, since the API failed when finding too many items. For very long lists it is also not doable to use "What links here". But these reasons do not hold up for {{fmbox}}, {{dmbox}} and {{cmbox}}. Since for them it is no problem to use "What links here". Look at these numbers:

{{fmbox}}: Category:Footer and header message boxes currently lists 25 boxes. When using "What links here" for {{fmbox}} I find about 260 templates and template subpages. The subpages are mostly editnotices. But there is no problem to manually find the 25 template basepages among those 260 items.

{{dmbox}}: Category:Disambiguation message boxes currently lists 37 boxes. Using "What links here" I find 50 templates and template subpages.

{{cmbox}}: Category:Category message boxes currently lists 99 boxes. Using "What links here" I find about 130 templates and template subpages.

When I used "What links here" I selected to only view template space, and to hide links.

So there's no good reason to confuse lots of template programmers (including me, I got confused today again and had to reinvestigate since I had forgotten).

--David Göthberg (talk) 15:06, 25 November 2009 (UTC)

Undefined id causes invalid HTML

If |id= is not defined, then it renders as id="", which is invalid. For example: {{editnotice}} uses {{fmbox}}, therefore {{editnotice central}} fails validation; see W3C markup validation for Template:Editnotice central.

I made the id optional in {{fmbox/sandbox}}, with testcase in Template:Fmbox/testcases; see W3C markup validation for Template:Fmbox/testcases.

The validation error for <ul> is a known MediaWiki problem that has been fixed but not deployed. ---— Gadget850 (Ed) ^talk 21:13, 17 July 2010 (UTC)

File:Green check.svg Done -— Gadget850 (Ed) ^talk 14:14, 26 July 2010 (UTC)

Word wrap on left side?

Hi, I am trying to place this template to the right of my table of contents on a different wiki. Ombox can wrap to the right of the {{TOC_left}} table of contents, but Fmbox does not. How can I cause Fmbox to wrap around and appear on the right of it? Thanks! 99.138.128.2 (talk) 05:00, 1 August 2010 (UTC)