Template talk:Anchor

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

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

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

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

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

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.

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

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

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

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

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