Last modified: 2014-09-24 01:12:22 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 11270 - Make section edit links more usable/understandable
Make section edit links more usable/understandable
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Normal enhancement with 3 votes (vote)
: ---
Assigned To: Roan Kattouw
http://taizhongbus.jidanni.org/index....
: design, patch, patch-need-review
Depends on: 19588 22982
Blocks: semantic-html editlinks 21614
  Show dependency treegraph
 
Reported: 2007-09-10 01:55 UTC by Aryeh Gregor (not reading bugmail, please e-mail directly)
Modified: 2014-09-24 01:12 UTC (History)
14 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Proposed patch (3.49 KB, patch)
2007-09-10 01:55 UTC, Aryeh Gregor (not reading bugmail, please e-mail directly)
Details
Proposed patch (German solution) (12.82 KB, patch)
2008-01-24 02:56 UTC, Aryeh Gregor (not reading bugmail, please e-mail directly)
Details
Updated patch (15.00 KB, patch)
2009-06-09 13:52 UTC, Roan Kattouw
Details
Updated patch (16.47 KB, patch)
2009-10-28 21:55 UTC, Roan Kattouw
Details

Description Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-09-10 01:55:37 UTC
Created attachment 4095 [details]
Proposed patch

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 2.0.0.6, 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 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-09-10 02:31:52 UTC
Comment on attachment 4095 [details]
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.
Comment 2 Tisza Gergő 2007-09-15 10:49:14 UTC
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.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-09-16 02:52:59 UTC
(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.
Comment 4 Tisza Gergő 2007-09-16 10:06:20 UTC
(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.)
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-09-16 20:41:12 UTC
I suggest you open a different bug for that request.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-21 18:27:39 UTC
Other bugs related to section edit link handling: bug 1629, bug 11555.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-26 03:25:33 UTC
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.
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-24 02:56:17 UTC
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.
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-24 02:59:53 UTC
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).
Comment 10 Roan Kattouw 2009-06-09 13:52:10 UTC
Created attachment 6212 [details]
Updated patch

Updated patch to apply cleanly to SVN HEAD, and added changes for Vector extension.
Comment 11 MZMcBride 2009-06-26 04:08:16 UTC
Committed to SVN by Roan (catrope) in r52410.
Comment 12 MZMcBride 2009-06-26 04:09:35 UTC
... and apparently reverted by Roan in r52414.
Comment 13 Roan Kattouw 2009-10-28 21:55:09 UTC
Created attachment 6731 [details]
Updated patch

Brought the last patch up to date
Comment 14 p858snake 2011-04-30 00:09:25 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 15 Trevor Parscal 2011-05-13 13:32:49 UTC
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.
Comment 16 DieBuche 2011-07-27 17:01:05 UTC
Repatched in r93284
Comment 17 Krinkle 2011-07-27 20:10:27 UTC
Reverted in r93299.
Comment 18 Brion Vibber 2011-07-27 20:20:29 UTC
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.
Comment 19 DieBuche 2011-07-27 21:01:22 UTC
(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).
Comment 20 Antoine "hashar" Musso (WMF) 2011-07-29 12:02:47 UTC
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?
Comment 21 Sumana Harihareswara 2011-11-09 03:24:02 UTC
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.
Comment 22 au 2012-06-17 18:40:53 UTC
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!
Comment 23 MZMcBride 2012-06-17 20:47:23 UTC
(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...
Comment 24 Platonides 2012-06-17 21:21:22 UTC
Note that mozilla bug 5016 has been fixed for years in the meantime. I also wonder what were the issues, just the parsertests?
Comment 25 Oliver Keyes 2012-10-17 14:19:56 UTC
(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
Comment 26 Steven Walling 2012-11-09 00:31:29 UTC
Related: bug 41729

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links