Template talk:Anchor

This is the talk page for discussing improvements to the Anchor template.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Archives (index): 1, 2, 3: 2 years

Rationale for substitution in the header

The information in the section Template:Anchor/doc#Rationale for substitution in the header appears to be outdated. An anchor below a section will no longer hide the section heading (at least on Chrome). Navigating to an anchor will also show a few lines above it. MClay1 (talk) 11:05, 30 August 2023 (UTC)[reply]

Chrome, perhaps. Firefox, no. --Redrose64 🌹 (talk) 21:15, 30 August 2023 (UTC)[reply]

Is there a phabricator ticket for this issue? I've tried searching but didn't find anything specific [1]. fgnievinski (talk) 02:00, 10 September 2023 (UTC)[reply]

Why would there be? If in Chrome navigating to an anchor will also show a few lines above it, that is a quirk of Chrome, and nothing to do with us. --Redrose64 🌹 (talk) 18:16, 10 September 2023 (UTC)[reply]

template substitution is an ugly solution. defining a new anchor when there are existing ones quickly becomes a hack. there ought to be a more elegant solution. fgnievinski (talk) 05:09, 11 September 2023 (UTC)[reply]

scroll-margin exists in CSS and is now supported nearly universally. We can just put {{anchor}} after the heading if the sitewide stylesheets were updated. My previous call to implement this was archived without resolution. — Christoph Päper 11:22, 17 February 2025 (UTC)[reply]

Stop generating linter errors: make the tag self-close

This edit request to Module:Anchor has been answered. Set the |answered= parameter to no to reactivate your request.

Change line 21:

Apparently not making this a self-closing tag causes a linter error. Aaron Liu (talk) 02:05, 16 May 2024 (UTC)[reply]

I might be confused but I think the diff above by Bruce1ee shows that the proposed edit would be wrong. My recollection is that a self-closed span is an error. At any rate, the proposal needs discussion. Johnuniq (talk) 08:32, 16 May 2024 (UTC)[reply]

