ayg wrote:

Comment on attachment 4095
Proposed patch

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 [edit] text.

ayg wrote:

(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 [edit] 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.)

ayg wrote:

I suggest you open a different bug for that request.

ayg wrote:

Other bugs related to section edit link handling: bug 1629, bug 11555.

ayg wrote:

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.

ayg wrote:

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.

attachment patch ignored as obsolete

ayg wrote:

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

Updated patch to apply cleanly to SVN HEAD, and added changes for Vector extension.

attachment editsection.patch ignored as obsolete

Committed to SVN by Roan (catrope) in r52410.

... and apparently reverted by Roan in r52414.

Created attachment 6731
Updated patch

Brought the last patch up to date

Attached:

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

sumanah wrote:

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.

audreyt wrote:

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

Folks interested in enhancing the parser's capabilities are very much welcome
to join the Parsoid project, and contribute patches as Git branches:

https://www.mediawiki.org/wiki/Git/Tutorial#How_to_submit_a_patch

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

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

https://www.mediawiki.org/wiki/Parsoid
https://www.mediawiki.org/wiki/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...

Quite ;p

swalling wrote:

Related: bug 41729

Isn't this task resolved now? Section edit links are next to headers these days.

PS: landing here because this is the oldest task assigned to @Catrope.