Template talk:Anchor

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)

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

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)

Why would there be? If in Chrome Template:Tq, that is a quirk of Chrome, and nothing to do with us. --Redrose64 🌹 (talk) 18:16, 10 September 2023 (UTC)

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)

scroll-margin exists in CSS and is now supported nearly universally. We can just put Template:Tl 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)

Stop generating linter errors: make the tag self-close

Template:Edit template-protected Change line 21: Template:Textdiff Apparently not making this a self-closing tag causes a linter error. Aaron Liu (talk) 02:05, 16 May 2024 (UTC)

I might be confused but I think the diff above by Template:U 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)

Agree with you, editor Template:U. Editor Template:U, 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)

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

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

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

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

Side note: the Manual of Style at MOS:SECTIONANCHOR recommends against self-closing tags: Template:Tq with a reference to phab:T134423 "Deprecate nonstandard behavior of self-closed HTML tags in wikitext.". —⁠andrybak (talk) 22:48, 2 June 2025 (UTC)

Recommend against placing the anchor above a section heading

The doc says Template:Tq 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 Template:Oldid2 on mobile for an example. Nickps (talk) 19:22, 17 May 2024 (UTC)

Prevent emitting a newline?

Template:Tracked It seems this template should have Template:Tag 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)

Why do you do this? You did it at Template:Tlx and Template:Tlx without a good explanation and then promptly closed the discussion at Template:Slink (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)

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)

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)

Templates like Template:Tl prevent emitting a newline by including a Template:Tag tag at the very beginning. Presently, Template:Tl and Template:Tl 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)

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)

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

@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)

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)

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

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)

Template:Talk quote

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)

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: Template:Tag is what we basically have for a "null" tag. Remsense诉 22:19, 30 July 2024 (UTC)

The abandoned HTML 3.0 spec had the Template:Tag 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 Template:Tag) 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)

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 Template:Tag tags directly. Remsense诉 18:44, 31 July 2024 (UTC)

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.

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.

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

If the MediaWiki software encounters a construct like Template:Tag, what it actually serves is Template:Tag, 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)

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)

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)

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)

Text to image and Image to text anchors

File:SNice.svg

Un smiley :-)^lire

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?Template:Efn.

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

neither id nor anchor worked properly in one case

Template:Section link

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

As far as I can tell, the link you've provided works, Template:Em after the browser scrolls down to "ington", the logic for Template:Tl kicks in and the browser scrolls away. In particular, it scrolls to the top of the table, Template:Deleted text Template:Inserted text. If I go into browser's address bar a second time and press Template:Key press, 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)

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

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)

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 Template:Diff, this ensures that screen readers will reach the row itself and announce it properly. --Redrose64 🌹 (talk) 22:50, 7 May 2025 (UTC)