This is the talk page for discussing improvements to the Anchor template. |
|
Archives: Index, 1, 2Auto-archiving period: 730 days ![]() |
![]() | Text and/or other creative content from this version of Template:Anchor was copied or moved into Template:Wp/nod/anchor with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. |
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)
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)
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).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)
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)
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)
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)
<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)
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)
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)
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>
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)
((anchor|Foo|Bar|baz))
[[#Foo]]
, [[#Bar]]
and [[#baz]]
."((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:
id="Adding_links_to_specialized_country.2C_state.2C_etc._articles._With_asterisk"
id="Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk"
id="h-Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk-Adding_flags_and_linking_countries,_states,_etc._in_lists"
id="Adding_links_to_specialized_country,_state,_etc._articles._With_asterisk"
.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.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)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)
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.
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)
<span id="
<span class="mw-headline" id="
<span data-mw-comment-start="" id="
<span class="anchor" id="
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)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)
<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 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)
== 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)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) |
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)
<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)
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?
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".
Sure, technically it is invalidenough 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.
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.
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)
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)
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)
((anchor))
should be substd is when it's used in section headings, because it causes difficulties if not substd there.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)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)
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)
![]() | This edit request to Module:Anchor has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Change line 21:
− | ret[#ret + 1] = '<span class="anchor" id="' .. anchor .. | + | 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)
<span>...</span>
is neither a void nor a foreign element so may not be 'self closed'.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)