Last modified: 2014-11-17 09:21:24 UTC
When I view http://en.wikipedia.org/wiki/User:SPUI/RI_10 in a Mozilla-based browser (Firefox, K-Meleon, etc) some of the edit links are in the wrong place - see http://en.wikipedia.org/wiki/Image:Fucked_edit_links.png for a screenshot. A possibly related but very minor problem occurs in the latest version of Internet Explorer - see http://en.wikipedia.org/wiki/Image:IE_SPUI_R10.gif . The fact that this only happens in certain browsers suggests that it may be a browser problem; if this is found to be the case, can someone with more knowledge of the cause submit it as a Mozilla bug? It could also be a CSS issue, with different browsers parsing it differently; or it could be a browser problem but fixable by changing the CSS.
In [[Boston_College]], this can be seen with Firefox 1.04 but not IE6-SP1, and is associated with misplacement of left-aligned thumbnails.
See also bug 72 and bug 2703.
*** Bug 4523 has been marked as a duplicate of this bug. ***
*** Bug 2703 has been marked as a duplicate of this bug. ***
http://commons.wikimedia.org/wiki/Image:Fehler-abschnitt-bearbeiten-unter-text.png I'm also using Mozilla
Not shure if this is the same bug at [[ro:user:Gangleri#bugzilla_01629]] where four [[ro:MediaWiki:Editsection]] are shown. Using Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 best regards reinhardt [[user:gangleri]]
Someone in the German Wikipedia has written a short JavaScript file. This puts the 'edit' text to the left side instead of the right. Try it if you're using a Mozilla browser (copy&paste into your monobook.js). function moveEditsection() { var editsections = new Array(); var divs = document.getElementById("bodyContent").getElementsByTagName("div"); for(var i = 0; i < divs.length; i++) { if(divs[i].className == "editsection") { editsections.push(divs[i]); } } if (editsections.length != 0) { var i = 0; var element, heading; while (editsections[i] != null) { element = editsections[i]; heading = element.nextSibling; while(!/^H[2-6]$/.test(heading.nodeName)) { heading = heading.nextSibling; } var spanElement = document.createElement("span"); var spaceNode = document.createTextNode(" "); heading.appendChild(spaceNode); heading.appendChild(spanElement); spanElement.style.fontSize = "x-small"; spanElement.style.fontWeight = "normal"; while (element.childNodes.length != 0) { spanElement.appendChild(element.childNodes[0]); } element.parentNode.removeChild(element); i++; } } } aOnloadFunctions[aOnloadFunctions.length] = moveEditsection;
Is it worth creating a user preference to put edit section links on the left (or the right for RTL languages)? I would expect this to be be relatively straightforward.
This can be seen on the page [[Artemis]]
(In reply to comment #9) > This can be seen on the page [[Artemis]] [[ro:user:Gangleri#contributions]] shows more misplaced edit section links. Is it possible using another HTLM / CSS implementation to "force" that section headers and edit section links apear on the same line (inside the <p>... </p>)? <p><a name="Contribu.C5.A3ii" id="Contribu.C5.A3ii"></a></p> <h2><font id="contributions"></font>Contribuţii</h2>
*** Bug 5148 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Someone in the German Wikipedia has written a short JavaScript file. This one is from me. More details (German...) can be found at http://de.wikipedia.org/wiki/Benutzer:Dbenzhuser/Monobook I know, that several people use it and like the alternative position of the editsection link. So I could imagine this to be a solution for the problem (of course built-in to the mediawiki php code, not js) PS: The last line should be changed from > aOnloadFunctions[aOnloadFunctions.length] = moveEditsection; to > addOnloadHook(moveEditsection); to work properly in others than only the German-speaking wikipedia.
*** Bug 6213 has been marked as a duplicate of this bug. ***
*** Bug 6713 has been marked as a duplicate of this bug. ***
In the german wikipedia we have currently enabled a slightly modified version of the script from above for all users. Even though there are demurs which are discussed at the moment, the overall reactions aren't that bad. Disadvantages of a sollution using JavaScript are 1) that it's JavaScript (including on old machines/long pages a visible switching of the buttons) 2) that there is no possibility to configure it by the preferences dialog (deactivating is currently only possible by the own monobook.js) Would be great, if a developer could check if the behaviour can be integrated in the MediaWiki-Code (with a possibility to return to standard behaviour by the preferences). This would solve this bug.
After doing a bit of delving into CSS specifications, the relevant specification is point 5 at http://www.w3.org/TR/CSS21/visuren.html#float-position, "The outer top of a floating box may not be higher than the outer top of any block or floated box generated by an element earlier in the source document." What this means is that if any content within a section is floated right, any section edit links will not be able to be above the top of that content. This is irrelevant for a single right float, since its top must be within the preceding section, but if a second right float is present, the position of the edit link may be shoved down. As far as I can think of, there's no possible fix that doesn't cause problems of its own. The <div> trick given at the new URL can't be automated, because floated images would then be positioned one on top of another, which would not be the desired effect if a right-floated image were placed near the top of a section, then another several paragraphs later. We don't know how tall the lines are going to be rendered, so we can't determine whether an image is going to overflow into the next section. We could just clear every section, but that's unacceptable. When I get around to it, I'll see if I can ask some CSS gurus if they have any ideas. (In reply to comment #15) > Would be great, if a developer could check if the behaviour can be integrated in > the MediaWiki-Code (with a possibility to return to standard behaviour by the > preferences). This would solve this bug. Well, it would brush it under the carpet. First of all you'd have edit links on the left instead of the right, which isn't necessarily desirable, and second of all it would still screw up on left floats (which just happen to be less common in LTR languages).
(In reply to comment #16) > Well, it would brush it under the carpet. First of all you'd have edit links on > the left instead of the right, which isn't necessarily desirable, and second of > all it would still screw up on left floats (which just happen to be less common > in LTR languages). Having them on the left side (not completely on the left, just right next to the heading) in my eyes is just a matter of habit. As this sollution does not use float to position the links, there is no problem with images or floated tables, not matter where they are. Just look on any page of the german wikipedia. Of course not everybody likes it, but a lot do - and it solves other usability problems, too.
(In reply to comment #17) > Having them on the left side (not completely on the left, just right next to the > heading) in my eyes is just a matter of habit. As this sollution does not use > float to position the links, there is no problem with images or floated tables, > not matter where they are. Er, right. My bad. So that could be a solution, yes, and it would also put more emphasis on the edit links (which is presumably good).
I support having the deutsch behavior enabled by default. In fact, the script is a workaround for a problem that could have been solved easily in Monobook.css, if there was no automated generation of <div class="editsection" style="float:right;margin-left:5px;"> by MediaWiki (it's the static style statement that is the issue here). What about getting rif of the style statement here and moving it in Monobook.css?
(In reply to comment #19) The style part can easily be overwriten in the monobook.css by using the !important statement to increase its priority: .editsection { float:none !important; margin-left:0 !important; } But I don't see how you want to achieve the current behavior of the german wikipedia by only using css. The problem - thats why I used JS - is the order in which the parts (link and heading) are written in the html code. Afaik there is no way changing this with css.
Indeed, my mistake. Anyway, I support this bug :) I've just made the fr wikipedia switch to this behavior (like on de), so we will have more feedback.
(In reply to comment #21) > I've just made the fr wikipedia switch to this behavior I don't know how much people use it, but there is a known bug: The "section editing by right-clicking on section titles" doesn't work together with the modified edit links. The right-click-script workes pretty similar as moveEditsection(): It searches the edit links and then modifies the following heading. As moveEditsection() changes the structure of this part of the page, the right-click-script fails. Just if others run with the idea to use the script, be prepared that there still can/will be little problems.
Created attachment 2204 [details] Non-Javascript implementation of "German solution" This patch tweaks the PHP files to implement a solution that's basically identical to what the Germans and French now use, but without that icky Javascript. This should work for any skin, but note that it puts the editsection link inside the h# tag, so they'll be the same size and general appearance as the header in any skin other than Monobook (whose CSS I tweaked in the patch). I'm still slightly skeptical of whether the general solution should be implemented in the software at all, but it's true that that looks to be the only way to reliably solve this bug until CSS improves. One other way to solve many of the cases where it occurs would be to have consecutive images floated in the same direction be put inside a floated div instead of being individually floated.
*** Bug 6963 has been marked as a duplicate of this bug. ***
Comment on attachment 2204 [details] Non-Javascript implementation of "German solution" Patch is obsolete with r17078. A replacement patch should be easy: all style changes are in place, so just swap the order of the spans in Parser.php.
Provided we want to maintain current float behavior, this bug is unfixable until CSS improves. Changing floated section edit links to inline is a separate request.
Instead of floating it, how about putting it in a right aligned div with a negative relative top position? The heading would need to have a right margin added to ensure a blank spot to put it in. See example at http://en.wikipedia.org/wiki/ Wikipedia:Village_pump_%28technical%29#This_edit_link_floating_image_CSS_bug_has_been_around_for_EVAR .
Positioning something to look like it's on the previous line is not generally possible with CSS 2.1, since you have access to only the font-size of the current element and not its line-height. You mostly have to hardcode the line-height, which will screw up if anyone changes it. But that aside, please post a working HTML example here as an attachment. Just take some standard thing that has edit links bunched up from [[WP:BUNCH]], and restyle the edit links according to your scheme so that they don't bunch. I can then review it and commit it if it works well.
Created attachment 3004 [details] html from [[WP:BUNCH]] using div with negative relative position for section edit link I'm not claiming it's perfect, but I've attached a version of [[WP:BUNCH]]'s example 1 using a div with a negative relative position (to get the edit link on the right line). I've only looked at this in two browsers (IE7 and Safari). This probably needs a change to the header style to make sure there's a blank spot on the line (like a 6 or 7 em right margin). The only thing I'm really claiming is that this might be worth taking a look at.
That appears to display quite well. I'll look into it tomorrowish.
Created attachment 3031 [details] Partial patch (doesn't work for non-Monobook-based) This appears to work without a hitch. It involves document structure changes, however, so there will have to be notifications and so on so people can make sure their scripts and stuff won't spontaneously combust.
*** Bug 9478 has been marked as a duplicate of this bug. ***
Okay, here's the reason I haven't committed this yet. It's passed every test I've put it to, but I'd bet five bucks that some corner case is going to screw it up just as badly as the current floating is screwed up. And while that may or may not happen, if it *does* happen, it will mean that I've disrupted everyone's scripts and CSS for no good reason. It also may require reversion of the changes, causing more disruption. And finally, according to that usability study (Google for it), people are totally confused by edit links being all the way to the right anyway. They think they belong to the previous section, because after all, there's this big line under them separating them from the section below. Edit links should be changed to look like the German and French Wikipedias have them, or else to be on the left rather than the right (so they don't jump around). That will eliminate this problem, and in all likelihood improve usability generally. So I'd be inclined to do that rather than this. It won't even require document structure changes, just CSS changes, so nothing breaks.
It would be great to have the german Wikipedia behavior by default: DOM order wm-headline, editsection.
(In reply to comment #7) > Someone in the German Wikipedia has written a short JavaScript file. This puts > the 'edit' text to the left side instead of the right. Try it if you're using a > Mozilla browser (copy&paste into your monobook.js). > Would it be possible to bring this monobook.js snippet to work with IE7 too, maybe to skip it only as to keep the en:WP look?
(In reply to comment #33) > And finally, according to that usability study (Google for it), people are > totally confused by edit links being all the way to the right anyway. They > think they belong to the previous section, because after all, there's this big > line under them separating them from the section below. Edit links should > be changed to look like the German and French Wikipedias have them, or else to > be on the left rather than the right (so they don't jump around). That will > eliminate this problem, and in all likelihood improve usability generally. So > I'd be inclined to do that rather than this. It won't even require document > structure changes, just CSS changes, so nothing breaks. I'm ready to do this; see <http://lists.wikimedia.org/pipermail/wikitech-l/2007-June/031899.html> ff. Please comment if you have an opinion.
In the midst of all the discussion, which is still ongoing and which I'm still committed to finishing off, I realized that there's a very simple way to do this, with a one-line CSS change. I've had it in my Wikipedia CSS for a while now and have seen no issues. I think it very likely that this will fix the problem once and for all, so I'm resolving FIXED in r24168.
It was reverted in r24253 and r24254: it broke RTL on Firefox and also broke IE/Mac.
What was the breakage on IE/Mac? RTL I can look at, IE/Mac not so easily. It could just be hidden from IE/Mac, though.
Header text was invisible.
*** Bug 10993 has been marked as a duplicate of this bug. ***
(In reply to comment #33) > And finally, according to that usability study (Google for it), This? http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Usability/Test_Februar_2006 > people are > totally confused by edit > links being all the way to the right anyway. Then they should not be all the way to the right. Making the headers display:table; kind of works. Kind of. German Wikipedia looks better, though.
The bug now also shows in Opera (8.02), see for example http://nl.wikipedia.org/w/index.php?title=Circuit_Park_Zandvoort&diff=10057985&oldid=10056982 . Maybe someone shoud do something about it, after all the bug was reported 32 months ago. :-(
A much better example is on http://nl.wikipedia.org/wiki/Gebruiker:Erik_Baas/1629 .
Other bugs related to section edit link formatting: bug 11270, bug 11555.
Not very elegant, but works for Firefox 2: .editsection { float: none; display: block; text-align: right; position: relative; bottom: 1em; line-height: 0; /* alternatively, you could use a negative margin */ } It assumes edit links are *after* the headlines, thus it would solve bug 11555 too. On the other hand, it would probably make the tab-like appearance proposed in bug 11270 impossible.
The question is whether the margins could be worked out accurately for all browsers and fonts. If so, something like that would be workable. I plan to put some effort into it over the next week or so, with the tabs too. (Tabs would work fine with that code, you just have to work in a background, padding, and some borders.) I think absolute positioning would actually work better than relative. The question is whether all browsers we support (which I guess is IE5+/Windows, IE5/Mac, Mozilla and Firefox 1.0+, Opera 7+, some versions of Safari; or some list like that) will behave correctly. I suspect they might not, based on comment 40 here, but the idea should be the same as for the content tabs, so I'm optimistic that I can look into the hacks we use for that and adapt them if I give it some effort. It would be good if I could dig up a Mac, but failing everything else, just omitting the tabs or fancy positioning for some browsers would be acceptable.
Oddly enough . . . I can't reproduce this locally. [[WP:BUNCH]] shows up correctly for me. Can anyone else reproduce this bug at this point? If not, I'm going to have to call it FIXED. I'll continue discussion on reformatting at bug 11270.
I still see it at WP:BUNCH (FF 2.0.0.11/Win XP).
Ah, I had a custom CSS rule, never mind. Stupid of me. I plan to fix this along with bug 11270, anyway.
*** Bug 12662 has been marked as a duplicate of this bug. ***
Wow! Such complex solutions to a simple problem: the header is not "containing" the float-right [edit] link. Add to the .css: <nowiki> /* make headers include contained floats, so they don't wander around (yes, is magic, it tells the browser the tag is a container) */ h1, h2, h3, h4, h5, h6 { overflow: hidden; width: auto; } /* keep "[edit]" at normal font, not inherit header attributes */ .editsection { font-size: 100%; font-weight: normal; } </nowiki>
Please read previous comments before posting new ones. This was tried in comment #37, but was backed out because of issues with RTL and IE5/Mac. If you can submit a modified set of rules that addresses those issues, I'll commit them. In any event, the "width" rule there should have no effect and should be omitted; and the .editsection rule is completely mysterious (why should setting overflow: hidden require any changes to editsection size or weight?).
Sorry, that comment didn't say *what* was tried ... (yes, I know by chasing all the rNN links I would have found it), sorry again. The width: auto; seems to be needed for it to work in some browsers/versions. In any case, harmless. The .editsection code is needed because the link is now "inside" the header, and will appear bolded and at different sizes as with the headers. (probably not desirable, in any case not the status quo ante)
(In reply to comment #54) > The width: auto; seems to be needed for it to work in some browsers/versions. What browsers? > The .editsection code is needed because the link is now "inside" the header, > and will appear bolded and at different sizes as with the headers. (probably > not desirable, in any case not the status quo ante) No change to CSS can change the inheritance of CSS properties. The link is inside the header already, and that code is already present in main.css, line 128 ff. (Except that there it actually works: font-size: 100% means "set the font size to the same as the parent's font size", which is not what you want.) Why is your version of the code relevant here at all?
Just FYI, English Wikipedia is considering moving the [edit] links to just after the section titles (like German Wikipedia) in order to fix the bunching problem. Apparently this would require bug 11555 to be fixed. See http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#The_.5Bedit.5D_link_for_sections
*** Bug 19365 has been marked as a duplicate of this bug. ***
*** Bug 21614 has been marked as a duplicate of this bug. ***
*** Bug 22864 has been marked as a duplicate of this bug. ***
Related to bug 8814.
*** Bug 24873 has been marked as a duplicate of this bug. ***
*** Bug 26198 has been marked as a duplicate of this bug. ***
Fixed in r79087 via bug 26449.