Last modified: 2006-10-18 06:54:21 UTC
skins/monobook/main.css has padding-top: .5em on h1,h2,h3,h4,h5,h6, but not on div.editsection. This results in the [Edit] links being .5em too high, giving the appearance that they are related to the *previous* section instead of the next one. Things would be much less confusing with div { padding-top: .5em; } in main.css.
*** Bug 4518 has been marked as a duplicate of this bug. ***
Actually, because the h2 section heading has font-size:150%, and div.editsection has font-size:smaller (by a factor of 1.2 in CSS2), the correct value is: 0.5em × 150% ÷ 1.2 = 0.9 The following appears to work perfectly in Safari 2.03 and Firefox 1.5.0.1: div.editsection { padding-top: .9em } The problem is, h3 through h6 each have a different font size, so the edit links will not align to them. A good way to fix this would be to use a better semantic structure for sections and subsections, so the relevant edit links could be formatted individually (see Bug 4741: Semantic HTML for section anchors). As long as changes are being made, the edit link could be moved after the section heading, or even into a span in the heading. Class or contextual CSS selectors could then be used to format everything in lots of different ways. The HTML for a section and subsection could look like this: <div id="Section" class="s2"> <h2>Section <span class="editsection">[<a href="...">edit</a>]</span></h2> . . . <div id="Subsection" class="s3"> <h3>Subsection <span class="editsection">[<a href="...">edit</a>]</span></h3> . . . </div><!-- /subsection --> </div><!-- /section -->
<http://openusability.org/download.php/89/germanwikipedia_usabilitytest_edit.pdf> notes that two users of their 10-user sample thought that section edit links belonged to the section above the actual section because of where they were placed, became confused, and actually deleted the unexpected content. Surprisingly, this is more than an aesthetic issue. I like your mockup, BTW.
Actually, it looks like it's even worse. Of the ten first-time editors, only two tried using section edit-links, and ''both'' of them thought they were editing the paragraph above. As a result, they both mistakenly deleted information. It's not clear which browser they were using, but from the screenshots (e.g. p 13) it clearly draws the section edit links well above the heading's underline, so they look like they belong to the previous section.
Should be fixed in r16962 (see also r16963).
Temporarily uncommitted pending JavaScript tweaks to work with the new structure.
When you reapply, don't forget to bump the numbers on all the CSS and JS urls, or display will be incorrect due to caching.
Fixed in r17078.
