Help talk:How to fix bunched-up edit links
Latest comment: 19 years ago by Cool Cat in topic Adding to external links
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)
- 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 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)
- 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
- 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)
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)