Help talk:How to fix bunched-up edit links
 | This help page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
| |||||||||||
 | This page was nominated for deletion on 07 August 2011. The result of the discussion was keep. |
Copied from Wikipedia:Village pump (technical)
editI created a new howto, Wikipedia:How to fix bunched up edit links, on how to fix that problem where floated images push section edit links to the wrong place (which seems to be a FAQ). Please take a look and correct any mistakes I might have made. --cesarb 20:43, 14 June 2006 (UTC)
- That is a very concise and helpful page. Are you going to add a link to it at the top of this forum in the FAQ list? Also, for one wiki, we had a solution for very large pages (like vote pages) that had bunched up sections that would be a pain for us to maintain manual clears (especially since most users adding to it didn't know how). In the common.css we put:
#headclear h1 { clear: both; }
#headclear h2 { clear: both; }
#headclear div.editsection { clear: both; position: relative; top: 2em;}
- And then we wrapped the page in a <div id="headclear">. Not perfect, but functional (although it seems to cause problems in some versions of IE). --Splarka (rant) 00:59, 15 June 2006 (UTC)
- I intend to add it to the FAQ (which I wrote most of) as soon as I get more feedback (in fact, it's my intention from the beginning). I don't want to impinge potentially bogus advice on any newbie which might happen to wander by. --cesarb 01:48, 15 June 2006 (UTC)
- Legacy clear after "unknown" (legacy or CSS) float should always work. The opposite would fail on legacy browsers, CSS clear after legacy float. The main difference between
{{clr}}and{{clear}}isn't legacy vs. CSS, but inline BR vs. block level DIV. Inline works everywhere within a block, block level isn't allowed in some places. For strict XHTML an inline element outside of all block level elements isn't allowed, in that case you'd need the DIV. Both are kludges, anything would be fine if folks start a DIV before any floating magic, and close it when they're happy with the result. For legacy browsers the "right" and "left" of [[image:]] is at best a waste of time. A dummy table withalign="right"or "left" containing only the image works with "any" brwoser, and in that case you'd need{{clr}}or<br clear="all/left/right/>. Example on WP:EIS, if it's still there. -- Omniplex 06:06, 20 June 2006 (UTC)
- Legacy clear after "unknown" (legacy or CSS) float should always work. The opposite would fail on legacy browsers, CSS clear after legacy float. The main difference between
- I think I understood it better now, thanks for the explanation. I've removed the incorrect information from Wikipedia:How to fix bunched up edit links. --cesarb 12:14, 20 June 2006 (UTC)
- The entire article content is wrapped in a
<div>, which in turn is wrapped in a<body>, which in turn is wrapped in an<html>. All elements are thus within multiple block-level tags, so there's no violation. —Simetrical (talk • contribs) 22:36, 21 June 2006 (UTC)
- The entire article content is wrapped in a
- Thanks, sounds good now. In theory you could "downgrade" your 2nd example to work with older browsers, add
align="right", optionally strike the then redundantfloat: right;, ready. That would be also a case where you'd use{{-}}or <br clear="right" /> to stop the floating. - Floating right can cause havoc if it meets something further down that can't be folded, wide <pre> lines or wide tables, unfortunately also long section titles in a ToC (unless the ToC is put in a table with width less than 100% leaving enough room for anything floating right). Maybe mention that floating left is better than floating right under rare conditions (vague because I'm not sure how much of it is only an oddity of my browser). -- Omniplex 17:22, 20 June 2006 (UTC)
- Thanks, sounds good now. In theory you could "downgrade" your 2nd example to work with older browsers, add
- No. The whole point of the second example is to work exactly like the first example. Since the first example uses only CSS floats (and thus would not float with obsolete or uncommon browsers), the second one has to also use only CSS floats. Doing otherwise would lose the whole point of the method, which is to fix the edit links while changing nothing else. I did think of
align="right"versusstyle="float: right; clear: right", and concluded being as similar as possible would help avoid possibly susprising results, and thus would be better. If the first example had usedalign="right", the second example would have to usealign="right"also; however, this is not usually seen in actual articles, and the page was written to help with the specific situation seen in several articles (and is supposed to be newbie-friendly, so it should avoid discussing obscure corner cases). - As to floating left, unless it's being proposed as a way to fix the section edit links, it shouldn't be in that page. --cesarb 04:01, 21 June 2006 (UTC)
- No. The whole point of the second example is to work exactly like the first example. Since the first example uses only CSS floats (and thus would not float with obsolete or uncommon browsers), the second one has to also use only CSS floats. Doing otherwise would lose the whole point of the method, which is to fix the edit links while changing nothing else. I did think of
- For popular browsers there's no difference between inline CSS
style="float: right;"and legacyalign="right", they interpret it identically. I hope with a priority for inline CSS in the case of conflicts. For uncommon devices (mobile) or old browsers inline CSS is invisible, no effect. Where that's no problem it's fine. A huge sidebar appearing before the relevant content can be annoying, sooner or later somebody will fix or remove it. - Floating left, I can't tell if that's in any way related to edit link issues, inline CSS has no effect from my POV, also no undesirable side-effects. -- Omniplex 12:58, 22 June 2006 (UTC)
- For popular browsers there's no difference between inline CSS
Adding to external links
editThis is a bug http://bugzilla.wiki.x.io/show_bug.cgi?id=1629 --Cat out 19:48, 12 August 2006 (UTC)
Right text margin problem
editThe two possible workarounds proposed here have both the same problem: they remove the margin between the text and the image, which in my situation is quite showy as I use Justified paragraphs. Here are the screenshots:
 |
 |
Is there a way to artificially add some white space between the text and the image? I find this proximity inelegant... // Duccio (write me) 17:27, 15 September 2006 (UTC)
- Yes, you can use
margin-left: 1.4em. However, the original usesborder-left: 1.4em, at least on Monobook; I do not know why, nor do I know ifmargin-left: 1.4emlooks correct on all skins. For now, I've changed the examples to use it. --cesarb 22:27, 16 September 2006 (UTC)
- It's perfect now! Thank you very much. // Duccio (write me) 09:39, 17 September 2006 (UTC)
Infobox + images?
editIs there a more elegant solution than that I have adopted at Redland, Bristol to the problem of having an infobox and images causing the bunching-up? I've put the image inside the float:right; clear:right -ed table, but that's obviously suboptimal. I tried to wrap the table and the image seperately inside another table, but that just went super-wacky (no diff, unfortunately, since I only did it in show preview). -Splash - tk 15:39, 29 October 2006 (UTC)
Different size images
editWhat do you do when all the various images are different sizes? Is there an option other than to put some on the left? Will (Talk - contribs) 22:56, 7 February 2007 (UTC)
Why are we using floats, anyway?
editHere's a rule that will fix it once and for all:
.editsection {
float:none;
display: block;
text-align: right;
position: relative;
top: 0.67em;
line-height: 0;
}
difficult directions
editI had trouble understanding the directions. Could someone please give some hands-on help with airport? --Espoo (talk) 11:40, 20 April 2010 (UTC)
Screenshots needed
editSeveral times I have, through some circuitous route, landed at this page. I have never been able to see any problem with the supposed examples, nor really understand what the symptoms of the problem are. Can I suggest one or more screenshots at the top of the page, with a big red arrow or circle saying "this is the problem that we're talking about"? —Preceding unsigned comment added by 81.159.78.229 (talk) 02:49, 8 September 2010 (UTC)
- The problem pretty much only manifests those of us with high resolution screens who keep our windows maximized. I think a screenshot might not be a bad idea.HarryHenryGebel (talk) 23:01, 3 November 2010 (UTC)
Universal fix has been discovered!
editThis whole page is about to become obsolete. On MediaWiki talk:Common.css#Header lines, The DJ proposed adding a simple rule (h2 {overflow: hidden;)) to Common.css to prevent the header line from touching the various floating element, like infoboxed and images. I relaised that constraining the headers to the available space might also constrain the edit links and thereby preventing them from being pushed down the page, and I was right. A bugreport has been filed, and a temporary fix wil likely be implemented in Common.css very soon. For those wanting to see immediate result, put the following code in your CSS:
h1, h2, h3, h4, h5, h6 {
overflow: hidden;
}
Once the code is in place, the templates can be blanked, and we have no more bunching! — Edokter • Talk — 15:55, 27 December 2010 (UTC)
- Code has been added to Common.css. In the unlikely event you may see any problems, please report here. — Edokter • Talk — 20:29, 27 December 2010 (UTC)
- I still see some pages that need work. Dab pages often have a lot of whitespace near the top that I fix by use of a table. I just fixed Legislative Assembly of the Cayman Islands by use of the {{LeftTOCwrap}} template. I use to use the {{Fix bunching}} template all the time, but now there does seem to be little need for it. Every now and then I do come across a page where I wish I could still use that template, but I usually mess with it until I find a viable fix. – PIE ( CLIMAX ) 21:00, 26 January 2012 (UTC)
Bunched-up images
editI have a problem with bunched-up images – see here for example: [1] It is caused by the use of two infoboxes (I know, I know).
I have "fixed" it for now by moving the first image down below the first infobox. Another solution would be to move the second infobox down. I'm looking for better solutions though. Tony Mach (talk) 19:15, 13 August 2012 (UTC)
- A similar (but slightly longer) posting was made a few minutes later at WP:Village pump (technical)/Archive 102#Bunched-up images. Since VPT has far more watchers than this page, let's discuss on that page only, per WP:MULTI. --Redrose64 (talk) 20:33, 13 August 2012 (UTC)
Should Wikipedia:Avoiding text gaps be merged here?
editI'm suspicious that Wikipedia:Avoiding text gaps is discussing this same problem without having landed on the same solutions. Trying to Google up this page, that was the one I landed on first. -- Kendrick7talk 05:45, 18 April 2015 (UTC)
- The two problems had different causes, and so affected different browsers. The text gap problem only affected Internet Explorer, and was related to floating block-type elements like images and tables; I believe this is now fixed (at least for IE8 on), although I don't know when. The bunched-up edit links problem affected other browsers, certainly Firefox and (I think) Chrome and Safari, was related to section headings, and was fixed over three years ago. --Redrose64 (talk) 11:53, 18 April 2015 (UTC)