Template talk:Anchor

Discussion notice: "Instructions on the placement of 'Anchor' templates" at MoS Talk
Since the discussion there has turned to possibly modifying this template, I think editors here should take a look at Wikipedia talk:Manual of Style. —DocWatson42 (talk) 05:06, 20 May 2021 (UTC)
 * Now at Wikipedia talk:Manual of Style/Archive 222 - dcljr (talk) 03:54, 24 February 2023 (UTC)

Before or after section title?
The current instructions in this template appear to contradict the instructions in WP:TARGET. The instructions here say to substitute the template after the section title: In general, substitute an anchor at the end of a section header:

But the instructions in WP:TARGET say to substitute it before the section title: Alternative anchors for section headings are ideally placed directly in front of the name of the heading (but after the equals signs): ==anchor nameSection title==

Which one should it be? Does it actually make a difference? &mdash; Umofomia (talk) 17:11, 11 August 2022 (UTC)
 * See above. -- Red rose64 &#x1f339; (talk) 05:27, 12 August 2022 (UTC)
 * Thanks @Redrose64; I saw that thread, though the discussion there seemed a bit unfocused, with commenters primarily arguing about the use of  or whether the anchor should instead be placed above or below the header itself, rather than where it should be placed within the header (either before or after the title text). I buy the current rationale that the anchor should be substituted within the header, and wanted to focus the discussion specifically on whether we care that the anchor comes before or after the title text (even if we do not care, we should probably not have the documentation in these two places be contradictory).
 * I started this new thread since the previous thread was from a year ago and nothing changed since then so I assumed that the approach of substituting the anchor within the header was de facto settled. The remaining issue in my mind is resolving the conflict in the instructions in these two places. &mdash; Umofomia (talk) 17:30, 12 August 2022 (UTC)

Anchor in Vector 2022
As a V-2022 user, whenever I use the anchor template, the top header that features the title and the like that is used in V-22 obscures the portion of the article where the anchor is supposed to specifically link to. For example, on List of Generation Z slang, linking Asl (slang) with an anchor obscures the segment of the article dedicated to the term "Asl" on the article using V-22. Knightoftheswords281 (talk) 04:23, 3 January 2023 (UTC)

