Template talk:Anchor

Are we sure WP:ANCHORSUBST is a good idea?

Stuff like === <span class="anchor" id="Administrator"></span><span class="anchor" id="Admin"></span><span class="anchor" id="Sysop"></span><span class="anchor" id="sysop"></span><span class="anchor" id="admin"></span>Administrators and bureaucrats === (diff) looks really bad and hard to read in the wikicode. I have my doubts about whether going around mass changing these is actually an improvement. cc FaviFake. –Novem Linguae (talk) 16:22, 18 August 2025 (UTC)

Thanks for the mention. I agree it's not the best, but do you have any other ideas? The logic behind WP:ANCHORSUBST makes sense. These are all worse imo:

== Basic format ==

{{anchor|Under-Foo}}

== {{anchor|Above-Foo}}Basic format ==

{{anchor|Above-Foo}}

== Basic format ==

If you have other solutions in mind I'd be glad to hear them. FaviFake (talk) 16:31, 18 August 2025 (UTC)

Putting the anchor template above or below the heading is definitely superior in terms of wikicode readability and wikicode maintainability. If I'm reading WP:ANCHORSUBST correctly, the problem with this is related to mobile devices?

Like anything in coding / software engineering, everything has a tradeoff. In this case, the tradeoff is wikicode readability/maintainability vs issues on mobile. We should carefully consider the pros and cons of this tradeoff before deciding that one is always better than the other and doing mass refactoring. –Novem Linguae (talk) 16:41, 18 August 2025 (UTC)

WP:READER says "The majority of visitors are readers, so it is important that pages and articles are optimised for this readership". I would be very willing to compromise wikicode readability if it materially improves the reader experience.

the problem with this is related to mobile devices?

Yes. Remember than most traffic to Wikipedia comes from mobile devices. So, the pros and cons seem to be:

Pros:

