RFC: Section headings should have a clickable anchor
Open, NormalPublic

Tokens
"Love" token, awarded by Sebastian_Berlin-WMSE."Like" token, awarded by Liuxinyu970226."Love" token, awarded by eflyjason."Love" token, awarded by Kaartic."Love" token, awarded by Niharika."Like" token, awarded by Pcoombe."Like" token, awarded by Ciencia_Al_Poder."Like" token, awarded by He7d3r."Dislike" token, awarded by Jooojay."Like" token, awarded by waldyrious."Like" token, awarded by gpaumier."Like" token, awarded by Arghman."Like" token, awarded by fbstj."Mountain of Wealth" token, awarded by Nemo_bis.
Assigned To
None
Authored By
brion, Dec 17 2008

Description

NOTE: Clickable section anchors ("§" next to page headers) were implemented and briefly deployed in March 2015. However, the specific way that clickable section anchors were added caused issues, discussed below, and the feature has been reverted and un-deployed.

Say you're in the middle of a long page and want to pass somebody a link... A link to the particular section would often be more helpful than just a link to the top of the page, but to do that right now you have to jump up to the table of contents and find your section again, then click that link.

It would be nicer if the section header itself were clickable, or had a little link anchor thingy you could click next to it that had the #blah bit on it to cut-n-paste or drag-n-drop.


Supplement

Requirements

  1. the feature is "activated" by hovering the header text;
  2. the link is offered in a symbol of some sort next to the header text, similar to what many do;
  3. the link is a normal one, i.e. left-click centers the section (but does not copy to clipboard) and right click + copy link can be used.

Things to watch for and possibly avoid

  1. The section symbol is being read aloud by screen readers when navigating the page by headings.
  2. The symbol appears in unexpected places due to being included in HTML (like Geohack or Google search results).
  3. Literal headings (<h2> etc.) should not have clickable section link anchors (T91271).
  4. No way to hide the symbol where it negatively affects the design (mostly main pages).
  5. The symbol § could be confusing, possible alternatives: #, , 🔗 (last one is emoji, not widely supported), Link_icon.svg.

Possible blockers or subtasks

  1. T13555: .mw-editsection links should not be part of the <h#> element
  2. ...

Workarounds

See also

Details

Reference
bz16691

Related Objects

Mentioned In
T76629: Numeric anchor in phabricator to link to a comment of a task does not work in IE11
T125865: Assign RFCs to ArchCom shepherds
T114851: Add more adequate interface for linking to topics
T54813: Remove "Show table of contents (for pages with more than 3 headings)" user preference from MediaWiki core
T93682: Added § symbol to 'See more' in the Image Gallery
rMW6b64c32e200d: Emergency remove .mw-headline-anchor
rMW520540538539: Emergency remove .mw-headline-anchor
T93187: Uncaught “URIError: malformed URI sequence” on en.wiktionary (fixed in jquery.cookie >= 1.4.0?)
T93000: [Regression] Google is indexing "§" characters in search result excerpts
T91865: Grey symbol on left side appearing when hovering over sections title
T91381: Comments lost in phabricator ticket T18691
rMWd5f4e01f7c7f: Hide section anchor links from screen readers using aria-hidden
rMWd2a6a73d2974: Hide section anchor links from screen readers using aria-hidden
T89690: Longer Maniphest tasks not fully displayed (as Phabricator defines a result set limit as 100 rows)
T91093: Document when to use Wikicon link icon vs. section sign '§'
T90091: Improve the UX of section anchor links
T90019: [Regression pre-wmf19] Headline anchor appearing next to all heading in Readmode
rMW6c7480e5f03e: Add clickable link for section headers
T88220: Remove overflow:hidden for headings
T86223: ToC: links to topics within the board, do not change the URL in the address bar
T78232: Make Special:Preferences preference heading IDs (for linking) discoverable
Mentioned Here
T93000: [Regression] Google is indexing "§" characters in search result excerpts
T91271: Literal headers should not have clickable section link anchors
T13555: .mw-editsection links should not be part of the <h#> element
T91093: Document when to use Wikicon link icon vs. section sign '§'
T90091: Improve the UX of section anchor links
T88220: Remove overflow:hidden for headings
There are a very large number of changes, so older changes are hidden. Show Older Changes

U+1F517 is only workable using a webfont, as no standard font (that I know of) supports this character. I suggested putting the link symbol in WikiFont earlier.