Agree with you, editor Johnuniq. Editor Aaron Liu, what also might be confusing is the fact that neither the template page nor the module page throws a linter error if we can believe their "Page information" pages. Isn't that how we detect linter errors by the page? Linter errors appear at the bottom of those info pages. Begs the question, precisely where was this module's "apparent" linter error detected? P.I. Ellsworth , ed. ^{put'er there} 10:11, 16 May 2024 (UTC)[reply]

For reference see the HTML standard at §13.1.2 Elements and particularly §13.1.2.1.6. ... is neither a void nor a foreign element so may not be 'self closed'.

—Trappist the monk (talk) 10:34, 16 May 2024 (UTC)[reply]

Sorry for the confusion, it was late at night and I read it wrong. Cheers. Aaron Liu (talk) 11:25, 16 May 2024 (UTC)[reply]

A self-closing tag is what this template used to do, until December 2009. This is where it changed; the relevant discussion is at Template talk:Anchor/Archive 1#Usage is confusing (wrong?). --Redrose64 🌹 (talk) 20:54, 16 May 2024 (UTC)[reply]

Side note: the Manual of Style at MOS:SECTIONANCHOR recommends against self-closing tags: Note: if electing to insert the span directly, do not abbreviate it by using a self-closing tag, as in ==Implications==, since in HTML5 that XML-style syntax is valid only for certain tags, such as  . with a reference to phab:T134423 "Deprecate nonstandard behavior of self-closed HTML tags in wikitext.". —⁠andrybak (talk) 22:48, 2 June 2025 (UTC)[reply]

Recommend against placing the anchor above a section heading

The doc says Another anchor named #Above-Foo has been placed above the section header. This anchor does work correctly, but because the anchor is technically not in the section but before it, it makes editing counter-intuitive. Such an anchor does not always work correctly on mobile, because if the anchor is above a level 2 (or 1) heading, the previous section will be expanded instead of the one the anchor is supposed to point to. We should deprecate such usage, at least above level 2/1 headings. Try opening [2] on mobile for an example. Nickps (talk) 19:22, 17 May 2024 (UTC)[reply]

Prevent emitting a newline?

Tracked in Phabricator
Task T369520

It seems this template should have <nowiki /> at the very beginning as to prevent emitting a visible newline, which drives people crazy. Is there a technical reason this is not done? Remsense诉 13:33, 8 July 2024 (UTC)[reply]

Why do you do this? You did it at {{CS1 config}} and {{bots}} without a good explanation and then promptly closed the discussion at Help talk:Citation Style 1 § Whitespace in `CS1 config` and `bots` (else I would have replied there). What is it that necessitates this change? If this is a bandaid to cover over a bug, shouldn't you be reporting it at WP:PHAB?

—Trappist the monk (talk) 13:49, 8 July 2024 (UTC)[reply]

Apologies. I just assumed that since these templates are meant to be invisible and aren't meant to be substituted, there would be no reason for them to emit a newline. I'll self-rv. Remsense诉 13:57, 8 July 2024 (UTC)[reply]

There is no need to emit a new line. If they do, then perhaps there is a bug at MediaWiki. If there is a bug, you should report it at WP:PHAB.

—Trappist the monk (talk) 14:20, 8 July 2024 (UTC)[reply]

Templates like {{EngvarB}} prevent emitting a newline by including a <nowiki /> tag at the very beginning. Presently, {{Bots}} and {{CS1 config}} do not do this, so I have to stack them on the same line when I use them together in an article to prevent excess whitespace. I thought this was all understood or intended behavior. Remsense诉 14:23, 8 July 2024 (UTC)[reply]

Confirmed at A. This seems like a bug in how MediaWiki handles these sorts of templates. Report it at WP:PHAB.

—Trappist the monk (talk) 14:28, 8 July 2024 (UTC)[reply]

Thank you; sorry for the confusion. Remsense诉 14:29, 8 July 2024 (UTC)[reply]

@Trappist the monk, this is apparently pretty ancient behavior, so while I opened a fresh ticket I wouldn't expect it to do much. Remsense诉 19:52, 8 July 2024 (UTC)[reply]

It's always a good idea to provide the ticket number. I'm assuming this is phab:T369520; if not, please state which. --Redrose64 🌹 (talk) 20:24, 8 July 2024 (UTC)[reply]

That is correct. Remsense诉 20:59, 8 July 2024 (UTC)[reply]

substitution

In the 'Rationale for substitution in the header' section it says that the template should always be substituted. The ration given is that it interferes with wiki software that deals with the section titles and makes the history more awkward. This was true years ago but is no longer true. Substitution replaces a very simple form with a complicated form that is much, much harder to maintain. I see no advantages to substitution and plenty of disadvantages. I propose that we remove the instruction for substitution. Stepho talk 22:06, 30 July 2024 (UTC)[reply]

The ration given is that it interferes with wiki software that deals with the section titles and makes the history more awkward. This was true years ago but is no longer true.

It's still the case, unfortunately. If you edit a section with an embedded, unsubstituted anchor, your edit summary will still indicate an edit was to the /* {{anchor|sand}}Box */ section. This might seem like not a big deal in isolation, but it becomes totally unworkable with multiple sections or multiple anchors in an article.Remsense 诉 22:11, 30 July 2024 (UTC)[reply]

I do wish we could do anchors differently though: it's a pity that the present HTML standard doesn't have some self-closing tag that's semantically suited for this purpose: ... is what we basically have for a "null" tag. Remsense诉 22:19, 30 July 2024 (UTC)[reply]

The abandoned HTML 3.0 spec had the <SPOT> tag for precisely this purpose. Its definition in the DTD was:

<!-- SPOT is used to insert IDs at arbitrary places
     e.g. for end points of a marked range (see RANGE) -->
<!ELEMENT SPOT - O EMPTY>
<!ATTLIST SPOT id ID #REQUIRED>

so it was implicitly self-closing (like <IMG>) and took exactly one attribute, being ID=. Unlike most other HTML 3.0 proposals, it never made it into either HTML 3.2 (which was a stripped-down 3.0, upwardly-compatible with HTML 2.0) or HTML 4.0 (which was 3.2 plus some of the 3.0 proposals that had been dropped for 3.2). --Redrose64 🌹 (talk) 18:36, 31 July 2024 (UTC)[reply]

It makes plenty of sense that it wouldn't be a real coveted proposal in just about any context except this one, where we're not ever placing <h2>...</h2> tags directly. Remsense诉 18:44, 31 July 2024 (UTC)[reply]

Underscores with substitution

Rationale for Special:Diff/1244491219/1248164137:

When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree and must contain at least one character. The value must not contain any ASCII whitespace.^[1]

Basic usage without substitution works fine with ASCII whitespace, I think MediaWiki (?) replaces whitespace characters in the input with underscores in the output, which will be valid HTML. But when the template is substituted, any ASCII whitespace characters are kept in the anchor id, which would output invalid HTML. Thus this documentation change and inconvenience.

Module:Anchor doesn't replace whitespace characters in the anchor id with underscores. I'm not sure if this behavior is changeable.

References

^ "HTML Standard". WHATWG. 26 September 2024. Archived from the original on 28 September 2024. Retrieved 28 September 2024.

84.250.15.152 (talk) 01:24, 28 September 2024 (UTC); edited 01:33, 28 September 2024 (UTC)[reply]

If the MediaWiki software encounters a construct like , what it actually serves is , the conversion is automatic. So there is no need to advise people to do something that is completely unnecessary. --Redrose64 🌹 (talk) 11:07, 28 September 2024 (UTC)[reply]

It would normally be, but I tested it here not to be the case with this one when substituted. When this template is inserted without substitution, it works as you're describing it. I hate it as much as you do. 84.250.15.152 (talk) 11:08, 28 September 2024 (UTC)[reply]

The bug or source of confusion appears to originate from Special:Diff: Special:Diff/1248232226 displays the diff with whitespace, but the output seems to be (?) with underscores. I've reverted my changes. 84.250.15.152 (talk) 11:18, 28 September 2024 (UTC)[reply]

Diffs show the difference between two versions of the Wikicode source, not the HTML that is served to clients. --Redrose64 🌹 (talk) 13:15, 28 September 2024 (UTC)[reply]

Text to image and Image to text anchors

Hi,

I was wondering if it is possible to link a text to an Image and an Image to that text. (not a footnote, but a text which deals with a topic)

In my view the difficulty comes from the image syntax [[File:...]] or [[Image:...]] which moves the image to a place where there is no other image and which does not provide a way to put an anchor at the top/bottom of that image.

What would be a good or wrong approach on such topic?^[a].

Regards.^voir. — Preceding unsigned comment added by 78.120.88.229 (talk) 20:35, 28 January 2025 (UTC)[reply]

Notes

^ L'idée d'un lien vers une ancre serait seulement monodirectionnelle. Deux ancres et deux liens permettraient la bidirectionnalité, au prix de nécessiter un modèle. Un tel modèle s'utiliserait comme suit: {{Illustré|nom=Smile|[[Fichier:SNice.svg|99px|:-) ]]}} puis {{TexteIllustré|nom=Smile|Le smiley est gai, rond et jaune}} et apparaîtrait: "Le smiley est gai, rond et jaune^voir", mais cela dépasse le sujet de la page et les conventions établies... et Techniquement, cela nécessite que l'ancre suive le haut de l'image....

neither id nor anchor worked properly in one case

List of generic forms in place names in the British Isles § ington

Please help/advice. --Altenmann >talk 07:09, 5 May 2025 (UTC)[reply]

As far as I can tell, the link you've provided works, but after the browser scrolls down to "ington", the logic for {{sticky table start}} kicks in and the browser scrolls away. In particular, it scrolls to the top of the table, ~~that is now squashed vertically~~ that is squashed vertically from the start. If I go into browser's address bar a second time and press ↵ Enter, my browser does scroll to "ington" properly the second time. I had to deal with a similar issue in a userscript, which actively changes the layout of the wikipage, by forcibly scrolling to #hash, if it's present:

		if (document.location.hash === "") {
			return;
		}
		const targetId = document.location.hash.slice(1).replaceAll(' ', '_');
		document.getElementById(targetId)?.scrollIntoView();

But I'm not sure if this is the right approach for this problem.

This doesn't seem to be an issue caused by Template:Anchor, but rather an interaction between different browser behaviors caused by the sticky table. I recommend moving this discussion to Template talk:Sticky table start and also to invite editors at Wikipedia:Village pump (technical).

Side note: looking at the template's CSS code, the template works by hijacking parts of the logic for collapsible elements. This is needed to have a special toggle [disable]/[enable], which is visible only on narrow screens (i.e. mobile phones). This can be seen in lines 61–65 of the CSS. —⁠andrybak (talk) 13:06, 5 May 2025 (UTC)[reply]

I moved the anchor up one row, and it works perfectly for me now. – Jonesey95 (talk) 21:39, 7 May 2025 (UTC)[reply]

Unfortunately, it's still broken for me in Firefox and Chromium. It still scrolls to the top after showing the "ington" row for a split second. Also, I struck a misleading part of my first message above. I can't see any "squashing" as it is happening, the table is already vertically squashed with a scrollbar on the first loading of the page. —⁠andrybak (talk) 22:33, 7 May 2025 (UTC)[reply]

Putting the id (whether as an anchor, a span element, or an id= attribute on the cell) on a cell of the previous row is sub-optimal. For accessibility reasons it needs to be on the relevant row. It's also a good idea to put the id=attribute onto the row marker, and not in a cell, as I did here, this ensures that screen readers will reach the row itself and announce it properly. --Redrose64 🌹 (talk) 22:50, 7 May 2025 (UTC)[reply]

Are we sure WP:ANCHORSUBST is a good idea?

Stuff like === 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I think he is saying that given a choice between:

=== Administrators and bureaucrats ===
=== {{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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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

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)[reply]

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)[reply]

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

@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)[reply]

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

