Last modified: 2014-09-24 01:12:22 UTC
Created attachment 4095 [details]
Section edit links don't seem like they belong to the section below. Brion made a good proposal to fix that in the thread linked below; here's my implementation of that in a patch.
* Tested on Firefox 220.127.116.11, Opera 9.23 natively on Ubuntu; IE5, 5.5, 6 via ies4linux
* With small browser windows/long headings, edit link is drawn on top of some header text: this needs to be fixed with a right margin (not elegant, but it should work easily enough)
* Patch is for Monobook only for the time being
* The way I remove the brackets is hacky and should be fixed up
Comments and further testing appreciated.
See: <http://lists.wikimedia.org/pipermail/wikitech-l/2007-June/031899.html>. Also, note that this should fix bug 1629 as well.
Comment on attachment 4095 [details]
Okay, thanks to _Danny_B_ for pointing out that this completely breaks with right floats. Floats will be needed to work nicely with floats, but it's impossible to get floats to position precisely across browsers, that I can see. I think the German way of doing it, with the edit link on the left, has gone back to being the best choice, although it might use these tabs if people like them more than the bracketed link.
If you are changing edit link format, you could also try to fix another small usability bug: triple-clicking on the section header (as a quick way to copy-and-paste it) also selects the  text.
(In reply to comment #2)
> If you are changing edit link format, you could also try to fix another small
> usability bug: triple-clicking on the section header (as a quick way to
> copy-and-paste it) also selects the  text.
I don't know how to fix that without details on the heuristic used.
(In reply to comment #3)
Firefox seems to select to the end of the line box. In the current arrangement, putting the editsection span before the h2, and removing the inner (mw-headline) span worked (don't know why the latter was neccessary). IIRC Explorer 6 does the same (no idea about 7), and Opera until the end of the sentence (that is, the colon).
I have no idea how to do this together with Brion's fix, but maybe somebody with a better understanding of CSS and browser engines can help...
(There is also a Gecko-specific "-moz-user-select:none" CSS setting and an explorer-specific "unselectable=on" HTML attribute, but neither did anything useful for me.)
I suggest you open a different bug for that request.
Other bugs related to section edit link handling: bug 1629, bug 11555.
I've investigated an alternative: absolute positioning with respect to the header text, i.e., an inline element. This actually works fairly well, but browser support is unacceptable: Firefox gets it wrong (https://bugzilla.mozilla.org/show_bug.cgi?id=5016), IE probably does. Opera seems to work, but that's not enough to proceed.
So, I think absolute positioning is out. I think it has to be positioned with respect to inline flow. I don't think there's any way to get reliable tab-like appearance or anything, in that case, because you don't really know how high above the lower border it is. So I would just do it the German way and if anyone can come up with a neat tab appearance later, great, it's not like it's going to break anything at that point. This will also fix bug 11555.
Created attachment 4571 [details]
Proposed patch (German solution)
This patch appears to be fully correct. It will, of course, break all user styles relating to section edit links and so on, so I'm not going to commit it immediately. However, I'm willing to commit it as soon as Brion gives permission.
CCing Brion. Brion, please give the okay/don't. Note, this also fixes bug 11555 and bug 1629. Bug 11555 can't reasonably be fixed without document structure changes similar to these (although it could keep the current element order, and the floats).
Created attachment 6212 [details]
Updated patch to apply cleanly to SVN HEAD, and added changes for Vector extension.
Committed to SVN by Roan (catrope) in r52410.
... and apparently reverted by Roan in r52414.
Created attachment 6731 [details]
Brought the last patch up to date
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
This issue has been validated through qualitative user testing, where observed users were frequently confused which section an edit link was related to, and often times users did not see the link at all.
Recently a quantitative test was performed on English Wikipedia, which measured the click-through rates between displaying the section edit link on the opposite side of the content area as the heading, and showing them next to the heading and displaying an icon next to the link. Users who were given section edit links near the heading were 117% more likely to use them, and about 10% more likely to complete an edit.
Repatched in r93284
Reverted in r93299.
Do we know exactly what issues there still are with the patch? Most of what got committed in r93284 looks the same as Roan's 2009 update of Aryeh's patch, and the 2009 revert only says there were "unresolved issues".
This is a LONG-outstanding issue, and it needs to actually get done one way or another.
(In reply to comment #18)
> Do we know exactly what issues there still are with the patch? Most of what got
> committed in r93284 looks the same as Roan's 2009 update of Aryeh's patch, and
> the 2009 revert only says there were "unresolved issues".
As I said in the commit, I tested it with all kind of browser in all skins both rtl and ltr and didn't find anything. (There was a minor bug where the header underline was too short in modern skin, but that was easily fixed).
Given the past reversions, I think it would be easier to create a branch to work on this. Then DieBuche can apply the patch in several commits and we could all work on this OUT of the trunk.
Once the branch has been stabilized and reviewed, we will be able to merge it in trunk and it will just be marked ok :-)
DieBuche, can you make such a branch and start your work in it?
Seems like this patch needs review (before it can finally be committed) or needs to be turned into a branch, so I'm marking it need-review to indicate that.
Hi Roan, thank you for the patch!
As you may already know, MediaWiki is currently revamping its PHP-based parser
into a "Parsoid" prototype component, to support the rich-text Visual Editor
Folks interested in enhancing the parser's capabilities are very much welcome
to join the Parsoid project, and contribute patches as Git branches:
Compared to .diff attachments in Bugzilla tickets, Git branches are much easier
for us to review, refine and merge features together.
Each change set has a distinct URL generated by the "git review" tool, which
can be referenced in Bugzilla by pasting its gerrit.wikimedia.org URL as a
If you run into any issues with the patch process, please feel free to ask on
irc.freenode.net #wikimedia-dev and the wikitext-l mailing list. Thank you!
(In reply to comment #22)
> Hi Roan, thank you for the patch!
> As you may already know, MediaWiki is currently revamping its PHP-based parser
> into a "Parsoid" prototype component, to support the rich-text Visual Editor
I think it's possible that Roan is aware...
Note that mozilla bug 5016 has been fixed for years in the meantime. I also wonder what were the issues, just the parsertests?
(In reply to comment #23)
> (In reply to comment #22)
> > Hi Roan, thank you for the patch!
> > As you may already know, MediaWiki is currently revamping its PHP-based parser
> > into a "Parsoid" prototype component, to support the rich-text Visual Editor
> > project:
> > https://www.mediawiki.org/wiki/Parsoid
> > https://www.mediawiki.org/wiki/Visual_editor
> I think it's possible that Roan is aware...
Related: bug 41729