Template talk:Box-header/Archive 1

This is an archive of past discussions about Template:Box-header. 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.

Is it used so the edit template doesn't produce a redlink? Anything else? Is that useful? --MarSch 2 July 2005 15:41 (UTC)

I can't remember if I tested it the other way, I was concerned that it may spit out the ed template code if no variable was passed. You could try it the other way and use &action=purge to see the changes. Slike2 2 July 2005 21:14 (UTC)

That would probably be a good thing. Error messages are good. Otherwise people might never know that an argument should be passed. I'll eliminate them. --MarSch 3 July 2005 11:12 (UTC)

It seems not to break anything :) Now what about the excessive use of padding and margins. I really hate all those small adjustments. It makes it difficult to change anything. Specifically I noticed that the vertical spacing is different from the horizontal spacing between boxes. I would like to fix this, but perhaps you can clean this up? --MarSch 3 July 2005 11:17 (UTC)

The spacings are due to the differences between % and em - the two divs which cause both sides to float are set to some arbitrary percentages adding up to between 95 and 99%, which means there's a 5-1% gap between the boxes. This means that the actual difference changes based on browser size. The vertical spacing is defined by the box margins, and it's in em. Basically, it's not the box's fault :) (or so I believe). You could try setting the divs to equal 100%, or 99.9%, and add a padding-left:???em; to the div which is floated right, to make it more consistent. Slike2 3 July 2005 23:29 (UTC)

The ed2 does break some things, (Wikipedia:Wikiportal/Computer_and_video_games - note the edit in the main box showing "{..."), but that may not matter because you may want to enforce the each box has a subpage thing. Slike2 3 July 2005 23:33 (UTC)

Trevor fixed it by creating that page. --MarSch 4 July 2005 13:21 (UTC)

I like that the edit link is now located on the header bar. However, the recent formating changes have had an odd consequence: wherever an image is present in a box, no matter its formating, the text is forced lower. I'm not sure why this is, and I have closely checked it. I'm tempted to revert it now, but I'm hoping Go For It!'s about to check it out. Aside from that, the new edit link is sometimes hard to see, depending on the box header's background colour (cf. Portal:Art).--cj | talk 10:59, 29 December 2005 (UTC)

Okay, I'm checking it. Go for it! 13:54, 30 December 2005 (UTC)

I couldn't even see any image formatting glitch. But I did notice that some text was getting forced lower, especially in category and list boxes. It seems to have been caused by the extraneous comment left at the bottom of the page. I've fixed that. Let me know if you still get the glitch. Go for it! 14:27, 30 December 2005 (UTC)

Yes but inconsistently. On main portals like Portal:History the text is lower against the image, instead of being flush at the top as previously. That same fault appears on this page with example box above. However, on Portal:Australia I see no such glitch and the formatting is the same (I did both). I'm not sure what's causing it, but I dislike it. Perhaps it might be caused by the "text justify" user preference I use, but that doesn't explain why it didn't occur before nor why P:AU is fine.--cj | talk 01:50, 31 December 2005 (UTC)

Actually scratch that. It occurs on every portal. The reason it didn't happen on Portal:Australia was because I had subst'd its box-header a while ago (for a reason I forget). Do you not notice it? I can upload screenshots if necessary.--cj | talk 12:47, 1 January 2006 (UTC)

Yes, I think I know what you are talking about now. It looks like the text starts half a line from the top of the image rather than at the very top. However, Mathematics has the same thing, and it's constructed using a different template. Philosophy uses still another markup method. I don't think the templates nor sourcepages are causing it. However the top margin looks the same for text in boxes with images as for the text in boxes with no images. It must be the way the program places pictures. I can't find it in any page source. There is one problem I noticed we're no longer having -- the text no longer overlaps into the image, which used to happen at the top of an image a lot. Go for it! 15:36, 1 January 2006 (UTC)

I only noticed image-related faults where thumbs were used. I have been discouraging their use, and left hidden comments on several portals warning against them. As for this present fault, it is to wide-spread to let be, so I intend on restoring the previous formatting. Additionally, I've noticed that the edit link being more prominent has resulted in a rise in vandalism; so much so that I've semi-protected some sub-pages. --cj | talk 05:54, 8 January 2006 (UTC)

Hi, sorry to butt in, but that last revert you made seems to have screwed up the top of some images. Many of them now seem to overlap an image over half a line of text. It's particularly noticeable on the Portal:Weather Portal I made the other day, but I can also see it on Portal:Mathematics and Portal:London. It doesn't happen on every portal or on every image... hmm... perhaps it is a firefox thing. I can't see the same problem in IE. nick 14:29, 9 January 2006 (UTC)

Nor can I (I use IE). Perhaps you can create some screenshots? As I said above, the only image-related faults I've noticed have occurred when thumbnails are used.--cj | talk 15:06, 9 January 2006 (UTC)

Sure, here you go : Image:Firefox-weather-portal-screenshot.gif. I notice you put a div around the top image and that fixed that one, but surely it defeats the purpose of the template system to do that on every image? nick 16:15, 9 January 2006 (UTC)

