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

Need guidance for anchors to list items

How should I attach an anchor to a list item? There is an example here: Wikipedia:Manual of Style/Images#sizetable. This violates MOS:INDENTMIX, because it separates the single list into two individual lists. I'm inclined to put the anchor between the '*' and the text, is that best? Should I substitute the template? Can we add something to the template doc? GA-RT-22 (talk) 14:50, 12 June 2023 (UTC)[reply]

Put it in between the asterisk and the text, like this. Alternatively, put it at the tail end of the previous list item.

The only time that {{anchor}} should be substd is when it's used in section headings, because it causes difficulties if not substd there.

If you build a list using HTML tags instead of Wikicode, an alternative method is available as the id= attribute, you can see how it's used in the lead section of Wikipedia:Featured article criteria or at Wikipedia:Good article criteria#The six good article criteria. --Redrose64 🌹 (talk) 22:32, 12 June 2023 (UTC)[reply]

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. <span>...</span> 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<span id="Consequences"/>==, since in HTML5 that XML-style syntax is valid only for certain tags, such as <br />. 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: <span>...</span> 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 <span class="anchor" id="Anchor name 1">, what it actually serves is <span class="anchor" id="Anchor_name_1">, 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]

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