This needs a UI mockup for how to add it without confusing things...

Proposed mock-up for LTR and RTL languages: http://en.wikipedia.org/w/index.php?oldid=276361042

p.org wrote:

Good idea!

I already saw this implemented within a wiki, but cannot recall the particular wiki software.

If you hovered above a headline, a paragraph-symbol appeared next to the headline. If you clicked on the paragraph-symbol, you activated the anchored link, and could simply copy the URL from the address bar then.

• Bug 31039 has been marked as a duplicate of this bug. ***

It's hard to think of any websites without this feature. Even this very Bugzilla comment of mine already has this feature.

But my "[link]" makes more sense than "#" for how to label it. See Bug 31039.
Plus no goofy hover craft needed or wanted, just plain old HTML.

IMHO an icon with alt fallback probably makes the most sense here.

(In reply to comment #7)

IMHO an icon with alt fallback probably makes the most sense here.

Ah, http://www.fileformat.info/info/unicode/char/1f517/index.htm directly, if only it was more widespread.

Also, making it only appear on-hover of the heading (or atleast be less page-cluttering when not focussing it) would be nice.

(In reply to comment #9)

Also, making it only appear on-hover of the heading (or atleast be less
page-cluttering when not focussing it) would be nice.

:/ angry stares from every usability oriented person taking touch screens into consideration fall upon that comment.

Allow me to demonstrate the pain of [add my usual obligatory "dragging
your heels by not fixing this" remark here] not having this feature.

To make a proper Facebook™ link, one needs
http://transgender-taiwan.org/index.php?title=%E7%8F%BE%E6%99%82%E4%BA%8B%E4%BB%B6#.E5.8F.B0.E7.81.A3TG.E8.9D.B6.E5.9C.92_2011.2F10.2F16_.E8.81.9A.E6.9C.83.EF.BC.88no.65.EF.BC.89--_.E6.89.AE.E8.A3.9D.E7.9A.87.E5.90.8E
but there's no way in h*ll the "average user" is going to cobble that
together especially on such pages without enough items to trigger a TOC.

Whatever you do make sure it still works in text browsers, even if
unfamiliar territory.

*** Bug 25107 has been marked as a duplicate of this bug. ***

See also Bug 2381 - Copy-and-paste-friendly anchors for section headings.

Should this bug be marked as duplicate of that older one?

p.org wrote:

(In reply to comment #13)

I consider bug 2383 related to, but NOT a duplicate, of this bug!
This bug is about how to exhibit a section anchor link to the visible user interface,
whereas bug 2383 deals with how to generate special characters in anchor links.

I'm not sure this is really a parser bug. I'm switching the component to "Interface" and marking this bug with the "easy" and "design" keywords.

I also added a URL: https://www.mediawiki.org/wiki/Requests_for_comment/Clickable_section_anchors.

I think the next steps for this bug would be doing a few real-life mock-up implementations on a test wiki and then asking wikitech-l and others which is best. This bug shouldn't be very difficult to resolve.

-easy: given that we're not even able to move the "edit" link without JS, this is probably not easy at all.

(In reply to comment #16)

-easy: given that we're not even able to move the "edit" link without JS,
this is probably not easy at all.

Read comment 15.

For instance the comment 18 link you see above is achieved with a mere

<span class="bz_comment_number">

<a href="show_bug.cgi?id=16691#c18">Comment 18</a>

</span>

See, even I could do that.

shreeshikha21 wrote:

I am new to FOSS and mediawiki how do I start on this bug and how do I replicate the error on my local machine.

Shikha: Does https://www.mediawiki.org/w/index.php?title=Annoying_little_bugs&oldid=909298#Helpful_information_for_new_MediaWiki_coders provide some help?

(In reply to Shikha Shree from comment #19)

I am new to FOSS and mediawiki how do I start on this bug and how do I
replicate the error on my local machine.

Are you still interested in fixing this bug?

anurag3rdsep wrote:

I would like to take this issue, if there is noone opting for it.

anurag3rdsep: Sure, go ahead! :)

anurag3rdsep wrote:

Hello,
I just completed Mediawiki installation on my local system. Can anyone guide me as how to begin on this issue.

(In reply to anurag3rdsep from comment #24)

Can anyone guide me as how to begin on this issue.

In the spirit of https://www.mediawiki.org/wiki/Annoying_little_bugs#Feedback.2C_questions_and_support and http://catb.org/~esr/faqs/smart-questions.html which I recommend to read: What is specifically unclear with the bug description here, and what have you tried already, so we can help you?

@MZMcBride Pure HTML/CSS indeed. With HTML only needing minor changes to make it easier to do with CSS. I don't think the actual anchors themselves should be in HTML.

How can an anchor be created without HTML?

How can an anchor be created without HTML?

Sections already produce anchors. What's needed is some JS which, when hovering the headers in some way, offers a link to the anchor. It's debatable when/how to provide a graphical hint (usually the ¶ character) , but there are so many good examples to copy out there that design is certainly not a show stopper here.

Hi. I'm a beginner here and i was wondering if this bug was still open to take, Thanks

Hi. I'm a beginner here and i was wondering if this bug was still open to take, Thanks

It is. https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker contains useful pointers for your first steps.

Hi all! Is anyone working on this bug or is it still open to take?

If its open, I have tried to make a few changes to my test wiki to get the desired results (I think).

Link to my test wiki : test wiki

Since, we can't do the "display on hover" thing on touchscreen devices currently , so, I added some js to display para symbols directly on touchscreen devices.
Please comment and let me know of possible problems, feedback, etc...

Thanks

PS : I am a beginner too :)

@Nemo_bis We already have a functional JS version, at mw:MediaWiki:Gadget-vector-headanchor.js and mw:MediaWiki:Gadget-vector-headanchor.css (which I use and love, and wish it was everywhere).
IIUC, the current request is to make something that doesn't require JS. (?)

@MZMcBride @Krinkle Perhaps one of you could explain the technical aspects of the request more clearly, in the task description? Otherwise we're just going in circles. :-/

@Jaredzimmerman-WMF We (eventually) need help making decisions on:

1. Which Icon to use? (Once the general icon shape is decided, we can wrestle with variants/details)
   • § ( section sign )
   • 🔗 ( link symbol )
   • ¶ ( pilcrow / paragraph sign )
   • other
2. Icon Placement: Before (e.g.) or After (e.g.) the headings?
3. Should it be visible Hover-only, or Permanently, for desktop users?

(I'm preferring the initial option, in each case)

@Dpkshrma In your example, the "[edit]" links move back-and-forth when the pilcrow symbol dis/appears (in my browser, at least). Can you fix that? Also, could you link to the code that you're working with? I can see the common.js at your test wiki, but I'm not sure if there's anything else. (I'm not a dev, so I might be missing something obvious. I'm just trying to encourage collaboration via clarity. :-) Thanks!

Initially I would have said to place an icon left gutter (LTR) , but we've been playing with the idea of having that be the access point for editing, one of the original ideas someone proposed was to not have an icon at all, which means no hover to deal with, but make the section headers themselves the anchor links, and that by clicking on a section header the window would scroll to that section (ideally with scrolling animation) and append the anchor link to the url, users could also right click on section headers to grab urls for sections easily this way too.

Someone else pointed out that there are a few cases where heading contain links, but I've still yet to see this in practice.

Since none of these options are compatible with the current section headings or collapsing functions on mobile, I'd recommend this be desktop only for the time being, as the mobile teams are already experimenting with mobile appropriate share functionality that is likely to solve this in a mobile appropriate way.

In T18691#956209, @Jaredzimmerman-WMF wrote:

Someone else pointed out that there are a few cases where heading contain links, but I've still yet to see this in practice.

http://es.pokemon.wikia.com/wiki/Lista_de_Pokémon?useskin=monobook

Gracias @Ciencia_Al_Poder, I wonder how common this is, as having section anchor links seems like a great benefit for users, if these overrides are infrequently used it might be an acceptable situation to have these edge cases. Would it be possible to have the anchor links work in cases where users had not manually added links to headers but preserve them in the cases where they had?

In T18691#951463, @Quiddity wrote:

@Nemo_bis We already have a functional JS version, at mw:MediaWiki:Gadget-vector-headanchor.js and mw:MediaWiki:Gadget-vector-headanchor.css (which I use and love, and wish it was everywhere).
IIUC, the current request is to make something that doesn't require JS. (?)

@MZMcBride @Krinkle Perhaps one of you could explain the technical aspects of the request more clearly, in the task description? Otherwise we're just going in circles. :-/

Thanks.

The RFC page describes most of it. For the stylesheet to apply properly, my gadget modifies the page structure slightly using javascript. If we'd implement this natively in core, there'd be no need for javascript. There are some design and implementation choices to be made, but none should need javascript for anything. That won't be a problem.

In T18691#956209, @Jaredzimmerman-WMF wrote:

Someone else pointed out that there are a few cases where heading contain links, but I've still yet to see this in practice.

It's not common in articles (Enwiki specifically cautions against it: https://en.wikipedia.org/wiki/MOS:HEADINGS "Headings should normally not contain links, especially where only part of a heading is linked.")

But it does occur in project namespaces, e.g. throughout https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Log/Today and in many WP:ANI threads, and other locations around the place.

The other drawbacks listed at https://www.mediawiki.org/wiki/Requests_for_comment/Clickable_section_anchors#Option_3 are also relevant, particularly #4. (but #2 and #3 could use clarification):

• some headers already are or contain links.
• degrades readability
• typographically "bad"
• Inconsistency between this (a link which links directly to itself), and all other wiki links.

So would what I proposed just using the section header as the link, not colorizing or styling in differently, but changing the cursor on hover, respecting if there is an override by a users, and otherwise making it an anchor link work?

Thanks Krinkle. Good questions, Quiddity; again, I *think* ¶ is by far the most common.

In T18691#956267, @Jaredzimmerman-WMF wrote:

I wonder how common this is

Very easy to find out. I happen to have wikiteam dumps of 5 thousands wikis handy:

$ find /data/scratch/tmp/wikistats/ -name '*.bz2' -print0 | xargs -0 -P 8 -n 1 bzgrep -E "^==+.+\[\[" | sort -u | wc -l
345538

So, about 350k unique headers containing internal links, out of 5849633 total. It's a significant portion.

I've seen sites that automatically write to the URL as you scroll would
this be a way to do this transparenlty without UI at all?

Here are two common libraries that I've seen in use for this purpose

https://github.com/imakewebthings/waypoints

https://github.com/browserstate/history.js

The only issue (i remember from over a year ago) was that some of these
solutions interfere with the browser back behavior, which I'd want to
avoid.

*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation

M +1 415 609 4043 \\ @Jaredzimmerman http://loo.ms/g0

In T18691#961187, @Nemo_bis wrote:

Thanks Krinkle. Good questions, Quiddity; again, I *think* ¶ is by far the most common.

I agree that the pilcrow (or "paragraph sign") is very common. Though possibly that is mainly at sites that provide an anchor for each individual paragraph?
I've also seen "#" used a lot, for paragraph and/or section links.
I think that the section sign is more accurate for our purpose here, though.

Seeing as how this is high priority, we should probably get started with actually fixing it. The summary of suggestions from above seem to be as follows:

• an anchor is necessary
• options include
  • an icon
  • the heading itself (but these may contain internal links)
  • a symbol, such as § or #
  • not having links at all, but dynamically updating the URL while scrolling (browser history will have issues below HTML5)
• this needs to be done in core, not in JS
• a before/after decision needs to be taken, but maybe someone can work on this even before that

I'd like to get started on fixing this, but really can't unless ^ those decisions are made. At the moment, I'm considering a faded out § character before the heading which fades in on hover (CSS). Should I get started on this?

Someone's gotta make these decisions, might as well be you. :)

Change 186332 had a related patch set uploaded (by Polybuildr):
Add clickable link for section headers

https://gerrit.wikimedia.org/r/186332

Patch-For-Review

Is there an easy way for non-devs to test out this proposed implementation (along with the suggested answers to all the questions above) ? :-)

Also, check out the existing gadget Headanchor at https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-gadgets if you haven't already. It works really nicely. (a good page to test it on is https://www.mediawiki.org/wiki/Manual:FAQ )

@Quiddity, Headanchor does a marvellous job of implementing the feature, certainly better than the patch I just submitted. I could use the same design principles it's using and improve my patch, though.

@matmarex, @MZMcBride: Is there a reason why the gadget isn't directly being included in core to address this bug?

We'd want to reimplement the behavior in PHP anyway. I didn't know that this exists, huh.

Alright, so the patch isn't redundant then. I rather like the gadget's
design. I'll upload a new patch set in some time taking some inspiration
from it.

The new patch is almost ready, but there's a small issue.

I need to either add the class mw-heading to the heading element being generated by makeHeadline or write css for .mw-body-content h1, .mw-body-content h2 ... and corresponding hover styles. Initially, I was doing $attribs = " class=\"mw-heading\"" . $attribs; in makeHeadline but this would break horribly if there were other classes to be added in $attribs.

Which of the approaches should I pick and if the former, how should I go about adding a class to the $attribs string?

Uploaded PS3. The section symbol appears to the left of the heading now, only on hovering over the heading (very similar to Headanchor).

For the issue I had about adding a class, I've manipulated the $attribs string in makeHeadline to add the mw-heading class and handled the case when there might already be a class attribute.

@Fomafix points out in https://gerrit.wikimedia.org/r/#/c/186332/ that there is a certain case in which overflow:visible might cause issues. The test case involves floating text next to a header. I'm not sure that it is common enough to dismiss the use of visible overflow. Also, it doesn't seem to cause much damage. Is this a valid concern? Headanchor applies the same rule, so does anyone know of any issues with it?

I created T88220 for removing overflow:hidden and replace it by some equivalent.

The current patch seeks to remove a key property (overflow:hidden) that makes headers behave with nearby floating elements, such as tables, infoboxes, sidebars and whatever other template that may be present. This would cause a regression.

Also, is using opacity the best way here? Seems like this can be accomplished a lot easier. (Personally, I don't like hidden elements that pop up unexpectedly; it is unintuitive.)

@Edokter, yes, there seem to be some issues with using overflow: visible for the headings. Things (some from the above discussion) that led me to use both that and opacity, though, are:

1. Several people suggested that they would not like to have a section symbol always present on the page since it would make things look cluttered. The proposed solution was to only show the clickable link on hover. An earlier patch I submitted had a faded out section symbol that faded in on hover.

2. @Quiddity pointed out that there is a Headanchor gadget (in JS, authored by @Krinkle, I think) that does what this task requires and does it well. I looked at it and really liked the design. The gadget uses overflow: hidden too. After this I changed my previous patch to behave like it does (appear on hover).

3. I'm not sure whether your objection is specifically to using opacity or to elements appearing on hover. The latter I've explained in point 1 and 2. As for the former, since I'm using a character, font-size: 0 would not work. Hover events (or :hover) do not fire on visibility: hidden hidden elements and I did not want to add a wrapper element on which :hover could fire. Hence, I resorted to using opacity with the IE fallback.

@Krinkle, @MZMcBride, @Jaredzimmerman-WMF what is your say on all this?

The edit links are not the only floating elements that benefit from overflow:hidden. There are gadgets that might add floating content, and of course all floating templates (with transparent backgrounds) will be malformed. If a key property is in the way, find a way around it; don't just throw it out and hope for the best... that's just lazy.

It all boils down to wanting the icon (btw. why not also use bg-image instead of opacity?) outside of the header. Either move the icon to somewhere inside the header, or add a positioned element instead. That way, you won't have to change the existing structure and there will be no regressions.

One option might be to use absolute positioning for the clickable link and
apply a relative position to the heading.

Also, keeping the element outside the header means I can try to keep the
rest of the layout almost the same as it is right now - less interference
that way. And I didn't use an image because the section symbol was already
readily available, but I suppose that is an option.

Side-note: I just noticed the {{see also|List of most watched television broadcasts#United States}} hatnote at https://en.wikipedia.org/wiki/Super_Bowl#Television_coverage_and_ratings converts the # into § (with spaces on either side). That's neat.

One option that I'm experimenting with right now that doesn't seem to have all the problems that the overflow: visible solution does is to add a wrapper around each heading generated by makeHeadline inside which I can put the both, the clickable link as well as the <hn> itself. Then, position: relative on the wrapper, position: absolute on the clickable link seems to take care of the issue, since the hidden overflow still applies to the heading and the clickable link can still float to the left of the heading.

@Edokter, @Fomafix, how does that sound?

The only issue I'm facing (which is the reason I haven't uploaded a patch set yet) is that the clickable link looks out of place if it doesn't have some styles that are same as the heading itself (line height, font size, etc.) and these are set by each skin. What is the appropriate way to deal with this?

An element outside of <hx> should be possible and removes the dependency to T88220.

The nicest way would be

h1:before,
h2:before,
h3:before,
h4:before,
h5:before,
h6:before {
	...
}

but it is not possible to create a clickable element.

Just some thoughts... How would just styling the header as a link in hover sound?
(Answering myself, that may interfere with links already in the header.)

The left gutter approach also seems troublesome; there is only enough space in Vector. Or is Vector the only target?

I expect usage to be low, so why not just a right-floating icon/link (where the edit button used to be?) That would be the easiest to code.

Building upon Edokter's idea, what about making all headers cursor: pointer, and making clicking on it give the anchor link?

This may slightly break a user's expectations, however it should still be discoverable and not be unintuitive - an average user will eventually spot the cursor hand and try to click, therefore discovering this feature. Biggest advantage is no visual clutter, no significant visual changes on hover.

@Edokter, @Unicodesnowman: While I did initially like your idea of making the heading itself clickable, it later occurred to me that your solution would probably involve nesting <a> tags, which is invalid HTML. This could be handled with javascript to provide the same effect but I feel like that would be overkill and possibly inelegant.

@Edokter, a right floating link would certainly be easier to code, but would that not clutter up the right side of heading too much? I always thought even the edit link looked slightly out of place, but that's just my view. Also, if the few people are already using the Headanchor gadget (I don't know how many, of course), would it not help to keep the behaviour consistent?

@polybuildr, making the header a link was not a good idea, so forget that.

Since the [edit] link has moved to the left two years ago, there is no clutter on the right side. As the anchor link need not be as prominent as the [edit] link, I don't think it is out of place there, especially with :hover. Plus, any gadget that may add any right-floating element to the header will ensure they play nice with eachother.

@Edokter, I'm sorry, but I don't think I understand.

1. The edit link moved to the left two years ago? Where was it earlier?
2. The anchor link, if people still think it should be a § character, will look very out of place on the right. As far as I know, that particular symbol always appears on the left. If the symbol were replaced with something else, then yes, maybe it would not look out of place.
3. The Headanchor gadget adds a link to the left. And if the clickable anchor were on the right and another gadget were to add a right floating element, would that not mean trouble? How would they play nicely with each other?

1. The [edit] link used to be all the way on the right edge of the page. It now sits right next to the header text; it is no longer floating. (There is a gadget on enwiki to move them to the right again.)
2. I missed that. I was thinking about a link (chain) symbol as used by the Headanchor gadget.
3. Multiple floating inline elements in the header will sit next to eachother wihtout getting in eachothers way

If using §, another option is just to put it in front of the header text (but not in the gutter), then it would show as:

§ Header text____________________

@Edokter, I see. I didn't know about the far right floating [edit] links, though I should have figured that out based on the discussions on the patch set.

I did explore the option of putting it in front of the header in my initial patch sets. However, there were two basic concerns.

1. If the symbol is visible all the time, then the heading looks slightly cluttered (or at least conspicuously different). (PS1, I think)
2. If it only appears on hover, then the headings look awkwardly pushed forward (or get pushed forward on hover, depending on whether its visibility is hidden or it has display: none set).

This was why I decided to go the same way as Headanchor and put the symbol in the left gutter.

Okay, I have no idea how I didn't realize this before, but a simple position: absolute on the clickable anchor solves pretty much every issue we had.

PS6 uploaded. overflow: hidden is not removed and the clickable anchor (using the § symbol) floats to the left of the heading using a negative margin. Since it's a child of the <hn> tag, it inherits the styling from the parent, but the absolute positioning allows it to pop out of the hidden overflow.

Please let me know if there are any issues. Else we can finally put this ~6 year old task to rest.