I've just installed Firefox, so I ended up not needing the screenshot (thanks anyway!). Using divs doesn't defeat the purpose of the software if it prevents the fault; in fact, their use is advisable given they ensure against it.--cj | talk 16:34, 9 January 2006 (UTC)

I not sure I understand your last comment cj. The new placement of the editlink is causing a formatting glitch on Portal:Mathematics (the image overlaps the text; at least under Firefox). Are you suggesting a fix, or do we need to go back to the old editlink location? BTW, I think the editlink looked better in the header bar anyway. -- Fropuff 17:08, 9 January 2006 (UTC)

Portal:Mathematics is now fixed. This is not a new placement; it is the location used up until a week ago. Where you see this fault, ensure "|right" markup is replaced with "div" markup for stability. It is for this reason templates used on the Main Page use "div". Having the edit link in the header was logical, yes. However, it was imperfect: aside a glitch, it off-set the heading and (ostensibly) increased vandalism.--cj | talk 17:20, 9 January 2006 (UTC)

I think there may be a way of getting it up there without offsetting the heading; see Portal:War. I don't know whether the vandalism claim is true, though. —Kirill Lokshin 02:38, 10 January 2006 (UTC)

That does seem to work, and without consequence too. About the vandalism: this is just a personal observation; it might well have to do with the new prominence of portals. Whatever the reason, I've had to revert vandalism on sub-pages of several portals daily. --cj | talk 04:21, 10 January 2006 (UTC)

Are they the portals linked from the Main Page, by any chance? That would be a rather more obvious explanation than the position of the edit link. —Kirill Lokshin 04:27, 10 January 2006 (UTC)

Gitch fix? I think I fixed the glitch. I suspect it was being caused by a difference between the way the program places images and how it places text. I've restored the edit button into the header, and have added a slight margin below it to fill the space the text seems to be sneaking into. I've checked all the Top 10 portals, and weather, and it seems to work. Let me know if the glitch shows up on your screen/browser, and if it does I'll take a closer look. Go for it! 13:26, 10 January 2006 (UTC)

It's hard to know, cj has put padded divs round all the images I mentioned, and I'm not of a mind to either revert his changes or go looking for more. nick 15:32, 10 January 2006 (UTC)

Hi Nick. Go for it! is referring to a separate glitch which forces the text lower when alongside an image, no matter its formatting. It doesn't appear in Firefox, but does in IE - which is used by the majority of users.--cj | talk 05:00, 11 January 2006 (UTC)

No, I was referring to the text overlap problem, where the top line of text tries to sneak above an image at the top of a section. I thought I had it licked. I'm changing the edit button back, so that we can track that glitch down. Go for it! 20:13, 13 January 2006 (UTC)

I really don't think we should impose this rather new (to en: at least) format on each and every portal using this template. At the very least, a proposal should be made to WT:P. Perhaps an alternative template could be created, one exactly like this but with rounded edges.--cj | talk 17:32, 9 January 2006 (UTC)

Looks rather crude, in my opinion, particularly given that the curves aren't very smooth. Also, on portals where there's an outer (angled) box—Portal:London, for instance—the rounded boxes look very strange. —Kirill Lokshin 02:08, 10 January 2006 (UTC)

I liked the overall look, but feel that curved edges simply don't fit with the rest of Wikipedia's layout. I also agree that dramatic formatting changes such as this ought to be discussed prior to implementation. 72.131.44.247 05:00, 10 January 2006 (UTC)

It wouldn't hurt to test the round corners for a few days by changing the template, since it takes a page refresh (purge) in order to see the changes on each portal. Because of this, only a fraction of the portals see the change. We can then see what the typical user reaction is on the talk-pages of the portals purged. But we can't get such feedback if you panic and revert in a knee-jerk reaction. You seem to "be bold" whenever it suits you, and to use the "discuss it first argument" when someone else's being bold doesn't suit you. I'm going to change it again, and if there is more than a few complaints (out of the hundreds of users assumed to be looking at the portals), I'll change it back in five days. In the meantime, I'll accomodate any portal maintainers who want their square edges back. Just give me five days, and remember the 3-revert rule. Go for it! 13:43, 10 January 2006 (UTC)

That was awfully flippant and I take exception to your accusation. I'm not the only one to have objected, nor were my reversions panic-driven “knee-jerk” reactions. I’m not opposed to portals using rounded-edges, but I object to it being imposed on all without the slightest attempt to inform maintainers. A better approach would have been to make a proposal on WT:P and to achieve some sort of consensus. I’m also concerned that you haven’t acknowledged the feedback already received (which is fortuitous, given it hadn’t been sought). It’s doubtful that many editors will even know where to comment, so I’m not sure how you intend to gather further feedback. Your argument about the changes not being visible is not accurate, either. If you wish to trial this format, why not use the alternate template you've created on a few portals rather than charging ahead against opposition? And I'm perfectly aware of the 3RR given I've enforced it on several occasions. --cj | talk 14:38, 10 January 2006 (UTC)

