zigger wrote:

In [[Boston_College]], this can be seen with Firefox 1.04 but not IE6-SP1, and
is associated with misplacement of left-aligned thumbnails.

zigger wrote:

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. ***

simonell wrote:

http://commons.wikimedia.org/wiki/Image:Fehler-abschnitt-bearbeiten-unter-text.png

I'm also using Mozilla

gangleri wrote:

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]]

hirsch.heisseich wrote:

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;

lupin.wp wrote:

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.

starwed wrote:

This can be seen on the page [[Artemis]]

gangleri wrote:

(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>

Wiki.Melancholie wrote:

*** Bug 5148 has been marked as a duplicate of this bug. ***

matthiasbinninger wrote:

(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.

hirsch.heisseich wrote:

*** Bug 6213 has been marked as a duplicate of this bug. ***

ayg wrote:

*** Bug 6713 has been marked as a duplicate of this bug. ***

matthiasbinninger wrote:

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.

ayg wrote:

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).

matthiasbinninger wrote:

(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.

ayg wrote:

(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).

jd wrote:

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?

matthiasbinninger wrote:

(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.

jd wrote:

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.

matthiasbinninger wrote:

(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.

ayg wrote:

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.

attachment 1629a.patch ignored as obsolete

rotemliss wrote:

*** Bug 6963 has been marked as a duplicate of this bug. ***

ayg wrote:

Comment on attachment 2204
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.

ayg wrote:

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.

rickblock wrote:

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 .

ayg wrote:

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.

rickblock wrote:

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.

Attached:

ayg wrote:

That appears to display quite well. I'll look into it tomorrowish.

ayg wrote:

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.

attachment 1629b.patch ignored as obsolete

ayg wrote:

*** Bug 9478 has been marked as a duplicate of this bug. ***

ayg wrote:

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.

peu wrote:

It would be great to have the german Wikipedia behavior by default:
DOM order wm-headline, editsection.

peu wrote:

(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?

ayg wrote:

(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.

ayg wrote:

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.

rotemliss wrote:

It was reverted in r24253 and r24254: it broke RTL on Firefox and also broke IE/Mac.

ayg wrote:

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. ***

ui2t5v002 wrote:

(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.

erikbaas wrote:

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. :-(

erikbaas wrote:

A much better example is on http://nl.wikipedia.org/wiki/Gebruiker:Erik_Baas/1629 .

ayg wrote:

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.

ayg wrote:

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.

ayg wrote:

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).

ayg wrote:

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. ***

RLUllmann wrote:

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>

ayg wrote:

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?).

RLUllmann wrote:

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)

ayg wrote:

(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?

wikipedia wrote:

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.