Template talk:Anchor

Proposed changes to don't do this subsections

@Butwhatdoiknow I'm really sorry but I can't manage to understand your edits and especially your goals, despite the edits summaries. Here's what I think:

• I agree all the four heading should indeed say "Not", so "Not above the heading" etc (Update 19:31, 7 October 2025 (UTC):  Done for all 4)
• I don’t understand why the link to test the anchor was removed. Its goal is clearly explained directly above: Below are incorrect usages of the template, accompanied by an explanation. Since they are actually placed in the § Basic format section heading on this documentation page, the links can be tested to see their effect. (emphasis supplied)
  • I don’t understand why you changed the wikicode of the 1st bad example to :{{anchor|Old heading text}} == New heading text ==. Now it no longer reflects the actual code of the /doc page.
  • I don’t understand this sentece in your edit summary: If the clickable link is changed then "Placed above" makes no sense in the "bad" example.
• I agree the bad example should be at the top and not below the explanation of why its bad, but in that case I don’t think there should be text above the bad example as to not interrupt the sentence flow. [Update 09:54, 12 October 2025 (UTC)  Done]
  • I don’t understand why the sentence Editors should not place an anchor above a heading because: was changed.

Following BRD i think this needs more space than an edit summary. FaviFake (talk) 16:39, 7 October 2025 (UTC)

Second bullet point: Removal of test links.

The purpose of the test links seems to be to show what it looks like when you land on an improper anchor. In most cases, however, clicking on the link doesn't take the reader to anything that appears particularly harmful. In short, the links don't add anything meaningful to the text. So maybe just remove them? Wikipedia:Avoid instruction creep

If we are nevertheless going to keep the links, the current explanation is (a) buried at the end of the section lede, (b) far from the "See" links, and (c) not all that clear (to me). I propose adding text where they appear - something along the lines of "To see the effect of an improper above the heading placement, click to the anchor § Placed above in this article" (without a colon at the end).

- ButwhatdoIknow, 20:33, 7 October 2025 (UTC) @FaviFake, I look forward to your thoughts regarding this post. - Butwhatdoiknow (talk) 05:33, 12 October 2025 (UTC)

@Butwhatdoiknow Thanks. I don’t think they should be removed; there are no other places where they can be quickly tested. A mediawiki change could change the effect, like it did in the past IIRC. They aren't "add[ing] anything meaningful to the text", you're right, they're just there so people can test the anchors.

But I agree they're not clearly labelled. However, as you say, they're currently very similar in functionality, so i think your proposed wording would be misleading. For example, anchors placed above work well on desktop, but not on mobile. We shouldn't tell the user they're going to see the difference every time they click these tests.

Maybe something like "You can test it at § Placed below"? FaviFake (talk) 09:45, 12 October 2025 (UTC)

@FaviFake I guess what I'm having trouble understanding is why it is a good idea to provide a test of what not to do - particularly when the test doesn't result in a visual demonstration of the problem. For example, clicking to Template:Anchor#Placed_above looks just fine. - Butwhatdoiknow (talk) 16:18, 12 October 2025 (UTC)

Yes, but it might not work fine on mobile, or when he foundation changes mediawiki, or in other conditions. For example, i receive different results when goit to § Basic format compared to § Placed above FaviFake (talk) 16:21, 12 October 2025 (UTC)

Okay, let's leave off the "particularly when" part of my post. With wp:CREEP in mind, why it is a good idea to provide a test of what not to do? Butwhatdoiknow (talk) 16:42, 12 October 2025 (UTC)

They're not instructions, they're tests. There are no other places where they can be quickly tested, and this is a great page for that. FaviFake (talk) 16:48, 12 October 2025 (UTC)

That is a distinction without a difference. The point of CREEP is to avoid TMI of any sort. - Butwhatdoiknow (talk) 01:12, 13 October 2025 (UTC)

Doesn't seem to be for me, after reading the page. Only talks about instructions. FaviFake (talk) 15:32, 13 October 2025 (UTC)

