Wikipedia talk:Article message boxes/Archive 7

From Wikipedia, the free encyclopedia

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Conflict with floated elements

This issue has been long standing. The AMBs run into right-floated elements which is really ugly. To see an example, please see this version of an article. Issues like these have traditionally been solved by adding {{-}} {{clear}} clears. I'm wondering why we don't just set "display:block" on the table. This should make sure the text of the AMB does not run into the right floated element. I don't see a downside, but it seems so obvious that it just cannot be so simple.... or is it? Please see my Sandbox for an example where the table has display:block set in several kinds of positioning situations within the text. I'd love to hear some comments. --TheDJ (talk • contribs) 12:21, 18 September 2007 (UTC)

Yes, something has to be done. See Wikipedia_talk:Article_message_boxes#example_of_overlap.2C_and_example_after_fix above. The other option is to set "clear: both;" on the ambox. Is there an advantage to "display: block"? — Carl (CBM · talk) 15:23, 18 September 2007 (UTC)

the advantage is that if there is a pagehigh infobox, with clear, you have an as good as empty page until the bottom of the infobox is reached. Using display:block keeps the current position and flow of the text on the page, while still keeping all the text in the messagebox readable. Note that it doesn't move the borders of the actual messagebox. It's not ideal, but it's at least better then what we have now, and in my personal view it's better than setting clear on ALL messageboxes. If needed clear can still be applied on specific cases. Where a lot of images are involved etc, a clear might still be preferred. --TheDJ (talk • contribs) 15:43, 18 September 2007 (UTC)

The problem is that there just isn't enough screen space to fit any nontrivial thing to the right of an ambox, when the width of an ambox is set to 80%. For example, I am using a 17" monitor right now with about 13" of usable width. If I used a 10pt font size, that means about 94ems of width. The portlets are 11.6 wide, leaving 82 ems for the content. The ambox uses 80%, which is 65.6 ems (ignoring the margins). That leaves 16.4 ems for an infobox, about 2.25in. So unless we have a lot of 2 in wide infoboxes, there's no reason to set things up to allow the ambox to have something to its right. We might as well just clear both sides and be done with it. There is also the option of making the ambox narrower, I suppose. — Carl (CBM · talk) 15:55, 18 September 2007 (UTC)