• When a mobile reader clicks it, the section is expanded and they aren't left to wonder which section they're supposed to open (since they're all closed by default).
• An editor who clicks "edit" on the section can edit the entire section.

Cons:

• If an editor switches to source editing, the editing view looks awful.

(Also, I'm not sure if you're alluding to this or if you've only seen other people do it, but I wasn't doing mass refactoring. When I'm on a page that is broken in some way, I try to fix it since I'm already there. I never go hunting for anchors to substitute.) FaviFake (talk) 07:20, 19 August 2025 (UTC)

Diff was in projectspace, which invalidates pro-reader arguments in that particular example. Projectspace readers are probably all editors rather than readers, and would likely skew heavily towards desktop. –Novem Linguae (talk) 12:44, 19 August 2025 (UTC)

That page is linked to from every protected article on Wikipedia. Besides, you didn't mention you only wished to change the application of MOS:SECTIONANCHOR on projectspace. Still, I think the compromise is more than justified in projectpace too; if someone needs to learn about wikipedia, we don't want to confuse them even more. FaviFake (talk) 12:45, 20 August 2025 (UTC)

I think he is saying that given a choice between:

1. === <span class="anchor" id="Administrator"></span><span class="anchor" id="Admin"></span><span class="anchor" id="Sysop"></span><span class="anchor" id="sysop"></span><span class="anchor" id="admin"></span>Administrators and bureaucrats ===
2. === {{anchor|Administrator|Admin|Sysop|sysop|admin}}Administrators and bureaucrats ===

The second one is much easier to understand in the wiki markup.  Stepho  talk 

Well, that also directly contradics the MoS (MOS:SECTIONANCHOR) in addition to WP:ANCHORSUBST.--FaviFake (talk) 07:25, 19 August 2025 (UTC)

True. Which is why we have discussions like this to improve the MOS. Impossible to ever improve the MOS if we counter every change with "it's against the MOS".  Stepho  talk  23:06, 20 August 2025 (UTC)

Sure. FaviFake (talk) 14:23, 21 August 2025 (UTC)

I've said it before, and I'll say it again: accessibility. Users of screen readers rely on anchors to be at the point from which reading should commence. Consider a section heading: if the anchor is after the heading, or even within the heading but after the heading text, the screen reader softare will not read out the heading text, but will begin with the text that follows the heading. Therefore, the anchor must be inside the heading and also before the heading text, so that the latter is read out. --Redrose64 🌹 (talk) 21:25, 20 August 2025 (UTC)

This is a great point!! I hadn't thought of that. I'll add it to one of the many places that mention it (so far i have MOS:SECTIONANCHOR, WP:TARGET, WP:ANCHORSUBST, and MOS:RENAMESECTION) FaviFake (talk) 22:30, 20 August 2025 (UTC)

Another disadvantage of substing these in the heading (that I just noticed) is that Visual Editor silently deletes the anchors. Example diff. It seems like Visual Editor handles the Anchor template fine, but isn't so good with spans. –Novem Linguae (talk) 21:37, 22 August 2025 (UTC)

VE is so buggy that it's been in beta for well over ten years. --Redrose64 🌹 (talk) 21:56, 23 August 2025 (UTC)

I mentioned this elsewhere, but I think, there is confusion due to some vague language on this page. Every overall guidance we have, going back decades, is that we should avoid links in headers (in between the equal signs).

If it's unavoidable, then we have the subst option.

But in the case of most anchors, it is avoidable - place the anchor right before the header.

And I'll note that subst-ing really becomes a mess on policy and guideline pages where - due to merging over time and maintaining historical shortcuts, it's not uncommon to see far more than 4 anchors to a section. (4 being the limit of a single anchor template.)

We just need to make it more clear in the explanatory text. - jc37 20:49, 1 September 2025 (UTC)

And it looks like the text has been updated in the last month or so to cement the idea of substing. I didn't revert it, but forcing links between the equal signs shouldn't be done. This should be addressed. - jc37 20:55, 1 September 2025 (UTC)

the text has been updated in the last month or so to cement the idea of substing
That comes from the MoS and has been on the /doc for many years; i'm not sure what you're referring to. The edits in the last month were about where in the heading they should be substed, not whether they shoud be in the heading or whether they should be substed. FaviFake (talk) 22:21, 1 September 2025 (UTC)

See MOS:SECTIONANCHOR. FaviFake (talk) 22:21, 1 September 2025 (UTC)

Again, that's what to do, "if" we need to, not that we need to in every instance.

But that aside, what's the argument for requiring it every time? I'm not seeing the value here. - jc37 21:58, 2 September 2025 (UTC)

I can't explain it better than WP:ANCHORSUBST already does. FaviFake (talk) 22:03, 2 September 2025 (UTC)

Which still does not address the above. - jc37 14:50, 4 September 2025 (UTC)

For talk pages: If you put the anchor before the heading, then when the prior section is moved/archived, the anchor goes with the previous section.

For articles: If someone moves sections and uses "Edit section" to cut out text, the anchor link will not be present as it is technically the last line of the previous section.

We substitute within the heading because otherwise the edit summary section links will be malformed, including an invocation of a template (and templates do not render in edit summaries); this wikitext must be removed from the edit summary manually or else the link will not work. Multiple anchors are annoying, but unless they were directly linked from an edit summary, it ought to be safe to condense to one and update any inbound redirects to that single anchor. —Locke Cole • t • c 18:04, 4 September 2025 (UTC)

Locke Cole - Thank you very much for the clarification. This should be on the doc page, for much better clarity. - jc37 21:31, 25 September 2025 (UTC)

I've added it, and reorganised the doc, a few days ago, check it out Jc37! FaviFake (talk) 14:37, 26 September 2025 (UTC)

@Jc37: we should avoid links in headers - two points: (i) anchors are not links, they're the destinations of links; (ii) the things at the top of sections, within two to six pairs of equals signs, are headings, not headers (see the HTML5.2 spec). --Redrose64 🌹 (talk) 19:22, 2 September 2025 (UTC)

I'll freely cop to being loose about saying "header" and "heading". Thank you for the clarification. - jc37 22:01, 2 September 2025 (UTC)

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)