So that people who want to use the wrong version can see for themselves the issue it causes. (Also like the edit summary being broken, mobile not expanding, etc) FaviFake (talk) 16:50, 12 October 2025 (UTC)

Regarding the first sentence, often folks will click on the "Above" link and NOT see any issue being caused. The "test" does not demonstrate a broken edit summary. In this case, seeing is not believing. - Butwhatdoiknow (talk) 01:20, 13 October 2025 (UTC)

The "test" does not demonstrate a broken edit summary.
It does if someone tries to edit that section. For testing purposes.

Regarding the first sentence, often folks will click on the "Above" link and NOT see any issue being caused.
For that specific one, they will see the difference with the default #Anchor linking. And they'll see the other differences i've mentioned above.

I can't understand the upsides of removing 3 words from each paragraph. That's not what's making them "bloated" with instructions. Are there any other reasons for removing this other than freeing up space? I agree /docs shoundn't be bloated but this seems like a terrible way to both (1) remove useful tests and (2) not save that much space. FaviFake (talk) 15:31, 13 October 2025 (UTC)

Consensus for the current recommendations to always subst the template within anchors

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I find that the current recommendations, that leave ugly <span class="anchor" id="Foo"></span> HTML code exposed to editors, and puts the wrong priority on the unfitness of the "transclude" alternative, are effectively misguided, but the only place to start would be to find the place where the current guidelines were hashed out, so I can start by reading up on previous arguments.

So please direct me to that discussion, please. Thank you and have a nice day, CapnZapp (talk) 18:16, 18 October 2025 (UTC)

I don’t have a lot of time to look into this, but from a quick search it seems the same advice is spread across multiple guideline pages. Here are a few I found:

• MOS:RENAMESECTION
• MOS:HEAD, specifically:
  • MOS:SECTIONANCHOR and
  • MOS:HEADINGLINKS, especially the last point in which {{Anchor}} is mentioned as an example.
• WP:TARGET
• and WP:ANCHORSUBST which, while not being a guideline, explains the reasons for this practice.

FaviFake (talk) 20:22, 18 October 2025 (UTC)

Thank you. I'll ask further at WP:MOS and WP:MOSLINKS. CapnZapp (talk) 21:13, 18 October 2025 (UTC)

See Template talk:AnchorWikipedia talk:Manual of Style/Linking#Consensus for the current recommendation to always subst the anchor template within a section header It's starting to look like there was no consensus for this. This guidance was inserted in several places in the MOS and guidelines by FaviFake on August 20. --Srleffler (talk) 02:52, 20 October 2025 (UTC)

The discussion Srleffler is referring to is here: Wikipedia talk:Manual of Style/Linking#Consensus for the current recommendation to always subst the anchor template within a section header. CapnZapp (talk) 11:13, 20 October 2025 (UTC)

Please drop a link here if you decide to RFC this. I would like to participate. –Novem Linguae (talk) 07:35, 21 October 2025 (UTC)

If anyone wants or needs to start a RFC, that's of course fine. Personally though, if we reach a consensus over at the linked discussion to change our advice/prescription, even over the objections of a very small number of editors, that's sufficient for me. If there exists other talk pages whose watchers could be interested in this discussion, do let me know about them (or post discussion notices at those places yourself). CapnZapp (talk) 07:46, 21 October 2025 (UTC)