Qgil added a comment.Mar 25 2015, 10:03 AM

I suggested putting the link symbol in WikiFont earlier.

@matmarex added it ( https://commons.wikimedia.org/wiki/File:Link_icon.svg
) as a possibility as well. Flow uses is to provide a permalink of every comment, which is a very similar use. I have no opinion about how the icon should be used, but perhaps we can settle at least on this Wikifont icon?

(We probably won't go back to using it, but I just ran into an example of "§" being used in this way: http://dev.w3.org/csswg/selectors-4/#context. Just linking as a curiosity. :) )

Pretty much what we had here, but they have a big gutter to work with...

w3.org uses

xxx::before {
  content: "§";
}

to keep the § out of HTML.

Nemo_bis added a comment.EditedApr 3 2015, 9:50 AM

Several users complaining about the disappearance of the feature at https://it.wikipedia.org/w/index.php?title=Discussioni_aiuto:Sezioni&oldid=71747727#Segno_.22.C2.A7.22_accanto_ai_titoli_delle_sezioni

I think being a native speaker of the language is citation enough.

Not for serious business. CLDR requires sources from native speakers, too.

(I have seen complaints about the feature disappearing at other wikis as well, but I would like to see the alternatives discussed somewhere.)

Make a "global gadget" for reimplementing the feature? Oh, wait...

Change 194377 abandoned by Bartosz Dziewoński:
sectionAnchor:Move § from HTML to CSS

Reason:
The feature has been removed for now.

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

Change 195032 abandoned by Bartosz Dziewoński:
mediawiki.sectionAnchor: Decrease contrast for section anchor symbol

Reason:
The feature has been removed for now.

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

GOIII added a subscriber: GOIII.Apr 23 2015, 2:10 AM

Using a chain-link image in an icon for this nuance doesn't make sense -- one day somebody is going to come up with a VE link dialog that is flexible enough to incorporate anchor ids on the fly; making the use of "chain links" for URLs with and without anchors convoluted at best.

And sorry to the objectors looking for citations - the section symbol is used more often than not in legal/legislative type of works than anywhere else by far.... that won't make sense either.

.fa-anchor::before {
    content: "\f13d";
 }



So am I missing something or isn't an anchor icon appropriate to indicate/depict the anchor (or fragment) identifier of an URL?

I see there is one used at the top of this very page appearing before the word "Maniphest" and I'm guessing fa- must mean "Font Awesome".

Yes.

That's an interesting idea. I worry that "anchors" are a bit programming-jargony in this context, and I personally greatly dislike icons that are clever visual puns, but unintuitive. But then, so is the "link" icon.

wctaiwan removed a subscriber: wctaiwan.Apr 23 2015, 6:07 AM
GOIII added a comment.EditedApr 23 2015, 6:36 AM

<shrug> nothing snarky about it

It is the way I've always come to think of the anchor id[entifier] re: URLs ( boy do I feel old all of a sudden)

And fwiw.... it seems like Mozilla and W3 pretty much uses the same verbiage today.

Change 193797 abandoned by Umherirrender:
mediawiki.sectionAnchor: Show section anchor link when focused

Reason:
The whole feature was removed by Ie9e334e973e3ded270f1897a2c3816d9df739fc0

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

Tbayer added a subscriber: Tbayer.Jun 10 2015, 5:28 AM
Jdlrobson lowered the priority of this task from High to Normal.Dec 2 2015, 11:45 PM
Jdlrobson added a subscriber: Jdlrobson.
Krinkle renamed this task from Section headings should have some clickable anchor for passing links to RFC: Section headings should have a clickable anchor.Feb 3 2016, 9:32 PM
Krinkle removed a subscriber: Jaredzimmerman-WMF.

We discussed this at the Front-end_standards_group 2016-03-09 meeting (and the group also discussed this at earlier meetings) @Volker_E is planning on studying this problem over the next couple of weeks to ensure we're doing this for the right reasons.

ensure we're doing this for the right reasons

This part is not under discussion, only the implementation details are.

Qgil removed a subscriber: Qgil.Mar 10 2016, 10:33 AM

It would also be great to promote HTML5 compatible fragment identifiers. I introduced the old '%ee' -> '.ee' hack for XHTML 4 compatibility a long time ago, before UTF8 or '%' was allowed in fragment ids. We will still need to support those old ids for a while, but readability and code auto-generating new fragment ids would be simplified if we promoted sane HTML5 ids instead.

I could swear that there is a Parsoid task for this already, but I wasn't able to find it. Perhaps @ssastry is interested in chiming in.

ensure we're doing this for the right reasons

This part is not under discussion, only the implementation details are.

On the contrary. The decision for whether we should have section anchors is in fact the primary discussion point right now. Once we're passed that, if the outcome is positive, we can discuss the implementation details.

In the first iteration of this RFC we went to implementation too quickly. Now, with Volker and design team on board, it's become clear that section anchors aren't "obviously" good to have. They are desirable by power users, which may be reason to implement this as an opt-in gadget.

In the Frontend Standards Group earlier this month, Volker made a good point that section anchors may not be very discoverable (we're not saying they aren't, it's just an unanswered UX question). And it may also not be clear in its purpose. (As power users we want to link people to a specific section and this feature helps that. But it may not be very natural or even common to get such an idea. Is this something people generally understand as something they can do on the web?) In addition, a better table of contents may make this feature obsolete.

For instance, imagine the table of contents being in the sidebar, being visible at all times (allowing you to get the permalink from there by right clicking). Or better yet, it can automatically highlighting the current section in the table of contents and update the browser's address bar to reflect the section you're in.

Such table of contents involve other considerations of course, but the point is we want to explore the underlying intent (sharing a link to a section) and later decide how we'll address that (section anchors, or perhaps something else).

For instance, imagine the table of contents being in the sidebar, being visible at all times (allowing you to get the permalink from there by right clicking). Or better yet, it can automatically highlighting the current section in the table of contents and update the browser's address bar to reflect the section you're in.

Given how much controversy section anchors have raised, I doubt the proposed sidebar design is becoming default quietly ;-)

In the first iteration of this RFC we went to implementation too quickly. Now, with Volker and design team on board, it's become clear that section anchors aren't "obviously" good to have.

What? We already have section anchors on most pages. We auto-generate a table of contents that contains them and any == heading == includes an anchor in its HTML output. It's completely obvious that section anchors are good to have.

The question here is how to better expose these anchors to users. As Brion noted when filing this task, requiring that the user scroll all the way up to the top of the page and find the appropriate link in the table of contents is a real and defined usability problem.

In the Frontend Standards Group earlier this month, Volker made a good point that section anchors may not be very discoverable (we're not saying they aren't, it's just an unanswered UX question). And it may also not be clear in its purpose. (As power users we want to link people to a specific section and this feature helps that. But it may not be very natural or even common to get such an idea. Is this something people generally understand as something they can do on the web?) In addition, a better table of contents may make this feature obsolete.

Maybe a future magical table of contents box would resolve the usability issue here, but I prefer to work in the present reality.

Users definitely expect anchors and they're common throughout the Web. There are citations in this task pointing to World Wide Web Consortium sites using clickable section anchors. I don't know how much more evidence is required to demonstrate that this feature is part of the Web. github.com and python.org and many other sites have already figured this out.

[..] it's become clear that section anchors aren't "obviously" good to have.

What? We already have section anchors on most pages. We auto-generate a table of contents that contains them and any == heading == includes an anchor in its HTML output. It's completely obvious that section anchors are good to have.

The HTML attribute indeed has no negative impact and is both desired and required for any section link to work (e.g. in the summary of section edits), redirects, table of contents, etc. I was referring here to *clickable* section anchors - the thing this RFC is about.

Nemo_bis removed a subscriber: Nemo_bis.Mar 25 2016, 8:27 AM

The HTML attribute indeed has no negative impact and is both desired and required for any section link to work (e.g. in the summary of section edits), redirects, table of contents, etc. I was referring here to *clickable* section anchors - the thing this RFC is about.

The table of contents box contains clickable section anchors. These clickable section anchors are indisputably useful. Exposing additional links to these same section anchors in a place other than the table of contents box (typically next to the heading or section in question) is a common Web practice. If @Volker_E has views on this task, Phabricator Maniphest is the place to discuss.

@Volker_E gathered various considerations and challenges on the RFC’s talk page at https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Clickable_section_anchors.

Link above from @Krinkle's comment features a collection of questions and challenges, which have been arising in this task's discussion only within the last year, starting with T18691#1098025 from March 2015. Haven't yet compiled all unresolved questions into it.

@Volker_E gathered various considerations and challenges on the RFC’s talk page at https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Clickable_section_anchors.

I looked at this talk page section the other day. My impression was that @Volker_E was drafting/expanding/updating the RFC, but on the talk page instead of on the subject-space page. This was confusing to me.

I'd prefer that we combine/merge this task's description, the RFC subject-space page, and that talk page section into a single body of text. Even if we ultimately decide to not implement this feature, we should at least have a coherent and unified document to point people to.

I'd prefer that we combine/merge this task's description, the RFC subject-space page, and that talk page section into a single body of text. Even if we ultimately decide to not implement this feature, we should at least have a coherent and unified document to point people to.

I've overhauled https://www.mediawiki.org/wiki/Requests_for_comment/Clickable_section_anchors (including many details on iconography) and merged the new content from the talkpage together with that.
Hopefully someone else can merge this task's description with that page, in a minimally redundant/confusing way.

I personally would love to be able to have a reliable way of linking to sections, but this is admittedly me focused on my own personal use case.

A related problem that might be a precursor to solving this one correctly: do we have a way of creating a reliable link to a section? For example, what is the stable link to the https://www.mediawiki.org/wiki/Requests_for_comment/Clickable_section_anchors#What_to_share.2Fcopy section of this RFC? Is there a way of turning that into https://www.mediawiki.org/wiki/Requests_for_comment/Clickable_section_anchors#sharing without changing the title of that section to "=== sharing ==="?

One reason for wanting the anchor link is the anchor escape mechanisms make it a real pain to even remember a link.

jayvdb added a subscriber: jayvdb.EditedMay 12 2016, 2:02 AM

A related problem that might be a precursor to solving this one correctly: do we have a way of creating a reliable link to a section? For example, what is the stable link to the https://www.mediawiki.org/wiki/Requests_for_comment/Clickable_section_anchors#What_to_share.2Fcopy section of this RFC? Is there a way of turning that into https://www.mediawiki.org/wiki/Requests_for_comment/Clickable_section_anchors#sharing without changing the title of that section to "=== sharing ==="?

https://en.wikipedia.org/wiki/Template:Anchor example no. 2
(but that is hardly ideal syntax, and it buggers up automatic section edit summaries, iirc)

A related problem that might be a precursor to solving this one correctly: do we have a way of creating a reliable link to a section? For example, what is the stable link to the https://www.mediawiki.org/wiki/Requests_for_comment/Clickable_section_anchors#What_to_share.2Fcopy section of this RFC? Is there a way of turning that into https://www.mediawiki.org/wiki/Requests_for_comment/Clickable_section_anchors#sharing without changing the title of that section to "=== sharing ==="?

Yes, {{anchor|sharing}}

do we have a way of creating a reliable link to a section?

https://en.wikipedia.org/wiki/Template:Anchor example no. 2
(but that is hardly ideal syntax, and it buggers up automatic section edit summaries, iirc)

Thanks @jayvdb! I captured this as a possible candidate for a different RFC:
https://www.mediawiki.org/wiki/User:RobLa-WMF/RFC_incubator

A bugger-free solution would be rather nice.

Restricted Application added a subscriber: Luke081515. · View Herald TranscriptJun 12 2016, 12:34 PM
Krinkle removed Krinkle as the assignee of this task.Mar 8 2017, 12:20 AM

I was looking for this today and was wondering what happened to it. I would really love to see it come back. :)

Niharika added a subscriber: Niharika.
Kaartic added a subscriber: Kaartic.
eflyjason rescinded a token.
eflyjason awarded a token.
eflyjason rescinded a token.
eflyjason awarded a token.
eflyjason added a subscriber: eflyjason.
Liuxinyu970226 awarded a token.

Change 430828 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] Skin: Remove the cache-compat remainings of mediawiki.sectionAnchor

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

Change 430828 merged by jenkins-bot:
[mediawiki/core@master] Skin: Remove the cache-compat remainings of mediawiki.sectionAnchor

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

I was looking for this today and was wondering what happened to it. I would really love to see it come back. :)

This is blocked on a team committing resources to implementing and owning it going forward. Once that is on-track, they can review the prior work and either directly propose one or more solutions for review or reach out to help find solutions (e.g. via wikitech-l, or via an IRC meeting).

fbstj added a subscriber: fbstj.Jun 16 2018, 3:50 PM