"Template:Anchro" listed at Redirects for discussion
The redirect [//en.wikipedia.org/w/index.php?title=Template:Anchro&redirect=no Template:Anchro] has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at  until a consensus is reached. Q𝟤𝟪 00:18, 22 May 2023 (UTC)

"Template:Ancor" listed at Redirects for discussion
The redirect [//en.wikipedia.org/w/index.php?title=Template:Ancor&redirect=no Template:Ancor] has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at  until a consensus is reached. Q𝟤𝟪 00:19, 22 May 2023 (UTC)

When anchor name duplicates heading name

 * Note. This discussion started on a user talk page.

Hi. See diff.

That section is linked to from here:
 * Template:Flagg/doc

I linked to the Help:Table anchor from the Flagg doc in case the Help:Table section heading changes again. What am I doing wrong? I got info from Template:Anchor. --Timeshifter (talk) 01:16, 25 May 2023 (UTC)
 * If you view the HTML source for any section heading on any Wikipedia page, you will see that the first tag inside the  is a, where the value of the  is the section heading text (encoded, so that e.g. underscores replace spaces). Inward links to that section work just fine. Not only is adding an additional anchor redundant, it also creates invalid HTML since the value of an   [//www.w3.org/TR/2021/SPSD-html52-20210128/dom.html#ref-for-html-element①③ must be unique within the document]. -- Red rose64 &#x1f339; (talk) 19:11, 25 May 2023 (UTC)
 * OK. I see what you are talking about in the page source. There are duplicate IDs.
 * But it is not a problem because even though there are duplicate IDs they are in the same location. So links to the anchor name and the heading name both go to that same location.
 * That is probably why it is not mentioned as a problem in the Template:Anchor doc page: Template:Anchor/doc.
 * I noticed something interesting. The anchor link I left on the other page still works. Even though the anchor had been deleted on Help:Table. That is a good reason to use the current heading name as the anchor name. In case some editor deletes the span stuff in the heading just because they don't understand what it is. --Timeshifter (talk) 23:40, 25 May 2023 (UTC)
 * Duplicate id's do not generate invalid HTML. What happens is that the same id is presented twice and it is ambiguous which one is chosen by the browser (although most choose the first instance). If both id's are in the same place then this is not a problem.
 * Given a choice between making a link go to a section name or an anchor, I always make it go to the anchor. Anchors rarely change and are a stable target. Sections headings change a lot as editors change styles, add/remove dates, etc to them. Anybody deleting anchors in articles should seriously consider what they are breaking. But of course, on your own talk page you can do what you like. In this particular case on a user page (not an article) I would leave the anchors off because only you are maintaining the page, the section heading is unlikely to change and only a few people will ever read it (compared to articles).  Stepho  talk 00:43, 26 May 2023 (UTC)
 * Thanks : "If both id's are in the same place then this is not a problem."
 * The anchor was on a Help:Table section. See the diff linked at the top of this thread. The discussion started on a user talk page. I clarified the note at the top. --Timeshifter (talk) 04:20, 26 May 2023 (UTC)
 * Please see the link in my post of 19:11, 25 May 2023 (UTC), where you will find When specified on HTML elements, the  attribute value must be unique amongst all the IDs in the element’s tree so when two ids have the same value, this is invalid HTML. -- Red rose64 &#x1f339; (talk) 08:43, 28 May 2023 (UTC)
 * Sure, technically it is invalid according to a very specific clause in the W3 specs. A clause that no browser I know of actually obeys. It's more of a recommendation for generators of HTML. Every browser I know of just looks for the first instance of the id and uses that. Some might differ in the order they search (top down, bottom up, inner elements vs outer, etc). And beyond that very specific clause, it will still pass every other validity test. Not a problem in the real world if all the replicated id's are in the same place. If they are in different places then it just means that the browser might not select the one you think it should.  Stepho  talk 09:09, 28 May 2023 (UTC)

It is not invalid HTML. Emphasis added by me. See: https://www.w3schools.com/html/html_id.asp - "The HTML id attribute is used to specify a unique id for an HTML element. You cannot have more than one element with the same id in an HTML document."

The duplicate IDs are for the same HTML element. They are not for 2 different HTML elements. So the rules are not being violated.

Redrose64 linked to:
 * https://www.w3.org/TR/2021/SPSD-html52-20210128/dom.html#ref-for-html-element%E2%91%A0%E2%91%A2 - "The id attribute specifies its element’s unique identifier (ID). ... An element’s unique identifier"

It's all in the fine print. :)

And from a practical point of view we want people to create anchors to the existing section heading name. So that when/if some editor deletes the anchor code in a heading because it is weird or whatever, then links to that anchor will still work. Because the anchor is the same as the heading. At least until someone changes the heading name. --Timeshifter (talk) 09:50, 28 May 2023 (UTC)
 * You claim that The duplicate IDs are for the same HTML element. They are not for 2 different HTML elements.. That is not what is happening here. Look at the HTML source for, that being the one that I reverted bringing about all this debate:  In this snippet, the outermost element is a  , within which are five   elements. Four of these have an   attribute, two of which (the second and fourth of the five) have the same value -  . These are different HTML elements with the same id value, the id value concerned is therefore not unique. I am also puzzled as to how one HTML element might have more than one id. -- Red rose64 &#x1f339; (talk) 18:05, 28 May 2023 (UTC)
 * From the documentation: "The template can be used to create multiple anchors with a single call. For example,

will create three anchors that can then be linked to with,   and  ."
 * Of course it needs to be substituted. People change headings. So people may prefer better anchors, or anchors that match the new heading name. But they don't want to disable old anchor links coming from other pages. Thus one ends up with multiple IDs for the same heading. They are basically multiple redirects for subsection links coming from various other pages.
 * In the end all those IDs in the page source relate to the H3 heading. They may go through the HTML span code within that heading, but the IDs in the end are for the H3 heading. As long as none of those IDs are used for a different H3 heading in the article then there is no problem. All the incoming links to those various anchor IDs end up at the same H3 heading.
 * There are 3 IDs named: "Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk"
 * There are 2 much longer IDs. I don't know what they do.
 * I could set up a couple sandboxes. One with multiple anchor links. One with multiple headings. One of the headings would have all the anchors. All the incoming links would end up at that H3 heading with all the anchors.
 * I know this is true from past experience with other anchor links, etc.. I think the documentation here needs to be clarified.
 * The current Help:Table without the anchor has 2 IDs in that H3 page source code named: "Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk"
 * It also has 2 much longer IDs there. --Timeshifter (talk) 20:19, 28 May 2023 (UTC)
 * The anchor template can indeed create multiple anchors with a single call. But if you look at what it actually does, it creates one span element for each of the parameters. Thus, creates three span elements, whether it is substituted or not. Each of the three has one id attribute. Because Foo, bar and baz are different, the three ids are also different, and there is no problem.
 * the IDs in the end are for the H3 heading - wrong. An  attribute is associated with the element in which it actually appears. It is not associated with any parent element, so the h3 element has no ID. In the snippet above, there are four IDs, one on each of the first four span elements:
 * Of these, no. 3 is unique; it is not a problem. No. 1 differs from the others sufficiently - whilst  is an encoding of a comma, it's enough to make this ID unique as well. The problem is that nos. 2 & 4 are absolutely identical in every way, they are not unique.
 * is not an id, it is a  which is a [//www.w3.org/TR/2021/SPSD-html52-20210128/dom.html#embedding-custom-non-visible-data-with-the-data-attributes custom data attribute] - completely different.
 * If you don't know what a particular ID does, don't worry about it - per the doc that I linked at 19:11, 25 May 2023 (UTC), Identifiers are opaque strings. Particular meanings should not be derived from the value of the  attribute. . The MediaWiki software scatters IDs about for all kinds of reasons. The ID of a HTML element has several purposes: one of these is to provide a point for a browser to jump to, but they are also used in style sheets, scripts, and data processing bots to name but four. -- Red rose64 &#x1f339; (talk) 22:02, 28 May 2023 (UTC)
 * Of these, no. 3 is unique; it is not a problem. No. 1 differs from the others sufficiently - whilst  is an encoding of a comma, it's enough to make this ID unique as well. The problem is that nos. 2 & 4 are absolutely identical in every way, they are not unique.
 * is not an id, it is a  which is a [//www.w3.org/TR/2021/SPSD-html52-20210128/dom.html#embedding-custom-non-visible-data-with-the-data-attributes custom data attribute] - completely different.
 * If you don't know what a particular ID does, don't worry about it - per the doc that I linked at 19:11, 25 May 2023 (UTC), Identifiers are opaque strings. Particular meanings should not be derived from the value of the  attribute. . The MediaWiki software scatters IDs about for all kinds of reasons. The ID of a HTML element has several purposes: one of these is to provide a point for a browser to jump to, but they are also used in style sheets, scripts, and data processing bots to name but four. -- Red rose64 &#x1f339; (talk) 22:02, 28 May 2023 (UTC)
 * If you don't know what a particular ID does, don't worry about it - per the doc that I linked at 19:11, 25 May 2023 (UTC), Identifiers are opaque strings. Particular meanings should not be derived from the value of the  attribute. . The MediaWiki software scatters IDs about for all kinds of reasons. The ID of a HTML element has several purposes: one of these is to provide a point for a browser to jump to, but they are also used in style sheets, scripts, and data processing bots to name but four. -- Red rose64 &#x1f339; (talk) 22:02, 28 May 2023 (UTC)

These 2 IDs are the same as far as concerns them being anchors. Click them and see that they go to the same section in the current Help:Table:
 * Help:Table
 * Help:Table

Those 2 IDs are within the H3 tags in both the current Help:Table and the previous version with the anchor. I already understood that the other IDs (or whatever they are) were not anchors because they were too long.

Anchors within H3 tags relate specifically to those H3 tags because the text within those tags is what incoming links aim at (via the anchor IDs). Incoming links are not aiming above or below the H3 tags.

The previous version of Help:Table worked fine. The incoming link worked fine. There were no duplicate IDs in the sense that one ID name was applied to 2 headings in an article.

I had that happen once when I had 2 headings in an article both named "Table". Links to that heading went to the first "Table" heading, not the second one. So I have practical experience with this. I had to rename one heading to "Table 2" I believe.

I wasn't clear about this: From the documentation: "The template can be used to create multiple anchors with a single call. For example,

will create three anchors that can then be linked to with,   and  ."

If I was doing it one of those anchors would be the current heading name. Incoming anchor links to all of them would work. Including the anchor link to the current anchor name. As illustrated in the example links higher up. People may even change the heading back to one of the old anchor names. The anchor link would still work in spite of the duplicate ID within the same H3 tag. This is how anchors are supposed to work. --Timeshifter (talk) 23:48, 28 May 2023 (UTC)
 * There is no restriction on the length of an id, nor is there any restriction on the length of a URL fragment. Hence, Help:Table also works.
 * If I was doing it one of those anchors would be the current heading name. You should never need to, because the MediaWiki software creates an anchor inside every h2/3/4/5/6 heading entirely automatically.
 * Most browsers fail gracefully when presented with invalid HTML, it is very rare that an error or warning is displayed - unlike when given an invalid SVG file. The fact that when presented with two identical IDs most browsers will jump to the first one is an indication that the browser has attempted to process the situation as best it can. It is not a good reason to encourage bad practice. Never rely on an undocumented feature, it can change at any time without warning.
 * When you follow a link that has a fragment, it jumps to an anchor if a match exists. That anchor is on the element where the id attribute is specified. In the examples considered, the anchor is on a span element. That is where the browser takes you to. The fact that the span element is enclosed within a h3 element is irrelevant. The browser is not jumping to the h3.
 * Let me again draw your attention to the paragraph 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 space characters. The word "must" occurs three times here, for three different characteristics. The word "must" has a [//www.w3.org/TR/2021/SPSD-html52-20210128/infrastructure.html#conformance-requirements clearly-defined meaning]: RFC 2119 section 1 shows that the definition is an absolute requirement of the specification ; similarly, "must not" means that the definition is an absolute prohibition of the specification . There is no leeway, and no option for variance when you may think that it is more convenient to do so. If there was any leeway at all, the word "should" would have been used instead of "must". -- Red rose64 &#x1f339; (talk) 09:13, 29 May 2023 (UTC)
 * As for the long IDs I meant they weren't anchors created by editors, and no editors would use them to create links. So for our purposes they are irrelevant.
 * And all the anchor links arrive at the H3 heading. Saying they arrive at the span is pedantic. Since the spans are within the H3 heading tags.
 * And using your span logic all the IDs are to different HTML span elements:
 * So there are no duplicate IDs to the same HTML element.
 * And you keep missing my point about making the anchor to the current heading. I have repeated this several times. One does this so that incoming anchor links (both internal and external links) continue to work if some editor messes up or removes the anchor span code within the H3 tags. As you did when you removed the anchor span code. The anchor link still works.
 * If I had created an anchor to a phrase different from the current heading, then my anchor link would have failed when you removed the anchor span code from the heading. --Timeshifter (talk) 10:36, 29 May 2023 (UTC)
 * Yes, all the IDs are in different span elements (and they have to be, since it is not possible to assign two IDs to the same element, even if those IDs are different), but that has nothing to do with it. You seem to be misunderstanding the phrase the attribute value must be unique amongst all the IDs in the element’s tree. In a HTML page, an element's tree is the element itself, all of its descendants, its parent and their ancestors, together with the descendants of each of those. All these span elements that have been mentioned have a single h3 element either as its parent, or as its grandparent. We don't need to go back any further, we have established that they are all part of the same tree. It follows that the  attribute value must be unique amongst all the IDs in the element’s tree comes down to "the   attribute value must be unique within the entire HTML page. -- Red rose64 &#x1f339; (talk) 16:39, 29 May 2023 (UTC)
 * Yes, all the IDs are in different span elements (and they have to be, since it is not possible to assign two IDs to the same element, even if those IDs are different), but that has nothing to do with it. You seem to be misunderstanding the phrase the attribute value must be unique amongst all the IDs in the element’s tree. In a HTML page, an element's tree is the element itself, all of its descendants, its parent and their ancestors, together with the descendants of each of those. All these span elements that have been mentioned have a single h3 element either as its parent, or as its grandparent. We don't need to go back any further, we have established that they are all part of the same tree. It follows that the  attribute value must be unique amongst all the IDs in the element’s tree comes down to "the   attribute value must be unique within the entire HTML page. -- Red rose64 &#x1f339; (talk) 16:39, 29 May 2023 (UTC)

Please see User:Timeshifter/Sandbox196

I substituted an anchor matching the header name "Basic format". I did it twice.

All the anchor links to it still worked. The internal anchor links are listed in several sections.

I temporarily changed the header name to "Basic format. Test." I added and removed "Test" a couple times. See
 * https://en.wikipedia.org/w/index.php?title=User:Timeshifter/Sandbox196&oldid=1157602043

All the anchor links on the page still worked. This was in spite of duplicate IDs in the page source for that H2 tag:

     

I go by what works. As for how it all fits in with the HTML guidelines I may have guessed right early on in the discussion with this:

I knew from the very beginning of this discussion that what I was doing worked. And that nothing I was doing was breaking anything. knew it too. --Timeshifter (talk) 19:07, 29 May 2023 (UTC)
 * In User:Timeshifter/Sandbox196, there are no duplicate IDs on H2 tags on that entire page. In fact, only one H2 tag has an ID, here is the element in its entirety:  and that ID is not found on any other element: it is unique, and it is valid. There are, however, three span elements which have the same ID, the opening tag for the first is   and for the second and third it is  . The first is automatically created by the MediaWiki software, the other two by the anchor template. These three are identical, they are not unique. They therefore do not specify their elements' unique identifiers. They are invalid.
 * I have never claimed that the links do not work. Not once. This whole thing is about your insistence on creating invalid HTML, HTML that uses duplicate (or even triplicate) IDs. It matters not one jot which elements the IDs happen to be on: it is not permitted to use the same ID more than once in the same HTML page. It is against the HTML spec. No part of that spec allows two IDs to have the same value. -- Red rose64 &#x1f339; (talk) 22:15, 29 May 2023 (UTC)
 * I have determined that you really don't know what you are talking about a lot of the time. I noticed on Village Pump that you have made various claims in an authoritative tone. And then been shown to be wrong by various experts. And you rarely admit that you are wrong. And on your user page you say you are using ancient browser versions. How is that helpful to being able to see what others are seeing? I may point to here from the technical Village Pump. --Timeshifter (talk) 01:14, 30 May 2023 (UTC)
 * So I've not updated that part of my user page in - it doesn't mean that it's necessarily still true, all it means is that since browsers went to frequent automatic updates, I couldn't be bothered altering it every month or two. For the record, the browser that I am presently using is Firefox 113.0.2 (64-bit) running under Windows 10 but by this time next week, I might be on Firefox 114. As for I have determined that you really don't know what you are talking about a lot of the time - enough. Stop. -- Red rose64 &#x1f339; (talk) 08:28, 30 May 2023 (UTC)
 * It is an error to have duplicate id's. It doesn't matter how close they are on the page. The specification is clear. User:PrimeHunter/Duplicate id says . https://validator.w3.org/ says "Error: Duplicate ID Heading." It also reports several unrelated errors in the MediaWiki-generated parts of the page. Browsers are forgiving and the potential consequences of this error appear to be minimal but we shouldn't deliberately make HTML errors. MOS:SECTIONCOMMENT says you can add the old section name as an anchor after the section has changed name, and mentions you can "leave an invisible comment at the heading of the target section, naming the linking articles, so that if the heading is later altered these can be fixed". PrimeHunter (talk) 10:08, 30 May 2023 (UTC)

From the Village Pump thread:

I ran User:Timeshifter/Sandbox196 through https://validator.w3.org before PrimeHunter mentioned it. My conclusion is that the tool does not have the power to look if the duplicate IDs are part of the same H2 tag. MOS:SECTIONCOMMENT does not say you can't use the current heading as an anchor target.

And everybody seems to be completely ignoring this comment of mine:

You can say the duplicate IDs are to different anchor span elements. But if those spans are within the same pair of H2 tags, and if you acknowledge that links arrive at the heading, then from my point of view the H2 tags do not have duplicate IDs. "Basic format" as an anchor multiple times within the heading is still just one ID for the H2 tags: "Basic format".

Now if you put the same anchor ID above the heading and below the heading. Or in the heading and outside the heading (anywhere). Then that is a duplicate ID that actually causes consequences. Incoming links to that ID will end up at the first one, and not the second one.

But if the the ID is duplicated within the heading then incoming links all end up at that heading. Nothing is broken. As Johnuniq said "It's a political question, not technical." Since no actual damage has occurred. Of the many errors pointed out by https://validator.w3.org for many Wikipedia pages some have no consequences.

And Mediawiki itself is creating duplicate IDs (within the H2 tags) as people change a heading multiple times. Even without anchors being involved.

There is a distinct advantage to creating an anchor to the current heading name. If someone removes or messes up that anchor in the heading, then incoming anchor links to that heading still work. And if that anchor target in the heading is left alone, then that anchor link still works when people change the heading name.

I am still waiting for someone to point out any damage done by duplicate anchor span IDs within heading tags (H2, H3, etc.).

I think some may be trying to create another useless rule that many people will ignore. Such as H:BR in Help:Line-break handling insisting (in the past) that is preferred. --Timeshifter (talk) 11:23, 30 May 2023 (UTC)
 * https://www.w3schools.com/html/html_id.asp has an example of a h1 element with an id: . If we simplify the HTML for User:PrimeHunter/Duplicate id by removing some irrelevant parts then it says:  . There are three HTML elements here: h2, span and another span. The h2 element starts with   so it has no id. There are two different span elements with the same id. It's very clearly a violation of the rule. It's irrelevant to the rule wether the two id's are inside the same . It may be relevant to the consequences but it doesn't change that it's an obvious rule violation. https://validator.w3.org/ is correct to report it. It's a validator, it reports invalid code, that's the whole idea of a validator. It shouldn't ignore invalid code just because it may not have significant consequences. MOS:SECTIONCOMMENT suggests ways to deal with the problem of broken links to renamed sections. It doesn't suggest your method. The implication is that it's not a recommended method. A manual of style cannot be expected to list everything you shold not do. I have never seen your method used or suggested anywhere so MOS:SECTIONCOMMENT probably has no reason to mention it. Our guidelines are developed in response to what happens. They are not an attempt to foresee everything that could happen. We have millions of section headings. We shouldn't add code to duplicate millions of id's and I don't see why Help:Table is so special that it justifies a HTML error to try to prevent a potential future problem. PrimeHunter (talk) 12:15, 30 May 2023 (UTC)
 * If it's an HTML error, it's an HTML error without a consequence. People are going to keep creating anchor links to the current header name, because there is no damage done. And in fact, as I stated several times there is an advantage to doing so. The reason it has not been discussed much, if at all, before is because it is not a problem except for people who follow useless rules they heard about somewhere. Few others would bother, because people creating these anchor links see that they work, and don't cause problems.
 * Help:Table is linked from Template:Flagg/doc. The best solution there would be to import that section from Help:Table. But I couldn't figure it out. It seemed to be a buggy proposition. --Timeshifter (talk) 14:51, 30 May 2023 (UTC)
 * Timeshifter, in a table* above, you quote Johnuniq as saying, So (assuming we accept that argument), MediaWiki should  be fixed so it does not generate invalid output. Agreed. But what does that prove about your insistence on generating invalid HTML by hand? Why should you (we) need to do that, and why is it worthwhile to the project to spend time  in favor of generating invalid HTML?
 * In general, when you make assertions like, , , etc., I mentally rephrase that to "it still to work", "I go by what  to work", "Nothing  to be broken", etc. Please keep in mind that the particular, visual-browser-based effect on your personal test devices using whatever software you happen to have may not be the effect that others experience. There are (some) forgiving (visual) browsers (currently), but the point of standards is to promote interoperability. Please don't turn your back on the rest of the world because you perceive that something "works".
 * Why isn't your concession enough for you to drop the stick and keep on the path with manually-instigated valid code (no matter what errors MediaWiki generates)? Is it because you don't want to learn how to do it right, don't accept the rules for valid HTML (some of which were made a long time ago; nobody is ), or just don't care about the effects? Or something else? I may be misreading you, even after years of interaction, but you seem here again to be determined to  resist anything that relates to standards if it doesn't perfectly align with what you have decided "works". The arguing is wearisome, the motivation on your end is unclear.
 * You say that, but Redrose64 already refuted your claim that . We therefore didn't completely ignore your comment, we're just not paying it any more attention.
 * Instead of using wikitable markup to produce an HTML table just so you can set off quoted material from whatever comments you're making directly, may I suggest you use Template:Talk quote block, which gives the equivalent visual effect using a, as a one-cell table is inappropriate (and potentially confusing to screen-reader software)? &mdash; JohnFromPinckney (talk / edits) 14:43, 30 May 2023 (UTC)
 * Please see my previous replies. --Timeshifter (talk) 14:51, 30 May 2023 (UTC)

Comment. For those who are interested there is more discussion at Village pump (technical)/Archive 206 and the following subsection: Village pump (technical)/Archive 206 --Timeshifter (talk) 00:25, 1 June 2023 (UTC)

Need guidance for anchors to list items
How should I attach an anchor to a list item? There is an example here: Manual of Style/Images. 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)
 * Put it in between the asterisk and the text, . Alternatively, put it at the tail end of the previous list item.
 * The only time that 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  attribute, you can see how it's used in the lead section of Featured article criteria or at Good article criteria. -- Red rose64 &#x1f339; (talk) 22:32, 12 June 2023 (UTC)

Rationale for substitution in the header
The information in the section Template:Anchor/doc 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. -- Red rose64 &#x1f339; (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 . fgnievinski (talk) 02:00, 10 September 2023 (UTC)
 * 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. -- Red rose64 &#x1f339; (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)

Stop generating linter errors: make the tag self-close
Change line 21:

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 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 . Editor, 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 &thinsp;, 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.  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. ; the relevant discussion is at Template talk:Anchor/Archive 1. -- Red rose64 &#x1f339; (talk) 20:54, 16 May 2024 (UTC)
 * A self-closing tag is what this template used to do, until December 2009. ; the relevant discussion is at Template talk:Anchor/Archive 1. -- Red rose64 &#x1f339; (talk) 20:54, 16 May 2024 (UTC)

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

Prevent emitting a newline?
It seems this template should have 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  and  without a good explanation and then promptly closed the discussion at  (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 EngvarB prevent emitting a newline by including a 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)
 * 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 T369520; if not, please state which. -- Red rose64 &#x1f339; (talk) 20:24, 8 July 2024 (UTC)
 * That is correct. Remsense  诉  20:59, 8 July 2024 (UTC)