Ehm, I tested and with "display:block" it instead looks worse in Opera. :((

It seems we got no good solution, just a bunch of bad to choose from. That is, as it is currently with no extra setting is bad, with "clear:both" is also bad and "display:block" is also bad. Just that it becomes bad in different web browsers.

--David Göthberg 15:59, 18 September 2007 (UTC)

I think you're right that there is no good solution, because the CSS we can use doesn't support what we are trying to do. Of the three (do nothing, clear: both, and display: block), clear has the advantage that it never makes borders or text overlap, and is bad only in adding extra whitespace in a few situations.

Another option is to add a parameter (like narrow=yes) to all the templates that makes the ambox use "width: 50%;". That should leave plenty of room for an infobox on all common monitor and font sizes. See Mass_Effect:_Revelation for an example where I hacked this up (screenshot). — Carl (CBM · talk) 16:07, 18 September 2007 (UTC)

It only looks worse on Opera, because Opera seems to "illegally" insert a "clear:both" automatically on these messageboxes in their current form. It's not supposed to do that, according to the CSS spec. --TheDJ (talk • contribs) 16:33, 18 September 2007 (UTC)

And a "narrow" option does not work on Safari, Safari (and opera) will keep the box smack in the middle of the parent CSS block, instead of moving it to the middle between left edge parent and left edge of the right float. In my experience, atm all browsers do something different, with at least Firefox and Safari letting the text overlap into the infoboxes. With display:block, all the browser behave the same and none of the text overlaps into the infoboxes. With clear:both, we have the same behaviour as well, but we have a lot of empty space in between everything. (PS. i'm checking if Safari is right in the center positioning of the messagebox when there is a right float element, or that Firefox is being smarter then the CSS defines it should be). --TheDJ (talk • contribs) 16:43, 18 September 2007 (UTC)

Even if the ambox stays centered, a user with a 11" wide window and 10pt font size should be able to fit a ambox set at 40% width (which translates to about 3.8" wide), and a space of 20em on both side of it; the infoboxes seem to be set at 20em. — Carl (CBM · talk) 16:51, 18 September 2007 (UTC)

I partially got my question answered: "i don't have a good explanation for the wikipeida rendering. my reading of CSS2.1 is that tables should not overlap floats, but WebKit applies this rule only to tables with auto width. will you file a bug at bugs.webkit.org? (CSS2.1 says: "The border box of a table [...] must not overlap any floats in the same block formatting context as the [table] itself. ")" --TheDJ (talk • contribs) 13:38, 19 September 2007 (UTC)

The bug# for this issue in Safari. Apparently it's been known for a while. --TheDJ (talk • contribs) 23:52, 21 September 2007 (UTC)

Fixing the flow conflict problem

OK, well not fixing it all all isn't a solution - like I calculated somewhere, nobody with a 17" screen and 10pt fonts can possibly have enough room to have an ambox to the left of an infobox with everything sized the way it is. The question seems to be between:

1. display:block. Doesn't add vertical space but allows border collisions
2. clear:both. Prevents all collisions but adds vertical space.

There is also the possibility of reducing the width of an ambox in certain circumstances. Thoughts on how to go forward? — Carl (CBM · talk) 12:59, 19 September 2007 (UTC)

What happens if you place a div (a block element) around the table, and give it a small amount of horizontal padding? --ais523 13:40, 19 September 2007 (UTC)

Would it be easier to simply left-justify the amboxes? That would eliminate potential issues with infoboxes. Horologium t-c 13:47, 19 September 2007 (UTC)

There just isn't enough space with the widths set the way they are. On a 13" wide screen (like a 17" diagonal) with 10pt fonts, there are about 82 ems of space for the content (excluding the portlets), of which the infobox want 20 and the ambox wants 66. And we can't assume our readers use fonts as small as 10pt or that they maximize their window. — Carl (CBM · talk) 14:29, 19 September 2007 (UTC)

I tested div wrapping, and it does not seem to solve the issue either. --TheDJ (talk • contribs) 14:50, 19 September 2007 (UTC)

Next steps

Right, I think we need to look at the following:

1. Background colour - there seems to be a vague consensus that light grey is better than what we have at the moment
2. The protection templates need modifying, using a grey (or browny-grey) colour bar as discussed above

Obviously discussion can still continue on these matters but I hope it will make things a little better for now. violet/riga (t) 20:16, 19 September 2007 (UTC)

Kaldari has done #1. violet/riga (t) 21:45, 19 September 2007 (UTC)

I suggest we make a class named "ambox-protection" and add it into MediaWiki:Common.css immediately since we have the caching problem. Then we can argue about the exact colour and change it once we agree. I suggest adding this code:

table.ambox-protection {
  border-left: 10px solid #bba;       /* Gray */
}

Note! Add the code BEFORE the "ambox-mini" class to avoid any future cascading problems.

Its the colour that violetriga suggested above at #Protection Templates which renders like this:

Editing of this page by unregistered or newly registered users is currently disabled.

This page is currently protected from editing.

Oh, and any admin that does the adding: Can you please change back the colour comments on our ambox code in MediaWiki:Common.css to say the simpler colour names to avoid future confusion? Instead of the confusing "DodgerBlue, FireBrick, Tangerine, Saffron, DarkOrchid, Forest green" use the old simple ones "Blue, Red, Orange, Yellow, Purple".

--David Göthberg 12:01, 20 September 2007 (UTC)

Y Done -- Flyguy649 ^talk _contribs 12:42, 20 September 2007 (UTC)

Thanks Flyguy649. So boldly pressing ahead:

1. I suggest we use the grey padlock as the default padlock in the {{ambox}} meta template. Not that it matters since there are not many protection templates so they will probably be well kept after and have every image set specifically. And I suggest we use the 40x40px size that we use for other icons in this new design. (Just like the padlocks in the example above.)

2. Since the protection templates are used both on articles and in project space we perhaps should use some parser functions inside them to only make them use this new style when they are on articles. (I can fix that code unless someone else is in the mood?) A funny side effect will be that they will then not show their new style in their listing at Wikipedia:Template messages/Maintenance.

3. I think we should wait some days to do this change due to the cache problem. And I have a new simpler, shorter and more flexible code for ambox that Random832 pointed out to me so I would like to code up and test that and add the protection type too, then we can add all that in one single change to {{ambox}}.

--David Göthberg 01:24, 21 September 2007 (UTC)

That all sounds pretty good. The only suggestion I have is to post a notice of the upcoming changes to the Village Pump and perhaps post on a noticeboard and the template talk pages. I think this would help alleviate some of the "I had no idea about this change" concerns. Cheers. --MZMcBride 01:59, 21 September 2007 (UTC)

MZMcBride: Ok, good idea. I will post on the "Village pump proposals" and the talk page of one or two of the protection templates. But where is the notice board you are speaking of?

--David Göthberg 02:15, 21 September 2007 (UTC)

Because protection and unprotection are really admin-related things, use WP:AN. Cheers. --MZMcBride 02:26, 21 September 2007 (UTC)

Yeah, I realised that was the noticeboard you meant, so I announced the (proposed) change of the protection message boxes at Wikipedia:Administrators' noticeboard too.

By the way, I have now taken a look at the existing padlock code. They are slightly complex since they have their own small mode (just a small padlock up in the right corner of the article). And now we are going to make them look different in articles and other places. So it seems better to make a special meta template only for them, instead of adding them to {{ambox}}.

--David Göthberg 12:12, 21 September 2007 (UTC)

The protection templates should have the same look whatever namespace they are shown. _→AzaToth 19:15, 21 September 2007 (UTC)

I agree. Personally I think the Wikipedia namespace templates should follow this scheme, but as we are waiting I think this little (temporary?) namespace hack will be helpful. violet/riga (t) 20:44, 21 September 2007 (UTC)

Either all at once, or none at all. _→AzaToth 21:44, 21 September 2007 (UTC)

I support the protection templates and don't care about the background as long as it doesn't get darker. ←Ben^B4 21:57, 21 September 2007 (UTC)

For further discussion about this see the new section #Protection templates, new meta template below. --David Göthberg 22:04, 21 September 2007 (UTC)

Other wikis

Wikibooks has copied the standardization idea with Template:Mbox, and the Polish Wikipedia has followed suit with Szablon:Ambox. Just thought you guys may want to know... Titoxd^{(?!? - cool stuff)} 02:42, 21 September 2007 (UTC)

Haha, the Wikibooks version is funny. Shorter name (Mbox) but wider box (90%). And interesting to see what changes they do. Thanks for the tip Titoxd. --David Göthberg 03:12, 21 September 2007 (UTC)

That reminds me of a certain song by three long-haired little lads. Nice to see it being adopted elsewhere. violet/riga (t) 07:48, 21 September 2007 (UTC)

Where did green go?

Well, you can start by complaining to your local traffic authority. They only use red, green and yellow for traffic lights you know. No orange, blue or violet there. (In some countries white is used for some traffic lights for trams and trains.)

Anyway, yes green is a very nice colour. But currently all the message boxes that were green were already covered by the other categories. We might come up with a usage for green in the future. I can imagine green boxes that tells that an article is featured status or similar. So think of it like we have reserved the green for even more great usage in the future!

--David Göthberg 19:52, 21 September 2007 (UTC)

In the meantime, I have banned the ambox colour code from my screen. I've gone into my monobook.css page and added code to turn all of the amboxes green. --  Denelson83  20:04, 21 September 2007 (UTC)

Even better: If project page templates are standardized, green is an easy choice for the {{policy}} template, which is used only in official policies. szyslak 20:08, 21 September 2007 (UTC)

That's what I'd like to see it used for too. violet/riga (t) 20:43, 21 September 2007 (UTC)

Green means good, not white. White means death to some cultures, hence British ambulances being repainted yellow. violet/riga (t) 20:43, 21 September 2007 (UTC)

Not having green is an NPOV violation? Surely that is a joke. At any rate, we're reserving green for a class of templates that doesn't logically belong in the other categories.--Father Goose 21:05, 21 September 2007 (UTC)

Well, I wanted indigo but they told me that was WP:UNDUE weight. ←Ben^B4 21:50, 21 September 2007 (UTC)

Indigo is unnecessary because it's a shade of blue, one of the three major hue groups already included in this code. If we really wanted only four colours in this ambox scheme, they should be red, yellow, green and blue. --  Denelson83  04:00, 22 September 2007 (UTC)

Ehm, you know, red/green colour blindness is the most common colour blindness. --David Göthberg 04:29, 22 September 2007 (UTC)

BTW, David Göthberg missed the point by suggesting that green boxes be used for the "article is featured" message. That message is not used in article space. I want to see article-space messages with green boxes.

Here's my idea for a four-colour code. Red for deletion, yellow for content issues, green for style issues, and blue for everything else. Green would mean "the content is good, it just needs to be proofread." --  Denelson83  05:40, 22 September 2007 (UTC)

Using green for style issues would imply that we don't consider style issues to actually be a problem. In reality, they can be very annoying problems that greatly hinder the reader's ability to effectively use the article. —Remember the dot ^(talk) 05:53, 22 September 2007 (UTC)

Here's why we chose red-orange-yellow-blue instead of red-green-yellow-blue: http://www.safetylabel.com/safetylabelstandards/ansi-signal-words.php Our goal isn't to have a rainbow, our goal is to have clear color symbolism. Red->orange->yellow makes for an easy to understand "severity" heirarchy. Red-green-yellow, by comparison, is just three different colors.

Green is being reserved for some class of templates that can't be fit into the existing heirarchy. We've discovered a use for gray (protection templates); I imagine we'll figure out a good use for green soon enough (policy templates have been suggested).--Father Goose 05:59, 22 September 2007 (UTC)

And discarded. Policy templates are never found in article space either. --  Denelson83  07:22, 22 September 2007 (UTC)

But they will be if project-space message boxes are ever standardized. szyslak 07:30, 22 September 2007 (UTC)

Which means all project-space message boxes will go in article space? That doesn't make any sense. --  Denelson83  07:36, 22 September 2007 (UTC)

No, they'd still be in project space. They'd just adopt a stacking format with a sidebar, similar to the article messages. szyslak 07:38, 22 September 2007 (UTC)

People! Work with me here! I want to see green amboxes in the article space. Gosh, you're making my wikimood go into a tailspin. <hyperventilates> --  Denelson83  07:52, 22 September 2007 (UTC)

You can change your own css to show style-issue/needs-proofreading templates in green (per your "four-colour code" explanation above). But your suggestion that green needs to be included in order to complete some hypothetical rainbow effect, is silly. It is as silly as me suggesting that we don't need yellow and that everyone just has RGB bias! The colors were not chosen whimsically, but based on a rationale, as explained in the last comment in this thread: Wikipedia talk:Article message boxes/Archive 1#Informational as an issue. --Quiddity 20:41, 22 September 2007 (UTC)

Look above. I've filtered out the colour code in my CSS. All amboxes now use green, no matter what the message used. --  Denelson83  03:03, 23 September 2007 (UTC)

TheDJ feeds Denelson83 some ritalin. Now go sit in the corner you annoying green man. --TheDJ (talk • contribs) 10:10, 22 September 2007 (UTC)

Crayon colors still in use

The bright crayon-like colors, which still conflict with our longstanding design aesthetic, seem still to be in use in templates currently in implementation, with no modification. What is the status of this? Thank you, Badagnani 22:16, 21 September 2007 (UTC)

Well, there are so many article message boxes that it is likely we have missed to convert some. If you give us the links to those message boxes or to articles that use them, then we can take a look and fix it. That is, list them right here on this talk page. Or, you can be bold and fix it yourself if you are in the mood. --David Göthberg 22:24, 21 September 2007 (UTC)

I think he wants Wikipedia:Ambox CSS classes/Skins. ←Ben^B4 23:17, 21 September 2007 (UTC)

I still don't understand how the current colors remotely "conflict with our longstanding design aesthetic." —David Levy 23:32, 21 September 2007 (UTC)

The consensus seems to be that then new colours are fine. As BenB4 suggests, you may wish to use skins to alter the way they appear for you. -- Flyguy649 ^talk _contribs 23:39, 21 September 2007 (UTC)

The bright crayon-like colors, as it has been pointed out numerous times since they were first implemented, deviate strongly from our long-standing design aesthetic, using muted colors. Please don't pretend you're unaware of this serious issue! Badagnani 23:27, 22 September 2007 (UTC)

If you want the deepest answer, see http://wikimania2007.wikimedia.org/wiki/Proceedings:GP1 (essentially, they're looking into updating the brand as a whole)

I don't think the colors are likely to change until then, unless there is a fairly massive outcry of editors demanding a multi-hued poll (which could end badly indeed..!)

Whilst they don't match the scheme described at WP:COLOR, they do stand out well instead, which is an important thing in many editors view (and a terrible thing in other editor's views). I understand your position (I had a small hand in updating wp:color after the mainpage redesign), and I might even alter my own css, but it looks like we're stuck with the current ambox colors for now.

Personally, the cartoony icons are what irritate me, but I won't get into that ;) --Quiddity 01:18, 24 September 2007 (UTC)

The colors still conflict with our long-standing design aesthetic, which is stated on the page you quoted. Badagnani 05:05, 24 September 2007 (UTC)

April 2006 (when those colors were chosen) is not exactly "long-standing" though. And some of the infoboxes use equally bold colours, e.g. Tom Gordon, so it's not out of the realm of possibility to use a different scheme. I'm not telling you to stop complaining (though offering other options (after reading the threads about color in the talk archives) would be more constructive than just saying you dont like it), but I do think it might be futile. --Quiddity 05:28, 24 September 2007 (UTC)

Some old templates still knocking around

I think you guys have done a fantastic job changing the templates, they look so much better now! I use Wikipedia:Template messages/Cleanup quite a lot and there are still a few on there that haven't been changed over - just letting you know in case you didn't know about them. Thanks, Cricketgirl 22:49, 21 September 2007 (UTC)

Those are intended for the talk: (and specifically covered elsewhere) or image: namespaces. Circeus 22:59, 21 September 2007 (UTC)

Aside from those, there may still be a few unconverted article notices bouncing around. A few days ago I found a couple just by browsing random articles. All of them are likely (a) uncategorized and (b) not listed on Wikipedia:Template messages. I wish we had a "random template" feature, like Special:Random or Special:Randomredirect. szyslak 23:07, 21 September 2007 (UTC)

Special:Random/Template? Titoxd^{(?!? - cool stuff)} 23:09, 21 September 2007 (UTC)

I've been a Wikipedia editor for just over three years, and I can't believe I didn't know about that. On Special:Specialpages, only "Random article" and "Random redirect" show up. Since you pointed that out, I've been surfing through random templates in the hopes of finding that last unconverted article message box. Though I haven't found any message boxes, much less any unconverted ones, I have come across quite a few TFD candidates. It's sad how so many uncategorized templates become orphaned and forgotten, floating around in the WikiEther until someone finds them on Special:Random/Template. szyslak 09:31, 22 September 2007 (UTC)

I've been periodically doing cleanup with category:Uncategorized templates. Circeus 21:53, 22 September 2007 (UTC)

Deletion templates shouldn't be included in ambox standardization

Making the deletion template look similar to other article templates causes them to blend in excessively. Article deletion templates should be differentiated from (not standardized with) other article templates. —dv82matt 00:39, 22 September 2007 (UTC)

While the subject of deletion templates is up again. I really think we should rename the red "serious" issue type to "delete" since it causes confusion. People keep changing orange "content" issue templates to red. And I think this confusion will stay forever if we don't change that name. This was not directed to Dv82matt, I assume you know that the red bar is reserved for delete issues, right?

I suggest we add a class named "ambox-delete" now and then do the change to the delete boxes and {{ambox}} in some week, due to the caching issue. This is the code I would like added to MediaWiki:Common.css:

table.ambox-delete {
  border-left: 10px solid #b22222;       /* Red */
}

It of course uses the same red as "serious" does right now.

--David Göthberg 01:08, 22 September 2007 (UTC)

Would {{notability}} stay red then, or move to orange? It seems orange would be best. -- Flyguy649 ^talk _contribs 01:24, 22 September 2007 (UTC)

{{Notability}} clearly needs to be a reddish-orange. :-P Well, okay, just orange.--Father Goose 02:11, 22 September 2007 (UTC)

Well David, you might have come up with a solution to an unrelated problem but it still leaves us with deletion templates that are visually very similar to, and tend to blend in among other article templates.

I think standardizing deletion templates with all the other article page templates is taking standardization too far. It's putting petty consistency ahead of utility. To take an extreme example we wouldn't do this with the {{copyvio}} template because the copyvio notice needs to be big bold and obtrusive. On the other end of the scale we probably shouldn't include stubs in the ambox standardization because putting them in a box with a colored bar would make them more obtrusive than they should be.

The deletion templates need to stand out visually from other templates that may be on a page. Standardizing them with ambox defeats that. —dv82matt 03:45, 22 September 2007 (UTC)

A couple of thoughts came to mind upon reading this comment. One, both stub templates and the copyvio template have been discussed on this page as candidates for standardization. Two, {{db-meta}} has a different background; I don't think it blends in at all. Perhaps we should consider adding that background color to the other deletion templates? Cheers. --MZMcBride 03:48, 22 September 2007 (UTC)

MZMcBride: That is kind of my evil plan with renaming the red class to "delete". To first make it very clear what it is for, since the misunderstandings seems to hinder the discussion here.

Then (or even now) we can add a pinkish background to the delete class if that is what people want. I would prefer not, but to me it doesn't matter much, since the delete templates anyway are terribly big and intrusive. And perhaps they should be that big and intrusive since they are important.

(I have even seen people here that want the pink background say they don't want the red "serious" class to have pink background "too" since that would dilute the effect on the deletion messages. Apparently they thought that red was also used for other issues than delete.)

So again: The RED "serious" class is ONLY for DELETION related message boxes.

--David Göthberg 05:11, 22 September 2007 (UTC)

@MZMcBride, yeah the db-meta template is somewhat better with its salmon background. It should probably also changed so that it doesn't stack tightly with other templates. A little whitespace between it and other templates that may be on a page, would help to further differentiate it.

I don't see any good reason to include deletion templates in this standardization drive but as long as the deletion templates don't become too obscured in the process I can live with it. —dv82matt 10:35, 22 September 2007 (UTC)

I think I'd rather not see the deletion templates included in the ambox standardization...they need to STAND OUT from all other templates. Red probably should probably just be excluded from the ambox coloring scheme entirely. —Remember the dot ^(talk) 18:11, 22 September 2007 (UTC)

Given the redness of the red we're using and the size of the deletion templates, I'd say they're impossible to ignore. The speedies have additional background coloring that makes them even more prominent.--Father Goose 20:30, 22 September 2007 (UTC)

Template:Hangon

I don't think it should be using a red bar. Thoughts? --MZMcBride 02:11, 23 September 2007 (UTC)

Well, it's always going to appear in tandem with a red-bar speedy template. It's not a "deletion template", logically speaking, but I'd say it's a deletion template rider, so the red makes sense to me, visually and otherwise.--Father Goose 02:57, 23 September 2007 (UTC)

Yes, it is very much "deletion related" so should be red. --David Göthberg 10:32, 23 September 2007 (UTC)

Red looks good to me. Red is for serious issues such as deletion, and the creator of the page requesting that the page not be deleted is certainly a serious issue to the exact same degree as deletion. Pyrospirit (talk · contribs) 15:07, 23 September 2007 (UTC)

New templates don't combine well with {{for}}

I've just added a merge proposal to the page Oxbridge, which uses the {{for}} template. In my opinion, the two templates do not combine well, and we need to add extra space between them. This is presumably the case for most of the other "see also" templates Bluap 13:15, 22 September 2007 (UTC)

I can't really see a problem to be honest. violet/riga (t) 14:06, 22 September 2007 (UTC)

The For line is glued to the merge message. Though ambox margins should not be changed (for stacking purposes), {{dablink}} (the template used by {{for}} and other disambiguation templates) could use a little top and bottom margin. — Edokter • Talk • 14:10, 22 September 2007 (UTC)

I think changing the <div> to a <p> in the dablink template ought to fix it; that way it'll get the same top margin as any other paragraph. The alternative, of course, would be to add an explicit top margin to the dablink class in Common.css. —Ilmari Karonen (talk) 14:38, 22 September 2007 (UTC)

One way to fix this would be by adding upper margins (.2 em seems to work) to common.css's dablink class. It doesn't look too good when you have one disambiguation notice on top of the other, however. Gracenotes^T § 23:46, 22 September 2007 (UTC)

Oh, great. So now our solution to one template having screwed up margins is "change every other template to compensate"? You're going to go around adding a top margin to every infobox template, too? – 217.44.23.69 21:31, 23 September 2007 (UTC)

Well, the ideal solution would be to use CSS adjacent sibling selectors to add a margin only after the boxes but not between them. Unfortunately, that won't work in all browsers. Still, it might be worth considering anyway, given that, done right, it shouldn't make things any worse than they are now in those browsers that don't support it. Something like:

table.ambox + .dablink { margin-top: 0.4em; }

ought to do it for dablinks, if I remember the syntax right. Do we have a general CSS class for infoboxes? —Ilmari Karonen (talk) 17:12, 24 September 2007 (UTC)

1. The dablinks should be first on the page (per WP:WAI), so it would rather be

   .dablink + table.ambox  { margin-top: 0.4em; }
   

2. Yes, we do have a general CSS class for infoboxes… It's called "infobox". –Ms2ger 18:27, 25 September 2007 (UTC)

Stacking problems

Is this supposed to happen?

Trivia sections are discouraged under Wikipedia guidelines. (August 2007) The article could be improved by integrating relevant items into other sections and removing inappropriate items.

Rich Farmbrough, 12:03 24 September 2007 (GMT).

No. Per clear consensus, the trivia tag shouldn't be used at the top of the article (which the nonstandard width is intended to discourage); it should be placed at the top of the relevant section. In the uncommon circumstance in which it's stacked with another template in that section, the parameter width=full will apply the standard width. —David Levy 12:13, 24 September 2007 (UTC)

How about the text left justification of notable, for example:

Rich Farmbrough, 13:23 24 September 2007 (GMT).

The {{primarysources}} tag should be using image=none rather than image=blank. Or they should have a proper icon. I think I'll fix it and see if anyone complains. —Ilmari Karonen (talk) 17:23, 24 September 2007 (UTC)

By the way, why is {{notability}} red? I thought that was only for stuff like imminent deletion. Shouldn't it be orange? —Ilmari Karonen (talk) 17:33, 24 September 2007 (UTC)

Yes, please fix (it's fully-protected). --Quiddity 18:31, 24 September 2007 (UTC)

There was a discussion above, suggesting that ppl think notability is in the deletion group. Rich Farmbrough, 07:29 25 September 2007 (GMT).

Y Done -- Flyguy649 ^talk _contribs 18:35, 24 September 2007 (UTC)

Thanks. Rich Farmbrough, 07:29 25 September 2007 (GMT).

Stubs all over again

You may remember the issues around the first stub tag of a stack needing double blank lines - in case it was preceded by a nav-box - well we seem to have the same issue with the first and last AMB of a stack running into preceding or succeeding boxes. IS this worth implementing the CSS fix suggested for stub-tags? Rich Farmbrough, 07:29 25 September 2007 (GMT).

(See, for example, Xenogears) Rich Farmbrough, 08:20 25 September 2007 (GMT).

See also the thread #New templates don't combine well with {{for}} above, about the same thing but with dablinks. (I don't know the answer) --Quiddity 02:59, 26 September 2007 (UTC)

Can we do away with the disputed tag, now?

It's been nearly a week now since the last "OMG stopit stopit stopit" knee-jerk reaction,five days since Tyrenius vocalized here, and it seems at the very least the spirit of the [whatever it is supposed to be] is not really under any meaningful challenge anymore. Circeus 15:10, 23 September 2007 (UTC)

Well, I still think whoever came up with the design was thinking only of these message boxes in relation to each other and not, I dunno, the rest of the article, with the result that they are far too wide and look crap next to infoboxes; for that reason alone, I still think all this "standardization" that isn't is completely useless and should never have been done in the first place – 217.44.23.69 21:28, 23 September 2007 (UTC)

Okay fine. But can you really state that there isn't consensus for this change?--Ybbor^Talk 21:38, 23 September 2007 (UTC)

If my opinion counts towards that consensus or lack thereof, I have to agree with anon. I think too much attention was paid to the tags themselves rather than how they looked with the rest of the article. There's always monobook.css customization, but Wikipedia's public image has nothing to do with long-time users customizing their accounts. I'm not necessarily suggesting we go back to the old tags, but maybe some more work is needed. Remember, I'm not necessarily saying we should go back -- that doesn't mean its not an option. I do appreciate all the work that went into these, and they really do look great -- just not so much in practice.

Equazcion • argue/improves • 23:03, 09/23/2007

The way I see it, we've always had issues with the way different types of templates interact. In the pre-standardization days, haven't most of us seen a message box where the right half is just an outline on top of an infobox or other sidebar, with the text and pastel shading chopped off? Even if we don't take that into consideration, the problems pointed out by Equazcion are inevitable with a big change like this. It's not a sign that standardization was implemented too quickly or without consideration for Wikipedia's overall design scheme. The solution is to resolve any bugs or inconsistencies that cause disharmony between the tags and the rest of the article. szyslak 05:03, 24 September 2007 (UTC)

The bright, crayon-like colors, which conflict with our long-standing design aesthetic, have not been modified or addressed in any manner, thus there is still a dispute over this important and unresolved issue. Badagnani 05:06, 24 September 2007 (UTC)

About this "long-standing design aesthetic" you've been harping on: We really don't have a "design aesthetic". We're an open-source, free-content wiki that runs on open-source, free-content software. Wikipedia's aesthetic arose organically, with no vast plan for its design. So unless the Wikimedia Foundation hires a paid, professional web designer with carte blanche to overhaul our look and the authority to take WP:OFFICE actions to carry it out, there is no "design scheme". szyslak 05:36, 24 September 2007 (UTC)

Templates collding with the infoboxes is a technical issue unrelated to the standardization (the old templates had the same problems).

The "design aesthetic" is exactly what we're trying to improve here. Sure, some people liked the old piecemeal design, but it appears that a larger number of people like the new standardized design. That's not to say that it can't be improved further.--Father Goose 05:43, 24 September 2007 (UTC)

See the thread #Crayon colors still in use above for my replies to Badagnani's comments there.

As for the float/overlap (images, infoboxes, dablinks) issue, that needs to be looked at and fixed still, but I believe David Gothberg and the other coders are aware of the problem, and are hopefully trying to determine a solution (?). That's our only real issue left to work on, I believe. (See Template talk:Ambox#Needs to clear for the last mention, afaik). If they can't fix it, we can take it to VPt. --Quiddity 05:58, 24 September 2007 (UTC)

Regarding the float/overlap: Yes, we are aware of the problem and have been aware of it for years since the same problem occurs with all kinds of boxes, even with the PRE-tags. There isn't any known good solutions, only bad. So it is hard to decide which bad solution to use. And yes, as Quiddity pointed out, there is an ongoing discussion about this at Template talk:Ambox#Needs to clear and I think in some places at this talk page too. --David Göthberg 14:54, 24 September 2007 (UTC)

Yup, at Wikipedia talk:Article message boxes/Archive 7#Conflict with floated elements. --Quiddity 18:34, 24 September 2007 (UTC)

Just to clarify, I wasn't referring to the float problem at all. I was only talking about the aesthetic. When more than one template is on a page, I find they clash with the page. It's a lot of bright color on a page that's otherwise grayscale. And yes, Wikipedia does have a design aesthetic -- it's gray. The logo is a combination of grays, the background is a pattern of light grays, the templates all used to be gray. With good reason too -- it's supposed to have an understated, subtle, library/educational-institution type appearance. This rainbow we're suddenly adding is totally out of place.

Equazcion • argue/improves • 15:52, 09/24/2007

The templates all used to be gray? Huh?! —David Levy 16:05, 24 September 2007 (UTC)

The maintenance tags were, yes, to my recollection... but more accurately I meant that they didn't have these bright colors. The ambox templates are gray too, they just have those color bars, which when stacked in an article form this rainbow of color that's painful to look at, and just doesn't look right on the page.

Equazcion • argue/improves • 17:22, 09/24/2007

Which templates were gray? They were all sorts of colors, and now they're gray. In my opinion (and the consensus opinion), shifting the color to a small bar on the left (rather reminiscent of folders with color-coded tabs) is an enormous improvement. —David Levy 18:34, 24 September 2007 (UTC)

Trivia and unreferenced, and I'd have to research that some more but I'm pretty sure most of the maintenance tags were the same, or close to the same:

There were certainly none with the bright colors of the ambox color bars.

Equazcion • argue/improves • 19:07, 09/24/2007

{{disputed}}, {{totallydisputed}}, {{POV}}, {{POV-check}}, {{Totally-disputed-section}}, etc... certainly not subtle nor subdued. Titoxd^{(?!? - cool stuff)} 19:12, 24 September 2007 (UTC)

Most of those were much more subdued. They had to be because they're background colors. These colors used as ambox color bars could never be used as background colors. You've also only listed just a few that demonstrate your point, which I also did, so that doesn't really say much. Even if some tags were subdued and some weren't, the fact is that now they all aren't.

Equazcion • argue/improves • 19:31, 09/24/2007

The templates I listed are very, very commonly used, which makes my point that not all of the commonly-used templates were gray, or gray-looking. Also the cleanup tags didn't look gray in any monitor I saw them.

I guess it depends on your definition of subdued: I consider a colorful background to be much more protruding into an article than a narrow vertical bar with a gray background. Titoxd^{(?!? - cool stuff)} 19:36, 24 September 2007 (UTC)

The cleanup tag color is sampled in my post above, as the background for "Sample text". That doesn't look gray to you? Besides which, the precise color isn't the point. The point is that they were subdued, and on the whole, maintenance tags were generally much less overpowering than they are now. That's my opinion.

Equazcion • argue/improves • 19:45, 09/24/2007

That looks gray to you? (You omitted the border, incidentally.) —David Levy 19:51, 24 September 2007 (UTC)

Yes it does. And, once again, that's not the point.

Equazcion • argue/improves • 19:57, 09/24/2007

That bar looks light-purple to me. And being eyecatching is part of the point, as the articles need to be improved until the (templated) objection is fixed. We don't want them to be easily ignored. Though as has been said, it's all quite subjective. --Quiddity 20:05, 24 September 2007 (UTC)

No doubt they're eyecatching, but the same could be said for a photo of a severed finger. "Tastefully eyecatching" is, I think, what we're going for. I don't believe we're there. Keep in mind though I'm really only talking about when there's more than one tag stacked. Just one tag looks fine, but when they're stacked, it just gets to be too much color.

Equazcion • argue/improves • 20:18, 09/24/2007

Well, there is Template:Articleissues, but I personally think that just makes things more complicated, e.g. Capoeira. Again, a subjective call, and all of which is contested by the "fix it, don't tag it" perspective, and the "move all tags to talkpages" perspective, and probably others (it's a wonder we agree on anything around here!). --Quiddity 20:27, 24 September 2007 (UTC)

No, I was not suggesting replacement of all tags with a single general tag. I was suggesting that the old tags better suited the encyclopedia, or that ambox needs to be redesigned. But yes it is subjective. It's only my opinion.

Equazcion • argue/improves • 20:40, 09/24/2007

The {{trivia}} and {{unreferenced}} templates were blue, which was the standard color for cleanup tags. —David Levy 19:51, 24 September 2007 (UTC)

And again. The specific color is not the point. You're allowed to disagree with me about the old tags' subtlety vs the new ones, but don't bring nitpicky arguments, because they won't shut me up. I can nitpick with the best of 'em. :)

Equazcion • argue/improves • 19:57, 09/24/2007

I don't see how noting the distinction between gray and colored is "nitpicky," and I'm certainly not trying to shut you up.

And yes, I disagree with you on the subtlety issue. To me, neither the old tags nor the new tags are more eye-catching. The new ones are simply far less ugly. —David Levy 02:56, 25 September 2007 (UTC)

Back to the thread topic, Yes, please can we remove the disputed tag now? --Quiddity 00:50, 27 September 2007 (UTC)

Y Done I have removed the disputed tag as it seems that the changes have broad support, and although there are discussions ongoing with respect to a "final" look, I don't see anyone seriously advocating restoring to old look. -- Flyguy649 ^talk _contribs 00:55, 27 September 2007 (UTC)

Enabling Clear: both

I am planning to set the CSS style {clear: both} on this template later tonight, following the discussions here and here. — Carl (CBM · talk) 18:43, 25 September 2007 (UTC)

CBM: Don't set that style, we now have a better solution! User:Dispenser suggested a much better solution that at least works perfectly in all my browsers. See examples that shows the new solution at Template talk:Ambox#Needs to clear.

--David Göthberg 01:58, 26 September 2007 (UTC)

OK, that definitely warrants some discussion. Let's talk about it at Template talk:Ambox#Needs to clear to keep the discussion together. — Carl (CBM · talk) 02:09, 26 September 2007 (UTC)

Why not transclude {{clear}} into {{Ambox}}? Rich Farmbrough, 13:50 26 September 2007 (GMT).

That should work, instead of the CSS change, although someone would have to verify it doesn't affect the stacking. But it would be better to find an acceptable fix that changes the box width, rather than making the boxes clear: both, because the clearing will add unattractive white space in some situations (which is better than overlapping templates, but not ideal). There is a proposed fix at Template talk:Ambox#Needs to clear that is being discussed as an alternative to making the box clear. — Carl (CBM · talk) 13:58, 26 September 2007 (UTC)

Rich and CBM: Well, {{clear}} internally uses the CSS style "clear: both;" to do its work. So to use {{clear}} would just be a less efficient way than to use the CSS style directly. But as both I and CBM now pointed out, we now have a better solution. See Template talk:Ambox#Suggestion by Dispenser.

--David Göthberg 14:41, 26 September 2007 (UTC)

Suggestion

Does anyone think that having a "stronger" color for {{Hoax}} would be useful? I understand it's not a deletion request, but if it IS a hoax, the next step is pretty obvious... 68.39.174.238 02:52, 27 September 2007 (UTC)

I sort of know what you mean... but either it's not a hoax, in which case it's a false alarm, or it is one, in which case it's an AfD, prod, or speedy candidate.--Father Goose 06:15, 27 September 2007 (UTC)

Template:Original research

Red, really? --MZMcBride 10:10, 25 September 2007 (UTC)

And {{POV}} and {{blpdispute}}, too. Jossi has changed templates that deal with core content policies (WP:NOR, WP:NPOV and WP:BLP) to red. Haven't we pretty much agreed red is just for deletion? szyslak 10:18, 25 September 2007 (UTC)

I thought so too... those policies deal with content, so the template should have the 'content' color. — Edokter • Talk • 10:46, 25 September 2007 (UTC)

Yep. Those may be core content policies, but they're content issues all the same. Orange. Red should be reserved for "this has to be dealt with right now" not "this might be a problem, we'll have to discuss it further". Unambiguous BLP, NPOV, OR violations should be removed on the spot and enforced, without using a template.--Father Goose 21:14, 25 September 2007 (UTC)

Fixed, and I've notified Jossi of this discussion. —Ilmari Karonen (talk) 21:44, 25 September 2007 (UTC)

I am not sure this works well. We need a distinction between a minor content issue, such as lack of inline citations ({{citations missing}}, and serious content issues such as violation of core content policies such as {{POV}}, {{OR}} and others. Readers need to be alerted that the content in an article may be disputed, not only that has minor fixable problems. Can another color + icon be used to differentiate these ≈ jossi ≈ (talk) 22:13, 25 September 2007 (UTC)

Well, like I said above, if it's a really serious violation of those policies, we don't need a tag; the material should be removed. For more borderline cases that don't need to be fixed immediately, I think orange is fine. And if it's an active content dispute, I think the red color and the 'stop' icon are antagonizing.--Father Goose 22:37, 25 September 2007 (UTC)

Mmmm... I would agree with you in WP:BLP violations, in which such a caveat to "remove on-sight" is clearly specified in the policy. OTOH, a POV tag, is a POV tag, usually resulting in a vigorous debate in talk; same about a OR dispute. In these cases, we need to differentiate between, "Hello reader, we need to improve this article, but read with confidence as it is not major" and "Hello reader, this article may not be compliant with Wikipedia content policies, and as such its contents may be dubious. Thread with care". Don't you think? ≈ jossi ≈ (talk) 22:45, 25 September 2007 (UTC)

When I see glaring POV and OR, I remove it, and I'll bet you do, too. If the removal is contested (and we're not talking about a single kook cruising for a ban), then it's a content dispute, and again, I think it's just antagonizing to label the dispute with an "OMG, serious problem!" template. I sometimes see POV and other dispute tags on things that strike me as totally fine, but are just contentious issues.

As a reader, I feel sufficiently warned when I'm told "not everyone agrees about this". "This is unsourced" strikes me as being every bit as serious as "This is disputed". If something is disputed and unsourced, remove and enforce.--Father Goose 08:46, 26 September 2007 (UTC)

We could simply use the exclamation point icon, and the red color, can't we? That is what I propose we do. ≈ jossi ≈ (talk) 22:47, 25 September 2007 (UTC)

Yep. Those may be core content policies, but they're content issues all the same I don't think so, Father Goose, unless you are editing a different Wikipedia than I am. :) ≈ jossi ≈ (talk) 22:49, 25 September 2007 (UTC)

I hope I am understood here. This change is a wonderful one, but I am not sure it was widely discussed to warrant a "this is the way it should be" attitude. Some flexibility in receiving and accepting feedback from committed Wikipedians, should be welcome. ≈ jossi ≈ (talk) 22:53, 25 September 2007 (UTC)

As a "committed" Wikipedian, I can say that I'd rather have the red color stay only for deletion issues. POV issues can be fixed, OR can be verified, sourced, or removed, but deletion is more permanent. Titoxd^{(?!? - cool stuff)} 01:13, 26 September 2007 (UTC)

Ok, I said it before but didn't get much response. I suggest we change name of the "serious" class to "delete" to avoid confusion. So I suggest we add the code here to the MediaWiki:Common.css and then wait some days for the browser caches to be updated and then switch over to use this code and then remove the "serious" class.

table.ambox-delete {
  border-left: 10px solid #b22222;       /* Red */
}

Let's get rid of this ever occurring confusion once and for all.

--David Göthberg 10:31, 26 September 2007 (UTC)

Agree. --Quiddity 17:20, 26 September 2007 (UTC)

Agree. —Ilmari Karonen (talk) 19:07, 26 September 2007 (UTC)

All that said, I think Jossi does have a point: it would be kind of nice to have separate classes for minor content issues like {{globalize}} and major ones like {{blpdispute}}, {{totallydisputed}} or {{hoax}}. Of course, then it becomes a question of where to draw the line. Jossi's suggestion of defining "major" content issues as violations of the core content policies would be one possibility; my personal inclination would be to lean in a more reader-oriented direction and consider a notice "major" if it should serve as a warning to the reader, rather than as a mere request for editors. Of course, to some extent both of those criteria tend to agree. —Ilmari Karonen (talk) 19:07, 26 September 2007 (UTC)

Well, I think we already have a solution to that. The colour scale is there to indicate severity. So I think it should be okay to use yellow for the really minor content issues. I don't think we need to draw a that hard line between style and content issues. So for me yellow is more like "this article needs some fixing" while orange means "readers be aware, this article has issues".

--David Göthberg 21:12, 26 September 2007 (UTC)

Yes, we need to think of the reader, rather than of our editors only. Red is good to attract the attention of our editors, but we also need to warn our readers when the article has serious content issues. ≈ jossi ≈ (talk) 21:47, 26 September 2007 (UTC)

So, would anyone oppose changing the meaning of yellow to "style and minor content issues"? (I think we can still keep "style" as the class name, unless anyone has better suggestions?) —Ilmari Karonen (talk) 18:35, 27 September 2007 (UTC)

Ilmari: I agree with your suggestion.

--David Göthberg 20:07, 27 September 2007 (UTC)

Unity of design

We have the following issues breaking the unity of design within this project:

• Icon/no icon/two icons
• Text layout
• Icon reflects severity/icon indicates problem/icon indicates solution

Comments? Rich Farmbrough, 10:52 25 September 2007 (GMT).

• Always have no icon, and left-align the to remove the gap. Icons only lead to profuse discussion among everyone who thinks their icon contributes just a fraction more than everyone elses. Witness this talk page. All icons do is give a reason for people to play, without actually providing even a fraction of the information from i) the text of the tag and ii) the links it contains. For instance, the first thing that a question mark in a spyglass says to me is "This article may be a Sherlock Holmes novel". To misquote a famous man, I would like all amateur graphics editors to have only one hand. "We could use this icon. Or on the other hand...".
• Per my above, left-align everything. Have a rule that if the main body of the text runs to more than one line, then the template is blanked pending a re-phrasing to fit it onto one line. There may be an additional one line of 'Please edit this article'-like text and a useful policy/guideline link or two.
• Severity of icon is dispensed with by removing all icons. Icon reflects only what it does in the eye of the beholder. Splash - tk 19:42, 25 September 2007 (UTC)

I personally would leave the icon issue in its present condition: informally standardized. There are some times when I think the icon adds something (I like the merge icons, for instance), other times when it adds nothing, and yet other times when an icon might be good but I don't like the one being used. The 'stop' hand on the current version of {{original research}} is overblown, for instance -- but OR is an orange (content) not red (deletion) issue anyway. I haven't seen a case where double icons are necessary.--Father Goose 21:06, 25 September 2007 (UTC)

A lot of the current templates do; eg {{current spaceflight}}. I like the flexibility of the current design, standardisation isn't supposed to make all message boxes identical. On {{original research}} perhaps something like the middle bubble in Image:Speech balloon 3 types.svg would be more suited? — Jack · talk · 01:23, Wednesday, 26 September 2007

Oh, I see. The spaceflight template looks all right with those two icons, although I have wondered in the past why we have such an explosion of "current" templates (current spaceflight, current sports event, current hurricane, etc.) The OR template is back to an orange exclamation point for now and looks okay. The {{peacock}} icon is garish and distractingly literal, though.--Father Goose 08:22, 26 September 2007 (UTC)

I agree. These issues need to be addressed if we're going to complete this standardization. We're only half way there. When the new style was first employed, the inconsistent icon styles was the thing that stood out the most to me. It sounds like a lot of people are against icons all together. I think if we use nice-looking subtle icons that all matched, people will be more open to it. And you can't say icons don't add anything to the template, because when see a article tagged with something, I don't usually read the message but look at the color/icon to tell me what the article's issues are. With this standardization, icons are now more important than ever since without them all the tags (of the same color) look the same. - Rocket000 02:34, 26 September 2007 (UTC)

The icon choices are entirely based on what is available under a suitable licence (same as at List of overviews). See the top section at Wikipedia:Icons for the dismal selection we have to choose from. (most of the rest of the page is spam. I tried to do some cleanup in April but got depressed). --Quiddity 02:51, 26 September 2007 (UTC)

Actually if we decide what icons we need, someone will make them. Rich Farmbrough, 10:08 27 September 2007 (GMT).

Wot, no! If you make them, they will get used. Shurley. Splash - tk 14:28, 27 September 2007 (UTC)

I agree that we could improve a lot of the icons we're using, and use them more consistently, but I don't think we need to standardize them as rigidly as the templates themselves.--Father Goose 08:22, 26 September 2007 (UTC)

deletion templates

I really think the deletion template should blink just so people don't miss them. If you don't want the whole thing to flash, maybe just have a big red stop icon that blinks. I would hate to miss one of these warnings and put a bunch of work into an article just to have it deleted later. Think about it. - 205.215.119.104 20:03, 26 September 2007 (UTC)

It doesn't seem likely that you'll overlook a big red deletion template. More likely is that you'll put work into an article before someone tags and/or deletes it.--Father Goose 22:43, 26 September 2007 (UTC)

No offense, but that's probably the worst idea I ever heard. - Rocket000 00:33, 28 September 2007 (UTC)

NO. Please, no blinking icons. This is not a circa 1996 Geocities personal website. Horologium t-c 02:36, 28 September 2007 (UTC)

Ambox CSS code changes

{{editprotected}}

There seems to be consensus for some changes/improvements to the ambox CSS classes in MediaWiki:Common.css.

1. Change the "width" and "margin" in the ambox main class so that article message boxes do not collide with infoboxes, image thumbnails and other right/left floating objects. This still means that the article message boxes will have 80% width in most cases. Per discussions and tests at Template talk:Ambox#Suggestion by Dispenser. Here is the new code:

table.ambox {
  width: auto; 
  margin: 0 10%;
  border-collapse: collapse; 
  background: #fbfbfb; 
  border: 1px solid #aaa; 
  border-left: 10px solid #1e90ff;       /* Default "notice" blue */
}

2. Change the name of the "serious" class to "delete" to avoid the ongoing confusion. But due to the caching of CSS pages instead first add the "delete" class name and then we will some days later update {{ambox}} and the templates that use this class and then we will remove the "serious" class name. Per discussion at #Template:Original research. So right now just add the "ambox-delete" class name. Note: Don't miss the comma! (I always miss that comma myself.) Here is the new code:

table.ambox-delete,
table.ambox-serious {
  border-left: 10px solid #b22222;       /* Red */
}

3. Remove the green "ambox-growth" class since it is no longer used. Per discussions at Template talk:Ambox#Removal of growth color and Wikipedia talk:Article message boxes#Where did green go? and several other places. This is the code to remove:

table.ambox-growth {
  border-left: 10px solid #228b22;       /* Green */
}

That's all.

--David Göthberg 10:22, 27 September 2007 (UTC)

Y Done — Edokter • Talk • 13:33, 27 September 2007 (UTC)

Partially reverted, see section below. :-( —Ilmari Karonen (talk) 18:32, 27 September 2007 (UTC)

Ilmari: Yes, you were right to revert. The consequences were worse than we thought. And I who thought pretty much all the article message boxes contained enough text to make them full width. Apparently I was wrong. (Yay! We have boxes with short text! I always wanted them to have less text, until today...)

--David Göthberg 20:18, 27 September 2007 (UTC)

Right, is ragged right right?

Looks untidy, na, when one of the proclaimed purposes was tidiness? In some ways, it looks untidier than the incongruous widths there were before, since at least those were usually centre on one another. Obviously, don't impose a defined stack position for each template, but see if a better hack can be found than the present Splash - tk 14:26, 27 September 2007 (UTC)

Yes it looks awful, with the colour bar on the left and ragged right. One of the great features of the new design (stacking) is needed to make the other possibly great feature (colour bar) work. And the icon disparity becomes more visually intrusive.

This article does not cite any references or sources. (July 2006) Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed.

This article or section may contain original research or unverified claims. Please improve the article by adding references. See the talk page for details. (July 2006)

ZOMG Rich Farmbrough, 17:06 27 September 2007 (GMT).

Agreed. Looks worse than the overlap. E.g. 3 stacked templates (looks almost intentional, hence doubly confusing). --Quiddity 18:19, 27 September 2007 (UTC)

Ewww, this is not how it's supposed to look. Something's broken here. —Ilmari Karonen (talk) 18:22, 27 September 2007 (UTC)

I've reverted the change that caused this. I think the problem in that "width: auto" means something different for tables than it does for divs. Anyway, here's how it looked before the revert. —Ilmari Karonen (talk) 18:31, 27 September 2007 (UTC)

Yes, it does mean something different for tables. I was going to suggest a revert due to the large number of complaints. — Carl (CBM · talk) 18:37, 27 September 2007 (UTC)

So, any suggestions on what to do now? Should we change {{ambox}} to wrap the table in a div, or is there some way of persuading a plain table to maximize its width subject to margins? —Ilmari Karonen (talk) 18:41, 27 September 2007 (UTC)

Create a table.ambox css class, and a separate div.ambox class? Maybe that could work. Titoxd^{(?!? - cool stuff)} 18:47, 27 September 2007 (UTC)

I already tried wrapping in a div. It didn't work. We either need to fully use a div and do away with the table, or we should use clear:both; i guess. --TheDJ (talk • contribs) 18:49, 27 September 2007 (UTC)

No, I mean different style definitions for different elements. Use clear:both in divs, and don't use it in tables, or vice versa. Titoxd^{(?!? - cool stuff)} 18:56, 27 September 2007 (UTC)

"clear: both" ought to work with tables too, if we want to go down that route, but I thought the idea was to avoid doing that? In any case, wrapping the boxes in a <div class="amboxwrapper"> and adding the following styles does seem to work:

div.amboxwrapper {
    width: auto;
    margin: 0 10%;
}
div.amboxwrapper table.ambox {
    width: 100%;
}

That is, it works in the sense that the boxes look the same as before. Unfortunately, in Firefox at least, it doesn't actually fix the float overlap problem: in fact, it makes it worse, since the boxes now have a hard 10% left margin. :-( —Ilmari Karonen (talk) 19:01, 27 September 2007 (UTC)

Yes, that's exactly what my experience was as well. I have an idea. Why not use "clear:left; display:block;" ??? It's somewhat of a tradeoff, but since the biggesst readability issues with the display:block method are with left aligned floats, and the biggest issues with clearing on the larger infoboxes etc to the right (where a bit of the background box gone missing, is considerably less annoying then on the left side), I think it might actually work pretty well. --TheDJ (talk • contribs) 19:16, 27 September 2007 (UTC)

User:TheDJ/Sandbox Test with clear:left; display:block I'm really not that bothered by the actual box overflowing into the right float. It's considerably less annoying to me then most of the other solutions when I'm trying to read an article. Sure it's not proper, but as far as I can tell, neither div or table in Firefox or Safari can accurately fix this, and we need to make a choice somehow. --TheDJ (talk • contribs) 19:21, 27 September 2007 (UTC)

NB. it also behaves consistent across browsers with those two options, something we cannot say by a longshot with the autowidth and margin options we tried the past 2 days. --TheDJ (talk • contribs) 19:29, 27 September 2007 (UTC)

(unindent) Looks good on Firefox and Opera, overlaps infobox on Konqueror. :-( Anyone with Safari and/or IE want to test this? —Ilmari Karonen (talk) 19:29, 27 September 2007 (UTC)

Safari overflows the text into the right float (behaves perfect on the left float). And the table autosizes to the full width of the text (looks really bad on templates with very long lines, like the stuff we saw earlier today) --TheDJ (talk • contribs) 19:34, 27 September 2007 (UTC)

Opera simply adds a clear:both to the div, as it did to the table. --TheDJ (talk • contribs) 19:37, 27 September 2007 (UTC)

IE6 with the amboxwrapper clears, and takes what seems to be the maximum page-width if it has ambox with long lines. (but does not extend page-width as Safari did). --TheDJ (talk • contribs) 19:59, 27 September 2007 (UTC)

Another possibility is a table within a table or a div within a table: Template talk:Ambox#New suggestion. My prototype there is kludgy but it might be fixable.--Father Goose 06:11, 28 September 2007 (UTC)