Page MenuHomePhabricator

Section edit links should be moved down .5em
Closed, ResolvedPublic

Description

Author: andersk

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


Version: unspecified
Severity: normal

Details

Reference
bz4525

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:02 PM
bzimport set Reference to bz4525.
bzimport added a subscriber: Unknown Object (MLST).
  • Bug 4518 has been marked as a duplicate of this bug. ***

michael wrote:

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

ayg wrote:

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.

michael wrote:

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.

ayg wrote:

Should be fixed in r16962 (see also r16963).

ayg wrote:

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.