Inconsistent advice

Some of the language in the "Explanations and examples" is not consistent with the preceding "Always substitute in section headers". Here are my suggestions for improvement (but I'm not game to make changes myself in this area):

From: A drawback of this approach (as detailed in § Limitations section) is that having
To: This approach is unsuitable (as detailed in the § Limitations section) because having

From: The obvious solution is to
To: The obvious (but still unsuitable) solution is to

From: Within section titles, it may be preferable to simply use direct HTML,
To: An anchor within a section title should be placed at the start using direct HTML, (and change the example code accordingly)

And the code in Example 4 also needs the ((subst)) moved to the start. 180.150.36.190 (talk) 15:56, 3 September 2025 (UTC)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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

WP:MULTI

Before it becomes about the same topic as the other discussion (building, rather than finding, consensus), I'm gonna close this per WP:MULTI, see the current discussion at Wikipedia talk: Manual of Style/Linking § Consensus for the current recommendation to always subst the anchor template within a section header. FaviFake (talk) 16:17, 21 October 2025 (UTC)[reply]

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  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)[reply]

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)[reply]

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

See ~~Template talk:Anchor~~Wikipedia 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

[1] "HTML Standard". WHATWG. 26 September 2024. Archived from the original on 28 September 2024. Retrieved 28 September 2024.

[2] L'idée d'un lien vers une ancre serait seulement monodirectionnelle. Deux ancres et deux liens permettraient la bidirectionnalité, au prix de nécessiter un modèle. Un tel modèle s'utiliserait comme suit: {{Illustré|nom=Smile|[[Fichier:SNice.svg|99px|:-) ]]}} puis {{TexteIllustré|nom=Smile|Le smiley est gai, rond et jaune}} et apparaîtrait: "Le smiley est gai, rond et jaune^voir", mais cela dépasse le sujet de la page et les conventions établies... et Techniquement, cela nécessite que l'ancre suive le haut de l'image....

[1]

[a]