You might need a survey/RFC with options, or it may become too chaotic to find a consensus. I'd recommend that the RFC include an option for the status quo of substing at beginning of the heading, an option for not substing at the beginning of a heading (not a big deal if the history tab oldid link doesn't jump to a section), and an option for not enforcing any position and letting each individual page keep its status quo ante (I'm leaning towards this at the moment but could change my mind with more discussion), plus whatever other options you'd like to add. –Novem Linguae (talk) 07:51, 21 October 2025 (UTC)

Thanks, but since I don't feel the need for a RFC, I won't be the one starting one. I recommend you start watching Wikipedia:Manual of Style/Linking if you don't already, so when or if someone does start discussing the need for a RFC you can give your recommendations to them. Best of luck! CapnZapp (talk) 08:06, 21 October 2025 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Anchor link content beginning overlapped

There is a problem with anchor links to paragraphs/sentences, the target content (at least beginning of it) not being visible because scrolled / overlapped; happening in Vector 2022 skin (default) for logged-in users. Reported as T407884. —Mykhal (talk) 06:59, 22 October 2025 (UTC)

Introduce encoding

I was surprised to find out this template doesn't do any automatic conversion of the input parameters to make them comply with the requirements for anchors, as is the case in many other wikis. Instead, Template:Anchor/doc just explicitly lays out the rules for manual transformation 🙄 (which you cannot do when you pass a parameter of another template to {{anchor}}).

E.g. if we write {{anchor|test>}}, we get

 <span class="anchor" id="text>"></span> 

which looks like this: ">

Judging by these search results, people just use {{anchorencode:}} directly rather than employing the template.

But won't we break anything by introducing encoding? Jack who built the house (talk) 06:53, 14 December 2025 (UTC)

sound like a great change if the output remains the same if the anchor is valid FaviFake (talk) 18:19, 17 December 2025 (UTC)

Discussion at meta:Community Wishlist/W260

 You are invited to join the discussion at meta:Community Wishlist/W260. Wish: Native Support for Alternative Section Anchors –Novem Linguae (talk) 13:42, 14 December 2025 (UTC)

Documentation suggestions

The documentation is lacking mention of how to subst multiple anchor names. Please add. It seems to work well enough as {{subst:Anchor|anchorname1|anchorname2|anchorname3}} but I would feel more confident if I'd been able to read that in the documentation.

Also, wouldn't it be better to subst the anchor after the section title name? In terms of visually scanning down the code, it would be easier to find the section header you're looking for without the mess of the expanded code coming first.   ▶ I am Grorp ◀ 15:06, 24 March 2026 (UTC)

The documentation is lacking mention of how to subst multiple anchor names. Please add
Feel free to add it yourself!

wouldn't it be better to subst the anchor after the section title name
it's definitely visually nicer when viewing the source editor, but the reasons we place it after the title are described in § Not after the section title. FaviFake (talk) 19:50, 24 March 2026 (UTC)

anchor linking triple lock

Using the anchor template twice on a page allows for 3 links to it (or ways to link to). (template)anchor|Aboveanchor and anchor on main title text in lowercase.

{{anchor|Anchor}} == {{anchor|anchor}} Anchor == {{seealso|template:Anchor}}

The title can be used to #Anchor link (capital letters and with spaces). Catcus DeMeowwy (talk) 19:12, 13 April 2026 (UTC)

What? FaviFake (talk) 20:07, 13 April 2026 (UTC)

I made a mistake in this topic/post, forgetting that the title being used as an anchor (with caps) can be used as an anchor and that only 1 anchor is needed. However this is not the case if the anchor text is different to title. And not that the capital letter anchor should be used.

Doing this:

{{anchor|abovetext}} <nl> == {{anchor|abovetextTitle}} AbovetextTitle ==

This "triple locks" the anchor and lets it be used with any capitalization. I think this should be the format on every page - and the anchor going ABOVE the paragraph to make the link jump to someone higher in the text. Every page as in standard format for anchor. Catcus DeMeowwy (talk) 14:35, 14 April 2026 (UTC)

I'm sorry, I still have no idea what you're proposing. FaviFake (talk) 14:48, 14 April 2026 (UTC)

They want the same anchor to be specified in three different ways at the same time. Apart from causing a problem with HTML validity (all IDs must be unique within a document), we have had this discussed several times before. People aren't wanting to go through it all again. --Redrose64 🌹 (talk) 18:07, 14 April 2026 (UTC)

Thanks. Do you have a link to the previous discussions? FaviFake (talk) 18:22, 14 April 2026 (UTC)

Do you really not recall the discussions that led to edits like this? --Redrose64 🌹 (talk) 21:07, 14 April 2026 (UTC)

Oh, I thought you were saying that we discussed the specific proposal of using multiple similar anchors for 1 heading. Nevermind, of course I remember those more general discussions, and I agree there's no need to rehash them FaviFake (talk) 04:22, 15 April 2026 (UTC)

I didn't know this had been previously discussed. Catcus DeMeowwy (talk) 10:22, 15 April 2026 (UTC)

Several times, admittedly not all of them on this page. The result of these discussions is in the template documentation, which shows why the additional positions that you suggest are unsuitable; start at Template:Anchor#Not above the heading and work down, stop at the "Limitations" heading. --Redrose64 🌹 (talk) 16:58, 15 April 2026 (UTC)

Maybe check the wikicode markup if you don't understand. I can't get it to nowiki and print out the code that would be used. Sorry. Catcus DeMeowwy (talk) 14:37, 14 April 2026 (UTC)

Anchored redirect target

I would like to have a template that produced Redirect target such that Page#Redirect target would land on the bold text. Is there such at thing already? Something like

{{subst:anchor|Redirect target}}'''Redirect target''' Johnjbarton (talk) 17:19, 10 July 2026 (UTC)

@Johnjbarton You're looking for {{Va}}:

'''{{va|Redirect target}}'''

FaviFake (talk) 10:18, 11 July 2026 (UTC)

Ok thanks! Just to be explicit (since I missed this detail the first time I read the code), the three ticks give the MOS:BOLDREDIRECT look, eg Redirect target. A link like Template talk:Anchor#Redirect target will land on the bold text and highlight it. Johnjbarton (talk) 15:52, 11 July 2026 (UTC)

Yup! You can test in this very talk page, it works!

Another example is WP:DUP, which highlights an entire bullet point. FaviFake (talk) 19:46, 11 July 2026 (UTC)

Bug with userscript (that could be related to Anchor)

A few minutes ago I made a GitHub issue about a userscript known as anfrc-lister, developed by @Novem Linguae. The part of the script that parses section headers was bugged, and Novem believes WP:ANCHORSUBST is at least partly to blame. I'm bringing this up here to discuss this issue, as well as hopefully finding a way to fix it. JHD0919 (talk) 13:35, 12 July 2026 (UTC)

In general, it's not our responsibility to adjust Wikipedia to accommodate user scripts. Script authors need to fix their own bugs. I agree with Novem Linguae's comment, though, that WP:ANCHORSUBST causes "ugly verbose wikicode". I wish we could get rid of it.--Srleffler (talk) 16:37, 12 July 2026 (UTC)

I took another look at this, and my initial diagnosis was incorrect. It was indeed a bug in this user script. I've fixed it at b3eba9b. Thanks for reporting! –Novem Linguae (talk) 00:24, 13 July 2026 (UTC)

Whitespace

The limitations section currently states that "whitespace is not a problem". Whitespace in an anchor violates the HTML specification, including in HTML5. Readers should be made aware of this and advised to substitute with other characters such as underscores or dashes. Ideally perhaps the template would substitute with underscores automatically or throw a warning. DiscreetParrot (talk) 20:52, 16 August 2026 (UTC)

I agree, please feel free to update the documentation @DiscreetParrot! FaviFake (talk) 21:12, 16 August 2026 (UTC)

Not possible, only admins and template editors can currently edit it. Unless I can get template editor perm granted... DiscreetParrot (talk) 22:03, 16 August 2026 (UTC)

@DiscreetParrot Nope, I am correct. You probably clicked the wrong button. You need to click the "edit" button located next too the "Documentation" heading, not the one at the top of the page. Anyone can edit the doc. FaviFake (talk) 07:05, 17 August 2026 (UTC)

The documentation is correct. Whitespace in a Wikipedia anchor name is converted to underscores in the resulting HTML. This is the same way Wikipedia handles spaces in article titles.--Srleffler (talk) 22:07, 16 August 2026 (UTC)

Yes, having subsequently just tested it, along with some other templates, correct links are in fact produced (spaces substituted with underscores). The documentation is simply unclear. Readers should be reassured that use of whitespace will result in correct links (underscore substitution performed), and is in fact preferred because it results in nicer link presentation.

It would be ideal, I feel, if this template, along with others like Template:See also, Template:Broader, Template:Further and Template:Main, behaved like Template:Section link, which not only automatically substitutes whitespace with underscores to create valid links, but also automatically does the opposite for the presented text (unless a keep-underscores=yes attribute is added). DiscreetParrot (talk) 23:27, 16 August 2026 (UTC)

The documentation is not unclear. It is correct and unambiguous. It identifies characters that can't be used and says correctly "Most other characters, such as whitespace and punctuation, are not a problem." The purpose of Wiki markup is to provide a simpler way to build hypertext. Spaces are valid in page names, section names, and anchor names.

Editors should not be encouraged to use underscores in wikitext. It is bad form, and many editors (and some bots) will remove them on sight. The behavior of Template:Section link encourages bad wikicode.--Srleffler (talk) 04:53, 17 August 2026 (UTC)

I came to this template article concerned about the possibility that such templates might just be taking anchors containing whitespace and constructing the underlying links with them verbatim, disrespecting the no-whitespace rule. I read that bit of text. I jumped to the wrong conclusion. A little later I actually did some testing, which I then regretted not doing earlier, finding that the template does in fact do the right thing when presented with whitespace. If the text is entirely unambiguous as you say, then how come I misunderstood it. Simply stating 'whitespace is not a problem' felt clumsy and gave a bad impression. I'm not sure what to suggest to tweak it to. Outright expressing that whitespace can be freely used because it will be transformed correctly in the underlying link might be too much.

"The purpose of Wiki markup is to provide a simpler way to build hypertext." Obviously.

"Spaces are valid in page names, section names, and anchor names" In presented text, yes, obviously. Not so much in underlying URLs.

"Editors should not be encouraged to use underscores in wikitext. It is bad form, and many editors (and some bots) will remove them on sight. The behavior of Template:Section link encourages bad wikicode." I'm aware that it's bad form, and I edit them away myself, but it's easy to make mistakes, copy and pasting from a URL and forgetting to remove them. Also, personally I've stupidly found myself leaving them in anchors recently, mistakenly thinking that I needed to. I'm not sure if I've ever seen an explanation for why its bad form though. DiscreetParrot (talk) 09:28, 17 August 2026 (UTC)

Give some consideration to Wikipedia app viewers

(Background: I made a change to the positioning of a table here, and it was reverted here.)

@The Grid: I think it is unfair that you revert my edit with the reason "try viewing it through mobile". (Also, I don't think the distinction is "mobile vs desktop" but rather "Wikipedia app vs browser".) Other sections in this Talk say that there are more readers on mobile than desktop. Of the mobile readers I would guess that the majority view with the app, and some of those will be tablets with a screen width where the table takes up most of the space and leaves a narrow band of text down its left hand side - in my case a column of single letters.

You are implying that the sub-set readers in something like my situation should either change the way they view Wikipedia or put up with a bad reading presentation, so that the rest of the readers don't have to put up with - what? - a table that looks lopsided in empty space at the top of a section? (in this particular case).

(As far as looks go, I have discovered by experiment that putting "wikitable center" produces a table that in my browser takes up the full width of the screen (not centres it at its previous width !?), but I did not want to put that in my edit until I found it in the documentation.)

The WMF think it worthwhile to have an app. They don't say "If you want to read Wikipedia, use a browser". I think that puts an obligation on editors generally to consider the interests of both browser viewers and app viewers. In this particular case the alternatives are a bad presentation for at least some app viewers versus an unaesthetic presentation for the others. I request you reconsider your reversion. ~2026-52102-18 (talk) 05:14, 29 September 2026 (UTC)

The app is crap. Every time I have to use it something breaks. Most people use the mobile website, almost no one uses the app, so we're optimising for most people. FaviFake (talk) 07:56, 29 September 2026 (UTC)

I see the Wikipedia app as a reader companion. It's great for reading articles on the fly. If you want to do anything advanced on it, the mobile site is your go to. They serve different purposes and it looks like it's mentioned as such. – The Grid (talk) 14:41, 29 September 2026 (UTC)

Oh yeah. The app is great for reading and horrific if you want to do anything else. FaviFake (talk) 14:48, 29 September 2026 (UTC)