Wikipedia talk:How to fix bunched-up edit links
From Wikipedia, the free encyclopedia
Contents |
[edit] Copied from Wikipedia:Village pump (technical)
I 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 with align="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)
-
-
-
-
- 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 redundant float: 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)
-
-
-
-
- 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 legacy align="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)
-
[edit] Adding to external links
This is a bug http://bugzilla.wikipedia.org/show_bug.cgi?id=1629 --Cat out 19:48, 12 August 2006 (UTC)
[edit] Right text margin problem
The 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)
[edit] Infobox + images?
Is 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)
[edit] Different size images
What 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)
[edit] Why are we using floats, anyway?
Here'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; }
--Random832 18:12, 19 September 2007 (UTC)