I've never been called "flippant" before! "Defensive", occasionally. But don't worry, if there's feedback, I'll find it. Most portal editors are probably smarter than me, and therefore will be able to figure out where to post, or at least will post somewhere (like on their portal's talk page). Plus, I might learn something while looking around. But since we're on the subject of feedback, I have a feedback question for you: are there any tools for counting the number of hits on Wikipedia pages? Are visits to articles recorded anywhere? This would at least be interesting, if not useful data. Go for it! 09:06, 11 January 2006 (UTC)

• Change back - Is my vote... it just doesn't fit with the rest of Wikipedia's look. I doubt many others will know to come here, or that maintainers will voice an opinion on their own the portal talk pages. Sulfur 20:28, 11 January 2006 (UTC) (IP 72.131.44.247 above)

• Revert is my vote too. I was undecided at first, but I think I like the square corners better. Its a more consistent look with rest of Wikipedia. There is also a weird effect on Portal:Mathematics in the "Topics in Mathematics" box. It looks like someone is try to shove a square peg into a round hole. -- Fropuff 20:50, 11 January 2006 (UTC)

I've reverted the change again. Go for it!, feedback has been forthcoming and it has been resoundingly negative (including at Portal:Philosophy). You may wish to respond to it. --cj | talk 05:03, 12 January 2006 (UTC)

CJ, you reverted two changes at once: the rounded corners and the editlink in the title bar. This in not cool. Can we discuss these as separate issues? I dislike the rounded corners, but I much prefer the editlinks in the title bar. -- Fropuff 05:14, 12 January 2006 (UTC)

The edit link is discussed in the section above this. This was returned despite being previously reverted due to a formatting fault in IE, hence my complete reversion now.--cj | talk 05:28, 12 January 2006 (UTC)

Then we should work on finding a fix for that glitch. -- Fropuff 05:46, 12 January 2006 (UTC)

You're welcome to try. Neither I nor Gor for it! have been able to. It may simply be an IE bug.--cj | talk 06:21, 12 January 2006 (UTC)

I agree with your statement concerning the default template forcing portals as a group to be round or square, and as per your suggestion have implemented a template for portal creators who want to try out round corners. See Portal:Technology. I've also created a template for square corners so that if new round-corner layouts are to be tested via the default template in the future, editors will have a way to bow out of the test. Your idea to move away from the whole default-template concept was a good one, and having more templates will encourage variety in design, and more experimentation. --Go for it! 21:23, 13 January 2006 (UTC)

CJ, I don't agree with your use of the term "resounding" to describe the feedback, as 4 votes is hardly a peep considering that hundreds or thousands of users view these pages. I plan to continue expermenting with layouts (as I can find the time), and to test both round-based and square-based format themes, and will come up with a better approach to testing the next time around. Thanks for the feedback, on both the layout and the testing method, it has been helpful. --Go for it! 21:23, 13 January 2006 (UTC)

(Sorry I took a while to respond - Wikipedia's getting too big!) All comments on portals about the change were negative, so use of the word "resounding" was justified. Please try not to be dismissive of those who have commented. It appears to me that general opinion has turned against rounded corners now anyway, after users realised it didn't transfer across the browser array. Be sure to discuss any further experiments. --cj | talk 14:11, 17 January 2006 (UTC)

Concerning the edit button, I've put it back up into the header so that we can track down the text bleed glitch. I added some padding, which I think might have solved the problem. If you spot the glitch again, let me know exactly where it is, so I can look at it with IE. Go for it! 21:27, 13 January 2006 (UTC)

The original glitch is still present, and is still the same as I described above. Please don't return the edit link to the header unless remedy has been found. Text bleed can be fixed by using div markup around images, as on the Main Page.--cj | talk 14:18, 17 January 2006 (UTC)

Could you point out a page on which the glitch occurs? I was trying to replicate it and couldn't. -- Fropuff 16:08, 17 January 2006 (UTC)

It won't occur any more, as I've removed the edit link. When in place, it occurs on any portal using this page in the circumstances I've described before (that is, where an image is placed alongside text, most notably in "selected article" boxes). --cj | talk 16:13, 17 January 2006 (UTC)

Could you give a specific page on which you saw the glitch? I realize it won't occur with the edit link where it is now. Also which version of IE are you using? -- Fropuff 16:24, 17 January 2006 (UTC)

The latest (IE 6 SP2). As I said, it will occur on any page transcluding the box-header. I noted Portal:History as the first page I noticed it on.--cj | talk 17:04, 17 January 2006 (UTC)

Fixed (I think, at least in WinXP IE) the glitch with the edit button. Most portal page uses I previously fixed by adding a "width" attribute to the <div> preceding the section box. For other uses, I added optional "width" and "bwidth" parameters. —Doug Bell ^{talk•contrib} 07:52, 1 May 2006 (UTC)

Is it possible to change the color of the "edit" link? At Portal:Psychology, the current color scheme makes it almost impossible to see it. For some reason, it's not "titleforeground" color, but lightblueish. /skagedal^... 06:01, 6 March 2006 (UTC)

I've made the edit link the same colour as your portals' title bar text. Happy editing, --cj | talk 09:37, 6 March 2006 (UTC)

Is there any way for us to edit the color of the portal ourselves? --Heida Maria 17:42, 6 March 2006 (UTC)

I'm not sure what you mean. You can do this already at Portal:Psychology/box-header.--cj | talk 01:20, 7 March 2006 (UTC)

OK, I didn't know that, heh :) --Heida Maria 02:19, 7 March 2006 (UTC)

I have changed the float of the edit link to an absolute positioned span with coordinated relative to the parent box. As I have heard users using the IE-browser might have problems displaying this sort of element (I don't know exactly). so I have tested now with setting an offset of 1px of the span to try to clear the border, and also I have tried to remove any background and border that might be problem for the kind of browser. If anyone have a better idea, please stand up. The problem with float is that it might set an offset of the title up to 4em to the left. _→AzaToth 23:16, 8 March 2006 (UTC)

I think this edit might have thrown things out of whack in Netscape... compare the uneven spacing for the Selected picture and lists at Portal:Wisconsin with articles that start with text. Can anyone confirm this, or was it something else that did it? While consistent in IE, there also seems to be a difference in spacing between the top and bottom that looks odd. 72.131.44.247 17:41, 11 March 2006 (UTC)

I don't understand what you are saying :/ Could you show a screenshot? _→AzaToth 17:52, 11 March 2006 (UTC)

Ok, I have fixed that, it was only a extra newline in the way. _→AzaToth 18:48, 11 March 2006 (UTC)

Yep, that took care of it... thanks! 72.131.44.247 23:27, 11 March 2006 (UTC)

I have been trying without success to copy the portal technology to my wiki all evening without any success.

Please could I have a pointer as to how this works and what I need to do to copy it? I am running Mediawiki 1.5.0. I have set up a Portal namespace with subpages enabled. I have copied Portal:Box-header and Portal:Box-footer. What else do I need to copy?

Thanks. Nicholsr 00:00, 11 March 2006 (UTC)

This is also right for me. The ending "DIV" element is beyond the box! Please help with this issue - how to use this Portal templates on the local mediawiki setup?

Thanks. --Orgyen

See this page to solve that problem, http://www.mwusers.com/forums/showthread.php?t=1755&highlight=template --Ocyun0 08:52, 30 July 2006 (UTC)

After applying the changes to tidy, when viewing my Portal:box-header and Portal:box-footer and any of my Portal:Name/box-header and Portal:Name/box-footer pages the format of the entire wiki page breaks. On the box-headers, the navigation bar on the left appears half way down the page. On the box-footers, the font size of the skin appears smaller and the tabs at the top don't display nicely. The author of the "tidy solution" admits that he doesn't fully understand what effect changing these settings has. Could someone provide more info on this solution and if there is a less drastic approach? I'm afraid that changing these settings may lead to more broken syntax causing display problems in the future. Thanks --RedACE 14:58, 26 April 2007 (UTC)

I worked around the problem by simply combining the header and footer into one template that transcludes the content of the box. This also makes the syntax of using the box templates easier. Instead of having to transclude the header, content and footer, the syntax looks like this:

{{/box|Selected article|{{FULLPAGENAME}}/Selected article}}

And instead of requiring Portal:Name/box-header and Portal:Name/box-footer, I simply have Portal:Name/box which looks like this:

{{Portal:Box | title={{{1}}} 
|editpage={{{2}}} 
|content={{{3|{{{2}}}}}}
|border=#aaaaaa           <!-- This is the color of the borders around Box Sections -->
|titleforeground=white    <!-- This is the color of the Box Section Title Bar text -->
|titlebackground=#aaccff  <!-- This is the color of the Box Section Title Bar -->
|background=#f9f9ff       <!-- This is the color of the Box Section background -->
|foreground=black}}       <!-- This is the color of the Box Section text -->

I don't know why this isn't used here. Maybe there's a disadvantage to doing it this way that I don't see? --RedACE 16:39, 27 April 2007 (UTC)

I like your solution and have tried it. Strangely It appears that if the article has attributes in tags ex: <div style="font-weight:bold"> it appears to break and the article will not insert. Here is what I am working on if any one has any ideas on why this is happening: Portal:Box | Portal:Name/box | Main Portal Page --Myotus 14:41, 23 August 2007 (UTC)

I recently made a change which AzaToth then reverted. I'd like to discuss options for how it might be possible to incorporate this as I think it is important.

Basically, I added <h2> - </h2> tags around the {{{title}}} parameter. These create a 'level 2 header', such as is automatically created by '==' in wikimarkup. The reason for including such is that these headers are used by screen-reader software for the blind to navigate around to different sections. Without them blind users essentially have to listen to the entire portal page rather than just the particular section they are interested in at the moment.

The problem is that Wikipedia also uses these headers to determine where to place automatic 'edit' links for users who have that option selected in their preferences. I assumed that most portals use __NOEDITSECTION__, the way I do at Portal:Featured content, to suppress the automatic 'edit' links, but apparently that is not the case.

If we add __NOEDITSECTION__ to this template would that suppress them for just this or all pages the template appears on? Do people actually use automatic edit links on existing portals? Could we just remove the manually inserted edit link in this template and use the automatic one instead (which would have the benefit of not showing them for users who have requested that option)? Et cetera.

I have already addressed this issue by adjusting things on the portals I maintain, but I think it would be a good feature to incorporate on all of them if there is some way to work out this 'edit link' issue. --CBDunkerson 19:00, 20 March 2006 (UTC)

We could try to add it, and see if people complain. I'll do it and see. _→AzaToth 19:04, 20 March 2006 (UTC)

Heh, you're brave. I understand the concern, but hopefully this or some other option will address it. If it does, I think this will really make a big difference in portal usability for these users. Thanks. --CBDunkerson 19:16, 20 March 2006 (UTC)

I had to revert, until we work out how to use h2 headings without overriding title (text) colors and making the text black. With Portal:Africa, for example, where the title background is also black, the titles are unreadable. I have copied this box-header to Portal:Box-header-h2, where I'm working on resolving this bug. -Aude (talk | contribs) 19:41, 20 March 2006 (UTC)

I have reinserted the h2 headings, with text color fix, along with __NOTOC__, to resolve problems. -Aude (talk | contribs) 19:48, 20 March 2006 (UTC)

Sorry I didn't notice those issues (it figures the three portals I looked at would have 'NOTOC', 'NOEDITSECTION', and black fonts) and thanks for all your efforts in cleaning them up. --CBDunkerson 21:05, 20 March 2006 (UTC)

• This needs to be better documented, and even after all of the above it's a usability problem, even if accessibility issues have been fixed. People use this on wikiproject pages, not just portals, and it is clobbering the ability to edit any section on the project pages. — SMcCandlish  Talk⇒ ɖ^⊝כ^⊙þ Contrib. 06:25, 17 February 2013 (UTC)

I noticed sometime around the March 18-20 edits that many of the portals lost the right side of the boxes in the right column... almost as if the total width was 101% within another table, but decreasing the main margin width doesn't fix the issue. This happens in N7 but not IE6. Can someone familiar with the template look in to it? Thanks! 72.131.44.247 19:44, 30 March 2006 (UTC)

Almost all the portals currently have no margin at all on the left side of the text. I think they have no margin on the right side either, but I don't have full justification turned on so it's hard to tell. It happened a day or two ago. Is this a result of the changes to this page? What should we do to fix it.

I've fixed it manually at Portal:New Zealand by adding tables around each section and setting "style=passing:5em" in each, but this is both a lot of work and a complication to wiki editing that shouldn't be necessary in very many places. I've fiddled with passing width and bwidth parameters to here at Portal:Oceania/box-header, but nothing seems to work.

Portal:Australia doesn't seem affected, and it is one of the few portals not to call this page from Portal:Australia/box-header.

I see these problems in Firefox 1.0.8 and 1.5.2 running on Kubuntu and XP respectively, also in Konqueror 3.5.2. In Opera (latest version I think) I don't see the borders of any of the portal panes, and the titles are in white, except Portal:Australia looks normal. In IE 6 on XP SP1, all portals look okay.

Any suggestions on what to do to get each portal displaying correctly?-gadfium 02:48, 2 May 2006 (UTC)

P:AU is not affected because I specifically substed the original box-header code to avoid the consequences of experimentation here. This is why the edit links are still located in the boxes on P:AU instead of in the headers. So far as I can tell, it was this edit by Doug Bell which caused the problem. It appears he made width optional to remove a glitch this template produces on non-portal pages. I have reverted this edit on the basis that it caused widespread faults in portals, and that this template (as evidenced by its location) is intended for portals.—cj | talk 05:24, 2 May 2006 (UTC)

Actually, I've had to revert all recent changes, as each individually affected portals - at least insofar as they appear in Mozilla browsers.—cj | talk 05:33, 2 May 2006 (UTC)

This template seems to cause problems with images for Internet Explorer (though not Opera or Firefox). Many images, especially if they have some sort of formatting applied to them, appear out of place or not at all. Portal:War/box-header substitutes this template for manual formatting, and images display properly on that portal.--67.186.162.70 23:46, 7 May 2006 (UTC)

(The anon above is me) What does the line: "position: relative" do in the last < div > section? Removing that seems to solve the image problem, based on my userspace troubleshooting. Since there are no further parameters telling it to go anywhere relative to normal position, does this line do anything (my understanding of CSS is nearly zero)?--ragesoss 00:55, 8 May 2006 (UTC)

I can't recall. My knowledge of CSS is based entirely on trial and error, so I'm up for removing it.--cj | talk 05:14, 8 May 2006 (UTC)

I've removed it. Now let's see if it causes any problems.--ragesoss 05:20, 8 May 2006 (UTC)

Looks like the image problem is solved. I'm not familiar enough with IE (except trial and error too), but notice a bug in Portal:Technology. Not sure if it's related to box-header, but I only see the "ed" in the left column "edit" links, with the rest of the word hidden. I'm not sure how many other portals, if any, this occurs. -Aude (talk | contribs) 20:18, 10 May 2006 (UTC)

I removed the <font color=...> tags and replaced them with inline styles. —Josh Lee 18:29, 6 June 2006 (UTC)

The h2 tags cause a glitch on IE if you have multiple boxes. When that tag is in there, the text in the boxes gradually bleeds over to the left. See User:BigDT/sandbox for an example. When I replace the tag with a span, it fixes the problem. I see above why the h2 tag was placed in there. But is there any way to fix the problem? BigDT 05:20, 27 August 2006 (UTC)

Remove the padding for the box in which the h2 tags are placed. It will solve the glitch in IE.

How do I get this to hide and have the "show" near the edit button to unhide? Joe I 09:47, 16 September 2006 (UTC)

You won't be able to perform such a function with this template. I don't see why it would be at all necessary in any case. The "show/hide" function has been used in some portals (such as Portal:Aviation) to hide sections within boxes, but never to hide the boxes themselves.--cj | talk 09:57, 16 September 2006 (UTC)

I was wanting use it with Portal:Military of the United States/Topics. Joe I 10:55, 16 September 2006 (UTC)

I would like to propose an optional section parameter to this template. This would require to add &section= onto the end of the edit link. If no parameter is input, the extra code will not affect the template negatively. If I knew the If# code, I believe you could only include that if the parameter had a value.

The reason for this extra variable would be for the pages that do not need sub-pages for each section. I think it is sometimes a waste to give every section its own seperate page.

Before:

-->color: {{{titleforeground|#000000}}};"><!--
    -->[{{fullurl:{{{editpage|}}}|action=edit}} <span style="color: {{{titleforeground|#000000}}}">edit</span>]{{{top| }}} <!--

After:

-->color: {{{titleforeground|#000000}}};"><!--
    -->[{{fullurl:{{{editpage|}}}|action=edit&section={{{section|}}}}} <span style="color: {{{titleforeground|#000000}}}">edit</span>]{{{top| }}} <!--

Thoughts? – Heaven's Wrath   ^Talk  20:15, 23 September 2006 (UTC)

-->color: {{{titleforeground|#000000}}};"><!--
    -->[{{fullurl:{{{editpage|}}}|action=edit{{#if:{{{section|}}}|&section={{{section|}}}}}}} <span style="color: {{{titleforeground|#000000}}}">edit</span>]{{{top| }}} <!--

_→AzaToth 21:32, 23 September 2006 (UTC)

Thank you. I will add it to the template then. – Heaven's Wrath   ^Talk  22:35, 23 September 2006 (UTC)

I know nothing about code (let me say right away!); is there a way to add a small image within the colored portion of the box title bar? Thanks. Her Pegship 04:06, 7 October 2006 (UTC)

Yes, (unless I do not understand you). Adding the code: [[Image:Filename.jpg|50px]] should do it. But if you want to make the picture link to another page, you will have to use {{Click}}. If you show the page that you need help on, it would be easier to answer. – Heaven's Wrath   ^Talk  04:21, 7 October 2006 (UTC)

I'm looking at Portal:Library and information science/box-header; I'd like to stick a little Image:Library-logo-white.png on the left side of the bar, but am not sure where in the code to put the image link. Thanks. Her Pegship 17:14, 7 October 2006 (UTC)

I do not think it is possible to add it to the left. Check out the portal now, I added the picture. Maybe you should create a mirrored copy of the picture, and it could be put on both sides of the title. – Heaven's Wrath   ^Talk  17:48, 7 October 2006 (UTC)

That looks great. I'll add a reversed image to the other side. Thanks! Her Pegship 21:42, 7 October 2006 (UTC)

Please add Polish interwiki: [[pl:Portal:Stopka]]. Thanks, Hołek ҉ 11:38, 1 November 2006 (UTC)

In light of problems I had on my talk pages, and concerns above, I've added "if" statements to the template to fix problems other users may run into. See the list below:

|EDITLINK=x This takes away the link in the corner for editing.

|TOC=x This allows a TOC on the page.

|EDIT=x This allows edit sections to be present.

|SPAN=x This changes the "h2" tag to a "span" tag so that the box is not included as a section as on a talk page.

I hope these are helpful! _└^Jared_┘^┌_talk^┐  20:34, 28 January 2007 (UTC)

One problem I have found with portals - when I use the watch function on a portal page, it doesn't report changes in the component boxes, you have to go to all the separate pages and put a watch on each - could be better, but maybe I'm missing something important. Anyway, I got a watch function working here, but it needs an unwatch facility - any help from an expert would be much apreciated sbandrews 21:17, 15 February 2007 (UTC)

Are all those HTML comments in the template really needed? Wikipedia seems to remove them, and that's good, but they are in the style attribute, and that's totally not conformant, and they make the code really illegible. --giandrea 22:03, 9 April 2007 (UTC)

Is there an identical template which replaces Edit link on the top right corner to a View link, where users are taken directly to the page, instead of directly to editing it? If not, has anyone considered creating it? Some Portals sub-pages may be a transclusion of various pages, making a direct edit link inappropriate. See for example Portal:Puerto Rico, and its Did you know... section, which is a transclusion of varios sub-subpages with randomly rotating DYKs. - Mtmelendez ^{(Talk|UB|Home)} 20:32, 29 May 2007 (UTC)

If you look at Portal:Louisville and its selected picture, you can see the odd effects in either Mozilla Firefox and Internet Explorer 6 when you reduce the browser width to a certain point. In Firefox, the image overflows the box on the right, and in IE, the contents on the lefthand side of the portal jump around to the bottom. I just wanted to report the issue, as I don't know the best solution offhand, although perhaps using "overflow: auto" would do the trick. Stevie is the man! ^{Talk • Work} 16:29, 30 May 2007 (UTC)

The WikiProject U2 uses this template for its page, and it is very distracting and hard to read, especially with its red and black colors. The template was added by the project's creator, but I'd like to get rid of it completely and just use a simple list format like all other WikiProjects. A discussion was started about it on the project's talk page, but few replies have been written and no consensus has been drawn. Does it state anywhere that this template may be used on Portal pages only? I really wish there was a reason to take it off the project's page. –Dream out loud (talk) 17:50, 9 July 2007 (UTC)

No, there is not. If you don't wish to use it at your project, then you'll have to outline why it shouldn't be used on its merits. In any event, I agree about the harshness of the colours – I've modified them (as can you) at Wikipedia:WikiProject U2/box-header.--cj | talk 01:24, 10 July 2007 (UTC)

Please add link to finnish page [[fi:Teemasivu:Laatikon otsikko]] --213.186.239.248 17:30, 29 July 2007 (UTC) [[vi:Chủ đề:Box-header]]. User:Es.ntp. 118.68.61.132 (talk) 07:52, 14 February 2009 (UTC).

I have added an ability to hide the "edit" link using {{{noedit}}}. This feature will not be immediately available on all portals - you need to add it to your portal-specific box header template ... but I think it's important to have for things like the {{WikimediaForPortals}} transclusions. --B 10:49, 30 July 2007 (UTC)

One of these two edits screwed up the coloring format for all box headers fonts, so I reverted it. If this can be fixed without screwing up the colors again, feel free. Cirt (talk) 18:03, 27 February 2008 (UTC)

Portal:box-footer prescribes to the div of its single parameter "margin:0.3em 0.2em 0.2em 0.3em; padding:0.3em 0.2em 0.2em". Especially the bottom ones seem too much, it leaves a lot of empty space at the bottom of portal boxen. What about removing them? Standard box padding seems quite enough to me.

Not to mention that this creates an empty, heavily padded div even when there's no parameter to display. I've bypassed this on a few portals' local footer templates, but a centralised solution would be better. --Malyctenar (talk) 16:36, 4 March 2008 (UTC)

I believe that this template should display (or contain an option to display) a "view" and "talk" link in the top-right corner, in addition to the "edit" link. The best way to do this, IMHO, is to have links analogous to those appearing on {{Navbox}}, but on the top-right corner for continuity's sake. Opinions?-RunningOnBrains 20:25, 28 February 2009 (UTC)

Viewing this page in IE6 bring several severe errors to light. First, the [edit] link is breaking out of the box. I see there was a "fix" (#absolute position versus float) above; that needs to be reverted. Also, as the page progresses, the H3 headers are progressively pushed outside the main div boundaries. This may be related to the above, but haven't investigated yet. — Edokter • Talk • 23:13, 18 April 2009 (UTC)

The template is somehow still creating dozens of interwiki links for this template into innumerable portals. Please fix as soon as possible. Sciurinæ (talk) 12:27, 19 May 2009 (UTC)

Now it seems to be back to normal. Sciurinæ (talk) 12:33, 19 May 2009 (UTC)

Why are the [edit] links all hidden when this template is used on a page? Compare this (fixed in user space) with this (the original WikiProject Earthquakes page). Also, why ask editors to use the template as {{Template:Box-header}} rather than the normal {{Box-header}}? --Jubilee♫clipman 22:51, 19 May 2010 (UTC)

You have to use an undocumented feature, add |EDIT=yes, to the options list. Mattg82 (talk) 18:16, 20 January 2011 (UTC)

Is it necessary to include the "Template:" prefix in the three examples provided on the /doc page? There's no difference at all between {{Template:Foo}} and {{Foo}}, is there? Thank you, -- Black Falcon ^(talk) 18:15, 17 August 2011 (UTC)

I've modified the /doc page to remove the explicit reference to the 'Template:' prefix. -- Black Falcon ^(talk) 18:55, 17 October 2011 (UTC)

Please, change the font from Arial to the generic code sans-serif, as there is no need to specify a specific font in this template which affects portals, such as Portal:Free software, I see the headers in Arial, why? --Mahmudmasri (talk) 09:41, 17 August 2012 (UTC)

 Done. — Edokter (talk) — 10:46, 17 August 2012 (UTC)

Someone know if it's possible to use this template without the edit link?. And I see here more parameters than in the documentation page like {{{border-width|1}}}, {{{titlefont-size|100%}}}, {{{padding|1em}}}, {{{border-top|{{{border-width|1}}}}}}px, etc. I think that this must be included there, because, for example, someone could want to have a title with a bigger size of letter or a wider box-header. --JaviP96 16:25, 8 April 2013 (UTC)

Can we have the option to use a different font on the title (only)? That would mean we can make this template fit better in individual cases with the correct formatting as per organisation websites. --Jwikiediting (talk) 14:02, 25 July 2013 (UTC)

You can pass a font-family= parameter; it's just not documented. — Edokter (talk) — 15:35, 25 July 2013 (UTC)

Can someone help out with this? on Portal:U.S. Roads and Portal:Michigan Highways (among others), we use the same color scheme as the Manual on Uniform Traffic Control Devices specifies for highway signs, white text on a darker green background. However, these highway signs also use a sans serif typeface. With the coming Typography Refresh, these headers are appearing in the same serif typeface as the headers in regular articles, which just looks "wrong" with that color combination. I'll note that as it is now, "sans-serif" is set as the default, but I have the Typography refresh enabled now, and portal headers appear in the same serif typeface as article headings, so obviously this template is not working overriding things.

I added |font-family=Arimo, Liberation Sans, Helvetica Neue, Helvetica, Arial, sans-serif to Portal:Michigan Highways/box-header, but nothing has changed for me on Portal:Michigan Highways. Help! Imzadi 1979 → 01:00, 1 April 2014 (UTC)

I think the font override needs to be applied to the h2 element, instead of the div. The site/beta feature CSS applying the serif fonts to h2 headings has a higher priority than the inline styling of the div. -happy5214 07:31, 2 April 2014 (UTC)

Added {{{title-font-family}}}. — Edokter (talk) — 10:41, 2 April 2014 (UTC)

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Hi! Can an admin/template editor please add the ability to define the div's height? It'd be useful for filling up the entire height of a table row when placing them side-by-side. I've simply added a height parameter (along with removing some extra spaces); see pastebin. Documentation would also need to be updated. ~SuperHamster Talk Contribs 07:50, 8 February 2015 (UTC)

@SuperHamster: Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Also, please don't use pastebin for proposed changes: use the template's sandbox; more information at WP:TESTCASES. --Redrose64 (talk) 12:21, 8 February 2015 (UTC)

Bad idea. Using a fixed height is problematic, as you never know what the width will be. If there is too much text, you risk the bottom part being obscured. -- [[User:Edokter]] {{talk}} 12:55, 8 February 2015 (UTC)

@Redrose64: Thanks for the tips!

@Edokter: Aye, I originally thought each div would fill up the height when set at 100%, but it apparently only does so when its parent div/table is set to a fixed height...no clever but simple CSS workarounds I assume? ~SuperHamster Talk Contribs 15:29, 8 February 2015 (UTC)

No. There is no way to give a div a relative height. I have been struggling with it myself for some time now. The only solution is to use the new CSS3 flexbox model. You can see it in action on my experimental Main Page (press the big button). -- [[User:Edokter]] {{talk}} 17:10, 8 February 2015 (UTC)

The <H2> tag is causing problems with mobile view. Change the <H2> tag to a <div> tag to correct. See Wikiversity:Template:Box-header for comparison. -- Dave Braunschweig (talk) 20:07, 9 January 2016 (UTC)

This edit request to Template:Box-header has been answered. Set the |answered= parameter to no to reactivate your request.

Change: Add the ability to customise colours for each border around the box.

Description: This is seen (by use of editing a copy of this template) on this page Portal:Canada/Wikiprojects/box-header/2 and uses a different coloured border for under the title. Also see Portal:Daddy Yankee/box-header/2 for another box-header that cannot be created from this template for the same reasons. I tried to accomplish this using this template, but from my testing, it is not at the moment possible. Dreamy Jazz (talk) 15:04, 4 June 2018 (UTC)

@Dreamy Jazz: This should already be possible by using |titleborder= for the title border colour, and |border= for other borders' colour, or all borders if |titleborder= isn't specified. (Though the documentation here could do with some improvement, I had to look at the source code to find that out) Evad37 [talk] 01:14, 5 June 2018 (UTC)

Here are some examples of the effects that can be achieved with these parameters - Evad37 [talk] 01:32, 5 June 2018 (UTC)

{{Box-header
| title=Foo
| noedit=yes
| titleborder=#ff0000
| border=#0000ff
}}
Bar
{{Box-footer}}

{{Box-header
| title=Foo
| noedit=yes
| titleborder=#ff0000
| border=#0000ff; border-top: 1px solid #ff0000
}}
Bar
{{Box-footer}}

{{Box-header
| title=Foo
| noedit=yes
| titleborder=#0000ff
| border=#0000ff; border-top: 1px solid #ff0000
}}
Bar
{{Box-footer}}

Thanks for the explanation. Dreamy Jazz (talk) 07:23, 5 June 2018 (UTC)