Jump to content

Template talk:Anchor

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Discussion notice: "Instructions on the placement of 'Anchor' templates" at MoS Talk

[edit]

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]

Anchor in Vector 2022

[edit]

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

[edit]

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

[edit]

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

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

[edit]

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

[edit]

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]

Stop generating linter errors: make the tag self-close

[edit]

Change line 21:

−
ret[#ret + 1] = '<span class="anchor" id="' .. anchor .. '"></span>'
+
ret[#ret + 1] = '<span class="anchor" id="' .. anchor .. '"/>'

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]

Recommend against placing the anchor above a section heading

[edit]

The doc says Another anchor named #Above-Foo has been placed above the section header. This anchor does work correctly, but because the anchor is technically not in the section but before it, it makes editing counter-intuitive. Such an anchor does not always work correctly on mobile, because if the anchor is above a level 2 (or 1) heading, the previous section will be expanded instead of the one the anchor is supposed to point to. We should deprecate such usage, at least above level 2/1 headings. Try opening [2] on mobile for an example. Nickps (talk) 19:22, 17 May 2024 (UTC)[reply]

Prevent emitting a newline?

[edit]
Tracked in Phabricator
Task T369520

It seems this template should have <nowiki /> at the very beginning as to prevent emitting a visible newline, which drives people crazy. Is there a technical reason this is not done? Remsense诉 13:33, 8 July 2024 (UTC)[reply]

Why do you do this? You did it at {{CS1 config}} and {{bots}} without a good explanation and then promptly closed the discussion at Help talk:Citation Style 1 § Whitespace in `CS1 config` and `bots` (else I would have replied there). What is it that necessitates this change? If this is a bandaid to cover over a bug, shouldn't you be reporting it at WP:PHAB?
—Trappist the monk (talk) 13:49, 8 July 2024 (UTC)[reply]
Apologies. I just assumed that since these templates are meant to be invisible and aren't meant to be substituted, there would be no reason for them to emit a newline. I'll self-rv. Remsense诉 13:57, 8 July 2024 (UTC)[reply]
There is no need to emit a new line. If they do, then perhaps there is a bug at MediaWiki. If there is a bug, you should report it at WP:PHAB.
—Trappist the monk (talk) 14:20, 8 July 2024 (UTC)[reply]
Templates like {{EngvarB}} prevent emitting a newline by including a <nowiki /> tag at the very beginning. Presently, {{Bots}} and {{CS1 config}} do not do this, so I have to stack them on the same line when I use them together in an article to prevent excess whitespace. I thought this was all understood or intended behavior. Remsense诉 14:23, 8 July 2024 (UTC)[reply]
Confirmed at A. This seems like a bug in how MediaWiki handles these sorts of templates. Report it at WP:PHAB.
—Trappist the monk (talk) 14:28, 8 July 2024 (UTC)[reply]
Thank you; sorry for the confusion. Remsense诉 14:29, 8 July 2024 (UTC)[reply]
@Trappist the monk, this is apparently pretty ancient behavior, so while I opened a fresh ticket I wouldn't expect it to do much. Remsense诉 19:52, 8 July 2024 (UTC)[reply]
It's always a good idea to provide the ticket number. I'm assuming this is phab:T369520; if not, please state which. --Redrose64 🌹 (talk) 20:24, 8 July 2024 (UTC)[reply]
That is correct. Remsense诉 20:59, 8 July 2024 (UTC)[reply]

substitution

[edit]

In the 'Rationale for substitution in the header' section it says that the template should always be substituted. The ration given is that it interferes with wiki software that deals with the section titles and makes the history more awkward. This was true years ago but is no longer true. Substitution replaces a very simple form with a complicated form that is much, much harder to maintain. I see no advantages to substitution and plenty of disadvantages. I propose that we remove the instruction for substitution.  Stepho  talk  22:06, 30 July 2024 (UTC)[reply]

The ration given is that it interferes with wiki software that deals with the section titles and makes the history more awkward. This was true years ago but is no longer true.

It's still the case, unfortunately. If you edit a section with an embedded, unsubstituted anchor, your edit summary will still indicate an edit was to the /* {{anchor|sand}}Box */ section. This might seem like not a big deal in isolation, but it becomes totally unworkable with multiple sections or multiple anchors in an article.Remsense诉 22:11, 30 July 2024 (UTC)[reply]
I do wish we could do anchors differently though: it's a pity that the present HTML standard doesn't have some self-closing tag that's semantically suited for this purpose: <span>...</span> is what we basically have for a "null" tag. Remsense诉 22:19, 30 July 2024 (UTC)[reply]
The abandoned HTML 3.0 spec had the <SPOT> tag for precisely this purpose. Its definition in the DTD was: 
<!-- SPOT is used to insert IDs at arbitrary places
     e.g. for end points of a marked range (see RANGE) -->
<!ELEMENT SPOT - O EMPTY>
<!ATTLIST SPOT id ID #REQUIRED>
so it was implicitly self-closing (like <IMG>) and took exactly one attribute, being ID=. Unlike most other HTML 3.0 proposals, it never made it into either HTML 3.2 (which was a stripped-down 3.0, upwardly-compatible with HTML 2.0) or HTML 4.0 (which was 3.2 plus some of the 3.0 proposals that had been dropped for 3.2). --Redrose64 🌹 (talk) 18:36, 31 July 2024 (UTC)[reply]
It makes plenty of sense that it wouldn't be a real coveted proposal in just about any context except this one, where we're not ever placing <h2>...</h2> tags directly. Remsense诉 18:44, 31 July 2024 (UTC)[reply]

Underscores with substitution

[edit]

Rationale for Special:Diff/1244491219/1248164137:

When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree and must contain at least one character. The value must not contain any ASCII whitespace.[1]

Basic usage without substitution works fine with ASCII whitespace, I think MediaWiki (?) replaces whitespace characters in the input with underscores in the output, which will be valid HTML. But when the template is substituted, any ASCII whitespace characters are kept in the anchor id, which would output invalid HTML. Thus this documentation change and inconvenience.

Module:Anchor doesn't replace whitespace characters in the anchor id with underscores. I'm not sure if this behavior is changeable.

References

  1. ^ "HTML Standard". WHATWG. 26 September 2024. Archived from the original on 28 September 2024. Retrieved 28 September 2024.

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

If the MediaWiki software encounters a construct like <span class="anchor" id="Anchor name 1">, what it actually serves is <span class="anchor" id="Anchor_name_1">, the conversion is automatic. So there is no need to advise people to do something that is completely unnecessary. --Redrose64 🌹 (talk) 11:07, 28 September 2024 (UTC)[reply]
It would normally be, but I tested it here not to be the case with this one when substituted. When this template is inserted without substitution, it works as you're describing it. I hate it as much as you do. 84.250.15.152 (talk) 11:08, 28 September 2024 (UTC)[reply]
The bug or source of confusion appears to originate from Special:Diff: Special:Diff/1248232226 displays the diff with whitespace, but the output seems to be (?) with underscores. I've reverted my changes. 84.250.15.152 (talk) 11:18, 28 September 2024 (UTC)[reply]
Diffs show the difference between two versions of the Wikicode source, not the HTML that is served to clients. --Redrose64 🌹 (talk) 13:15, 28 September 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Anchor&oldid=1255892161"