Template talk:Anchor

From WikiProjectMed
Jump to navigation Jump to search


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#Instructions on the placement of "Anchor" templates. —DocWatson42 (talk) 05:06, 20 May 2021 (UTC)[reply]

Now at Wikipedia talk:Manual of Style/Archive 222#Instructions on the placement of "Anchor" templates - dcljr (talk) 03:54, 24 February 2023 (UTC)[reply]

CSS solution

I hope we can all agree that both recommended options, i.e. either having to put {{anchor}} before the heading that starts the relevant section of the article or subst-ing it within the heading itself, are ugly hacks. {Ideally, {tl|anchor}} should usually be included after the heading, but we cannot do that yet, because the page will scroll past the heading when accessed with the anchor ID as a target (i.e. as a fragment identifier in the URL, following a hash sign #).

I'm wondering if there was, by now, a CSS solution to that issue. It appears that the CSS Scroll Snapping Module should be of help, which has reasonable browser support already. I just haven't figured out how exactly, but it should probably look something like this in a global stylesheet: 

h2 + span.anchor:target,  h2 + span.anchor ~ span.anchor:target,
h3 + span.anchor:target,  h3 + span.anchor ~ span.anchor:target,
h4 + span.anchor:target,  h4 + span.anchor ~ span.anchor:target,
h5 + span.anchor:target,  h5 + span.anchor ~ span.anchor:target,
h6 + span.anchor:target,  h6 + span.anchor ~ span.anchor:target {
  scroll-padding-top: 3em; /* some value that covers the heading height */
}

(Anchors should really be a elements that are literally called anchor elements, but Wikipedia chose meaningless span instead in Module:Anchor. In a perfect world, Mediawiki syntax for headings would support manual IDs with something like == Heading == #id or == Heading #id == for <h2 id="id">Heading</h2> or <h2 id="Heading"><a id="id">Heading</a></h2> HTML output.)

Can we please explore this option and implement it if successful? The readability of article source code would benefit from it. — Christoph Päper 08:21, 22 March 2022 (UTC)[reply]

Heading heights differ between skins. Izno (talk) 15:38, 24 March 2022 (UTC)[reply]
The jumping position doesn't have to be perfect. Readers should see the whole heading and maybe a few pixels more. Also, if this works in principle, it could be fine-tuned per theme and heading level. — Christoph Päper 07:42, 1 April 2022 (UTC)[reply]
Yes, template substituting makes the page source code ugly, let's hope for a better solution. fgnievinski (talk) 18:08, 23 April 2022 (UTC)[reply]

VP idea

Editors who watch this page may be interested in Wikipedia:Village pump (idea lab)#Improving redirects to sections of a page, where it is proposed that {{Anchor}} be used much more widely. Certes (talk) 18:26, 11 May 2022 (UTC)[reply]

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:
== Section header{{subst:anchor|Anchor name}} ==

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

=={{subst:Anchor|anchor name}}Section title==

Which one should it be? Does it actually make a difference? — Umofomia (talk) 17:11, 11 August 2022 (UTC)[reply]

@Umofomia: See #Documentation boldly changed; some unaddressed objections in preceding discussion, however above. --Redrose64 🌹 (talk) 05:27, 12 August 2022 (UTC)[reply]
Thanks @Redrose64; I saw that thread, though the discussion there seemed a bit unfocused, with commenters primarily arguing about the use of subst: 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. — Umofomia (talk) 17:30, 12 August 2022 (UTC)[reply]

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

"Template:Anchro" listed at Redirects for discussion

The redirect 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 Wikipedia:Redirects for discussion/Log/2023 May 22 § Template:Anchro until a consensus is reached. Q𝟤𝟪 00:18, 22 May 2023 (UTC)[reply]

"Template:Ancor" listed at Redirects for discussion

The redirect 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 Wikipedia:Redirects for discussion/Log/2023 May 22 § Template:Ancor until a consensus is reached. Q𝟤𝟪 00:19, 22 May 2023 (UTC)[reply]

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:

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

If you view the HTML source for any section heading on any Wikipedia page, you will see that the first tag inside the <h2>...</h2> is a <span id="...">, where the value of the id= 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 id= must be unique within the document. --Redrose64 🌹 (talk) 19:11, 25 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
Thanks Stepho-wrs: "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)[reply]
@Stepho-wrs: Please see the link in my post of 19:11, 25 May 2023 (UTC), where you will find When specified on HTML elements, the id 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. --Redrose64 🌹 (talk) 08:43, 28 May 2023 (UTC)[reply]
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)[reply]

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:

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

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 this version, that being the one that I reverted bringing about all this debate: 
<h3><span id="Adding_links_to_specialized_country.2C_state.2C_etc._articles._With_asterisk"></span><span class="mw-headline" id="Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk" data-mw-thread-id="h-Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk-Adding_flags_and_linking_countries,_states,_etc._in_lists"><span data-mw-comment-start="" id="h-Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk-Adding_flags_and_linking_countries,_states,_etc._in_lists"></span>Adding links to specialized country, state, etc. articles. With asterisk <span class="anchor" id="Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk"></span><span data-mw-comment-end="h-Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk-Adding_flags_and_linking_countries,_states,_etc._in_lists"></span></span></h3>
In this snippet, the outermost element is a h3, within which are five span elements. Four of these have an id= attribute, two of which (the second and fourth of the five) have the same value - "Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk". 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. --Redrose64 🌹 (talk) 18:05, 28 May 2023 (UTC)[reply]
From the documentation: "The template can be used to create multiple anchors with a single call. For example,
{{anchor|Foo|Bar|baz}}
will create three anchors that can then be linked to with [[#Foo]], [[#Bar]] and [[#baz]]."
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)[reply]
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, {{anchor|Foo|Bar|baz}} 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 id= 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:
  1. id="Adding_links_to_specialized_country.2C_state.2C_etc._articles._With_asterisk"
  2. id="Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk"
  3. id="h-Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk-Adding_flags_and_linking_countries,_states,_etc._in_lists"
  4. id="Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk"
Of these, no. 3 is unique; it is not a problem. No. 1 differs from the others sufficiently - whilst .2C 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.
data-mw-thread-id="h-Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk-Adding_flags_and_linking_countries,_states,_etc._in_lists" is not an id, it is a data-mw-thread-id which is a 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 id 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. --Redrose64 🌹 (talk) 22:02, 28 May 2023 (UTC)[reply]

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:

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,
{{anchor|Foo|Bar|baz}}
will create three anchors that can then be linked to with [[#Foo]], [[#Bar]] and [[#baz]]."

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

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#h-Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk-Adding_flags_and_linking_countries,_states,_etc._in_lists 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 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". --Redrose64 🌹 (talk) 09:13, 29 May 2023 (UTC)[reply]
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:
 <span id="
 <span class="mw-headline" id="
 <span data-mw-comment-start="" id="
 <span class="anchor" id="
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)[reply]
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 id 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 id attribute value must be unique amongst all the IDs in the element’s tree comes down to "the id attribute value must be unique within the entire HTML page. --Redrose64 🌹 (talk) 16:39, 29 May 2023 (UTC)[reply]

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

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

<span class="mw-headline" id="Basic_format._Test">
<span class="anchor" id="Foo">
<span class="anchor" id="In-Foo">
<span class="anchor" id="Anchor_name_1">
<span class="anchor" id="Anchor_name_2">
<span class="anchor" id="Basic_format">
<span class="anchor" id="Basic_format">
<span class="anchor" id="Basic_format._Test">

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:

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:

I knew from the very beginning of this discussion that what I was doing worked. And that nothing I was doing was breaking anything. Stepho-wrs knew it too. --Timeshifter (talk) 19:07, 29 May 2023 (UTC)[reply]

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: <h2 id="mw-toc-heading">Contents</h2> 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 <span class="mw-headline" id="Basic_format"> and for the second and third it is <span class="anchor" id="Basic_format">. 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. --Redrose64 🌹 (talk) 22:15, 29 May 2023 (UTC)[reply]
I have determined that you really don't know what you are talking about a lot of the time. I noticed on Wikipedia: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)[reply]
So I've not updated that part of my user page in eleven years - 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. --Redrose64 🌹 (talk) 08:28, 30 May 2023 (UTC)[reply]
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 == Heading <span class="anchor" id="Heading"></span> ==. 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)[reply]

From the Village Pump thread:

It's a political question, not technical. It could be argued that if a duplicate anchor in the wikitext leads to invalid html, MediaWiki should be fixed so it does not generate invalid output. Browsers are never going to explode if a duplicate id occurs and there is currently no reasonable way to ensure such duplication never occurs. Johnuniq (talk) 02:09, 30 May 2023 (UTC)[reply]

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:

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."

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 <br /> is preferred. --Timeshifter (talk) 11:23, 30 May 2023 (UTC)[reply]

https://www.w3schools.com/html/html_id.asp has an example of a h1 element with an id: <h1 id="myHeader">My Header</h1>. If we simplify the HTML for User:PrimeHunter/Duplicate id#Heading by removing some irrelevant parts then it says: <h2><span id="Heading">Heading <span class="anchor" id="Heading"></span></span></h2>. There are three HTML elements here: h2, span and another span. The h2 element starts with <h2> 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 <h2>...</h2>. 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#Adding links to specialized country, state, etc. articles. With asterisk 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)[reply]
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#Adding links to specialized country, state, etc. articles. With asterisk is linked from Template:Flagg/doc#Adding links to specialized country, state, etc. articles. With asterisk. 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)[reply]
Timeshifter, in a table* above, you quote Johnuniq as saying, It could be argued that if a duplicate anchor in the wikitext leads to invalid html, MediaWiki should be fixed so it does not generate invalid output. So (assuming we accept that argument), MediaWiki should indeed 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 arguing in favor of generating invalid HTML?
In general, when you make assertions like it still worked, I go by what works, Nothing is broken, etc., I mentally rephrase that to "it still seemed to work", "I go by what seems to work", "Nothing appears 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 Sure, technically it is invalid 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 trying to create another useless rule), 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 emphatically 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 everybody seems to be completely ignoring this comment of mine..., but Redrose64 already refuted your claim that the rules are not being violated. 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 <div>, as a one-cell table is inappropriate (and potentially confusing to screen-reader software)? — JohnFromPinckney (talk / edits) 14:43, 30 May 2023 (UTC)[reply]
Please see my previous replies. --Timeshifter (talk) 14:51, 30 May 2023 (UTC)[reply]

Comment. For those who are interested there is more discussion at Wikipedia:Village pump (technical)/Archive 206#HTML expert needed, relating to the id attribute and the following subsection: Wikipedia:Village pump (technical)/Archive 206#Template:Anchor --Timeshifter (talk) 00:25, 1 June 2023 (UTC)[reply]

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]
Retrieved from "https://mdwiki.org/wiki/Template_talk:Anchor"