Template talk:Anchor/Archive 2
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 |
Undocumented character limitation
I am doing a lot of cleanup and fixup on Klingon grammar in my sandbox, with the original intention of Template:Tt-Klingonifying it. Because of the complexity of the topic, it was already running to three levels of subheads—
- ==== Type 6 ====
—and I've found it worthwhile to extend it to five equal signs. Now, in order to cross-refer within it without digging even deeper, I've been trying to add anchors to a few individual paragraphs. The most reasonable name for such an anchor is the Klingon morpheme that the paragraph is about, as referenced in the text, so that I can simply copy and paste. Unfortunately, trying to do this has uncovered at least one more character that won't work in an anchor.
The apostrophe is a full-fledged letter of the alphabet in Roman-script Klingon, possibly the most frequent consonant. Partly for visual clarity and partly to avoid massive conflict with wikitext, it is often replaced with a right single quotation mark (U+2019 ’). But anchors containing this character don't work. I added an anchor on the -wI’ paragraph, using {{anchor|-wI’}}, but when I saved the page and added #-wI’ to the URL, I just came to the top of the page, same as without any anchor. It's not the hyphen's fault: #wI’ (right single quote, no hyphen) fails the same way, but #-wI' (ASCII apostrophe, hyphen) works fine.
And as long as I was testing that, I tried é. Actually, I tried a bunch of different ways of getting it:
- é
- Insert:Latin from the menu under the editing pane, then copy that from the page and paste into the address line
- direct selection from my Mac character viewer
- Mac U.S. Extended keyboard {ALT-e}{e}
- Mac U.S. Extended keyboard {e}{ALT-SHIFT-e}
And, as you probably know or have guessed, none of them worked.
I don't know enough about templates to be willing to mess with even the documentation of such a widely used one, but presumably the W'ians who pay attention to this talk page are. Somebody, please add this to the documentation. If you want my input, {{ping}} me. --Thnidu (talk) 06:16, 26 February 2014 (UTC)
- The template appears to have created the anchor in the manner to be expected. You did not provide any links to the old versions of your sandbox, so I am not 100% sure that I have correctly identified the versions of the page containing what you desired (you appeared to try multiple things before, after, and in between these).
anchor you used | link to anchor in old version of your sandbox | What to append to the URL |
---|---|---|
{{anchor|-wI’}} |
link here | #-wI.E2.80.99
|
{{anchor|lu’}} |
link here | #lu.E2.80.99
|
{{anchor|é}} |
link here | #.C3.A9
|
{{anchor|é}} |
link here | #.C3.A9
|
- As you have probably figured out from the examples above, the unicode characters are encoded. While the encoding is deterministic, I commonly just put the string in a heading (e.g.
==-wI’==
) and just copy what is in the URL bar once I've clicked on it in the TOC while previewing the edit, alternately you can look in the page source to determine the ID of the<span>...</span>
. — Makyen (talk) 13:46, 26 February 2014 (UTC)
- Thank you, Makyen! I just saw your reply, as you didn't {{ping}} me or use my user-id, and I don't put every page I comment on onto my watchlist. As it happens, I've gone with a different and somewhat more readable, though less general, workaround.
- The Klingon apostrophe stands for a glottal stop, as is the case with many real languages. Before computers, linguistic analyses of languages that included such a phoneme often used a digit 7 for it, since that was easy to type on typewriter, generally unambiguous, and not as easy to overlook. So I changed "-wI’" to "-wI7" in the anchor and the link, and it worked fine. --Thnidu (talk) 06:24, 8 April 2014 (UTC)
- No problem.
- Sorry for the lack of a @Thnidu:. Clearly, I did not think about/forgot to do so at the time. That is particularly egregious oversight on my part given that you stated the need in your last sentence. Then time passed...
- I am glad you have a solution that works. — Makyen (talk) 06:44, 8 April 2014 (UTC)
Text shown by the template and text parameter
From the documentation: "If the text to be displayed must differ from the anchor (e.g. because it contains brackets for linking), the text parameter can be used:"
But no text is shown by this template! Neither without text parameter nor with it. --109.53.196.52 (talk) 11:43, 15 June 2014 (UTC)
- I don't know how it got in the documentation; as far as I can tell, It does not support
|text=
and it never was. I've removed it.-- [[User:Edokter]] {{talk}}
12:23, 15 June 2014 (UTC)- That may have been part of the former template
{{Section}}
which I think had a text-emitting parameter; that template got deleted (see Wikipedia:Templates for discussion/Log/2011 January 6#Template:Section & Wikipedia:Templates for discussion/Log/2012 April 17#Template:Section) and probably wrongly "merged" into this one wheras the functionality is available at {{Visible anchor}}. -- Michael Bednarek (talk) 12:36, 15 June 2014 (UTC)
- That may have been part of the former template
Module rating
Module:Anchor/doc states "This module is rated as alpha." Is this still the case? It seems that it is pretty much in general use now, as it is invoked from Template:Anchor. I'm wondering if we're ready now to change the module rating to "protected". I didn't want to just go ahead and do it though, in case I'm missing something. Thanks. – Wdchk (talk) 01:09, 24 July 2014 (UTC)
- Actually, I've come to dislike the module rating templates, as there isn't really any objective standard that we are judging the modules by. The ratings are all pretty arbitrary. I've removed the template from the module doc page - perhaps I should nominate the template for deletion as well. — Mr. Stradivarius ♪ talk ♪ 02:07, 24 July 2014 (UTC)
Proposed update
I wrote what I feel is a more up-to-date and efficient module, but I don't have edit permissions. Please review and update this if you feel it would be appropriate.
local p = {} local getArgs function p.main(frame) if not getArgs then getArgs = require('Module:Arguments').getArgs end local args = getArgs(frame, { wrappers = 'Template:Anchor', trim = false }) return p._main(args) end function p._main(args) args = args or {} local anchors = {} for k, v in pairs(args) do if type(k) == 'number' and k >= 1 and math.floor(k) == k and string.find(v, '%S') then table.insert(anchors, '<span id="' .. mw.text.trim(v) .. '"></span>') end end return table.concat(anchors) end return p
Vinifera7 (talk) 02:23, 27 July 2014 (UTC)
- For lazy readers, please outline the difference between this and Module:Anchor. I don't mean the efficiency part, but is there any expected difference in output? What/why? This is a very widely used module so a lot of testing would be required before making a change. Anyone can edit Module:Anchor/sandbox and try Module:Anchor/testcases, possibly extending the latter with more tests. Test results are seen at its talk, but a WP:PURGE is probably needed. Johnuniq (talk) 03:31, 27 July 2014 (UTC)
- I don't actually care to do all of that. Since I created this revised module for my own purposes, I figured I'd share it here. Editors can feel free to utilize it, or not. Vinifera7 (talk) 07:43, 29 July 2014 (UTC)
Question
![](http://upload.wikimedia.org/wikipedia/en/thumb/f/fb/Yes_check.svg/20px-Yes_check.svg.png)
I want to add an anchor (this template) to a section header. What is the way to make it end up OK? (without disturbing the section & TOC):
- Then I should read the manual ;-) -DePiep (talk) 21:13, 31 July 2014 (UTC)
My from-page has this link:
[[Some wikipage#MyThing|MyThing]]
The To-page has (two options for demo):
==Target section abc<code>{{anchor|MyThing}}</code>== <code>{{anchor|MyThing}}</code>
The second anchor does not show the section header (when clicked to). Any suggestions? -DePiep (talk) 21:08, 31 July 2014 (UTC)
- (I'm sorry. This question is answered in the documentation) -DePiep (talk) 21:13, 31 July 2014 (UTC)
Edit request: Make subst: available
The documentation has this suggestion for anchoring a section header:
== <span id="Foo"></span> Section title ==
It would be helpful if the template has the subst:
working for this. At the moment, subst: produces {{#invoke:anchor|main}}
. -DePiep (talk) 07:35, 14 October 2014 (UTC)
- added, although I don't know why you would need to substitute it, it's certainly better to have it substitute cleanly or not at all. Frietjes (talk) 23:36, 14 October 2014 (UTC)
- From the #Example 2 in the /doc: plain template code makes the the wikicode showing up in es (together with section header text). es then starts with:
/* == {{anchor|Foo}} Section title == */
.- What DYMB 'cleanly'? -DePiep (talk) 09:23, 15 October 2014 (UTC)
- Frietjes is saying that {{anchor}} should not be substituted ("I don't know why you would need..."), but since it is possible to use subst, the template should be fixed so the subst works (an alternative would be to add a bunch of code to the template which makes it show an error is subst is attempted). There is no good way to do an anchor. Using the span method is good, but it looks very peculiar to uninformed editors—what is its purpose? should it be removed? When the template is used, an editor can refer to the template page to get information. Johnuniq (talk) 10:08, 15 October 2014 (UTC)
- There is a diff between "should not" and "why need". I explained when & why one needs the span tags hardcoded (directly from the /doc, I did not invent it -- I actually needed it). I don't see your "should not" reasoning, except for the conclusion that anchors are bad always - which is a different talk. -DePiep (talk) 10:52, 15 October 2014 (UTC)
- my preference would be to add some variant of Module:Unsubst to have it return itself when someone tries to substitute it. I prefer seeing the more intuitive
{{anchor|foo}}
in wikitext instead of the less intuitive<span id="foo"></span>
. by cleanly, I mean substituting it doesn't break, or create a mess. Frietjes (talk) 18:34, 15 October 2014 (UTC)- I'm a consumer of this template, and in the /doc this option of plain code is mentioned to solve a minor issue (I met). All fine with me. If you two want to plast this template into a "don't subst, don't hardcode" one, that contradicts the /doc & mind. I have not read a base for this (except that {anchor} is always somewhat wrong). So, I am not convinced yet, I want to be able to use it as it is now, and I think that a template or <span> code in a page is not that extreme. Thanks for the edit. -DePiep (talk) 18:45, 15 October 2014 (UTC)
- To be clear: I'd like to use the subst: option to prevent effects like this, text appearing in an editsummary: "/* {{anchor|Foo}} Section title */ [my es goes here]". live example. -DePiep (talk) 19:02, 15 October 2014 (UTC)
- my preference would be to add some variant of Module:Unsubst to have it return itself when someone tries to substitute it. I prefer seeing the more intuitive
- There is a diff between "should not" and "why need". I explained when & why one needs the span tags hardcoded (directly from the /doc, I did not invent it -- I actually needed it). I don't see your "should not" reasoning, except for the conclusion that anchors are bad always - which is a different talk. -DePiep (talk) 10:52, 15 October 2014 (UTC)
- Frietjes is saying that {{anchor}} should not be substituted ("I don't know why you would need..."), but since it is possible to use subst, the template should be fixed so the subst works (an alternative would be to add a bunch of code to the template which makes it show an error is subst is attempted). There is no good way to do an anchor. Using the span method is good, but it looks very peculiar to uninformed editors—what is its purpose? should it be removed? When the template is used, an editor can refer to the template page to get information. Johnuniq (talk) 10:08, 15 October 2014 (UTC)
Position
I just started using this template. When I jump from a redirect to the anchor, the heading is above the display. Is this the proper operation? --21lima (talk) 17:42, 8 June 2015 (UTC)
- @21lima: It's expected behaviour, but not necessarily desirable behaviour. Your browser jumps to the place where the anchor is: it has no knowledge of what is above (or below) that point. Placement of
{{anchor}}
was discussed at Wikipedia:Village pump (technical)/Archive 136#Broken anchor links but I don't think it was conclusive. --Redrose64 (talk) 17:57, 8 June 2015 (UTC)- I was digging though the discussion above, but it is a bit beyond me. I will talk to my mentor when he returns and see if there is an alternative. --21lima (talk) 18:16, 8 June 2015 (UTC)
- Looking at that discussion and doing a bit of testing, {{shortcut}} works, at least with Firefox and Internet Explorer. The way this template works is confusing and it looks like there has been a lot of discussion but no disposition to resolve the issue. --21lima (talk) 12:30, 9 June 2015 (UTC)
- I don't think that
{{shortcut}}
does anything special. It relies on the existence of redirects: for example, if you follow WP:DATED this goes to the section heading because the redirect WP:DATED is set up as a link to Wikipedia:Manual of Style/Dates and numbers#Precise language, and if you edit that section you'll see that the section heading contains the HTML tag<span id="Precise language" />
. It would work just as well if the redirect were set up to point to Wikipedia:Manual of Style/Dates and numbers#Statements likely to become outdated. --Redrose64 (talk) 12:44, 9 June 2015 (UTC)- I do know my HTML: the shortcut creates <div style="position:relative;top:-3em"><span id="WP:DATED"></span> which positions the page so the heading is at the top (unless the page is at the very bottom). The anchor does no such positioning. --21lima (talk) 17:04, 9 June 2015 (UTC)
- But if you click on WP:DATED, you don't get taken to Wikipedia:Manual of Style/Dates and numbers#WP:DATED - the MediaWiki software follows the link in the redirect, which is to Wikipedia:Manual of Style/Dates and numbers#Precise language. If it did link to the anchor in the shortcut box, that would only aid sighted users: those who rely on screen reader software would be taken to a point in the HTML that is after the heading, so the heading would not be read out, which is potentially a WP:ACCESSIBILITY problem. --Redrose64 (talk) 17:32, 9 June 2015 (UTC)
- Then the shortcut template is not used and is useless in this example. Regardless, the anchor template is confusing and I will find another way to do what I want. --21lima (talk) 21:53, 9 June 2015 (UTC)
- I created links that work the way I want without using the anchor. Perhaps this will be fixed someday and I will take another look. --21lima (talk) 22:18, 9 June 2015 (UTC)
- Can you share your method with us? We might be able to use it to fix this template. Stepho talk 10:28, 10 June 2015 (UTC)
- Link to the heading and add a comment under the heading that it is linked to. To reiterate: Template:Shortcut works. I don't grok Lua, but I can see where Module:Shortcut uses position CSS. --21lima (talk) 10:52, 10 June 2015 (UTC)
- Can you share your method with us? We might be able to use it to fix this template. Stepho talk 10:28, 10 June 2015 (UTC)
- I created links that work the way I want without using the anchor. Perhaps this will be fixed someday and I will take another look. --21lima (talk) 22:18, 9 June 2015 (UTC)
- Then the shortcut template is not used and is useless in this example. Regardless, the anchor template is confusing and I will find another way to do what I want. --21lima (talk) 21:53, 9 June 2015 (UTC)
- But if you click on WP:DATED, you don't get taken to Wikipedia:Manual of Style/Dates and numbers#WP:DATED - the MediaWiki software follows the link in the redirect, which is to Wikipedia:Manual of Style/Dates and numbers#Precise language. If it did link to the anchor in the shortcut box, that would only aid sighted users: those who rely on screen reader software would be taken to a point in the HTML that is after the heading, so the heading would not be read out, which is potentially a WP:ACCESSIBILITY problem. --Redrose64 (talk) 17:32, 9 June 2015 (UTC)
- I do know my HTML: the shortcut creates <div style="position:relative;top:-3em"><span id="WP:DATED"></span> which positions the page so the heading is at the top (unless the page is at the very bottom). The anchor does no such positioning. --21lima (talk) 17:04, 9 June 2015 (UTC)
- I don't think that
- Looking at that discussion and doing a bit of testing, {{shortcut}} works, at least with Firefox and Internet Explorer. The way this template works is confusing and it looks like there has been a lot of discussion but no disposition to resolve the issue. --21lima (talk) 12:30, 9 June 2015 (UTC)
- I was digging though the discussion above, but it is a bit beyond me. I will talk to my mentor when he returns and see if there is an alternative. --21lima (talk) 18:16, 8 June 2015 (UTC)
What about placing {{anchor}} on the line above the line of the section header? I mean, in my opinion something like
{{anchor|Winter annuals}} == Winter ==
looks much more clean and problem-free than
== {{anchor|Winter annuals}} Winter ==
or
== <span id="Winter annuals"></span> Winter ==
No browser problems, no hassles with markup within the section header, clicking on the link the section heading will properly appear on the top of the page. What do you think? -- Basilicofresco (msg) 16:54, 13 August 2015 (UTC)
- Hello! Here are a few issues with the anchor placement before the section heading:
- To edit anchors for a section, you'd need to to edit the section above. Very inconvenient, counter-intuitive, and likely a source of many complaints down the road.
- Moreover, when you edit the section above and save it, a newline would be automatically added between the
{{Anchor}}
and the section heading. Not good.
- Thus, IMHO it wouldn't be such a great thing. — Dsimic (talk | contribs) 19:14, 13 August 2015 (UTC)
- There is also the possibility that somebody editing the section above might not understand what the
{{anchor}}
is for, and either add text below it (instead of above), or remove it entirely. --Redrose64 (talk) 19:45, 13 August 2015 (UTC)
- There is also the possibility that somebody editing the section above might not understand what the
So, is there an agreement that the anchor should be inside the section header? -- Magioladitis (talk) 07:55, 4 September 2015 (UTC)
- Everything points into that direction. — Dsimic (talk | contribs) 08:41, 4 September 2015 (UTC)
- It breaks edit summary linking. --Redrose64 (talk) 08:42, 4 September 2015 (UTC)
- I always manually delete the anchors code from edit summaries. — Dsimic (talk | contribs) 08:44, 4 September 2015 (UTC)
- No. There is a proper fix for this, just no will to apply it. I refuse to use this template while it is broken. --21lima (talk) 17:17, 6 September 2015 (UTC)
- Would you be willing to elaborate that further, please? — Dsimic (talk | contribs) 22:35, 6 September 2015 (UTC)
- I don't see anything wrong with having the {{Anchor}} template just below the header. (It can be in arbitrary positions in text, so I'm not sure the CSS below is appropriate.), even if it could be implemented.) However, if it could be implemented, even conditionally (as in a non-positional argument to the template, positionup=yes), it would be a good idea to then move the templates out of the headers. — Arthur Rubin (talk) 19:39, 20 January 2016 (UTC)
- Yeah, but can it be implemented? We already have the positioning that works only half the time. — Dsimic (talk | contribs) 22:16, 20 January 2016 (UTC)
- I don't see anything wrong with having the {{Anchor}} template just below the header. (It can be in arbitrary positions in text, so I'm not sure the CSS below is appropriate.), even if it could be implemented.) However, if it could be implemented, even conditionally (as in a non-positional argument to the template, positionup=yes), it would be a good idea to then move the templates out of the headers. — Arthur Rubin (talk) 19:39, 20 January 2016 (UTC)
- Would you be willing to elaborate that further, please? — Dsimic (talk | contribs) 22:35, 6 September 2015 (UTC)
- No. There is a proper fix for this, just no will to apply it. I refuse to use this template while it is broken. --21lima (talk) 17:17, 6 September 2015 (UTC)
- I always manually delete the anchors code from edit summaries. — Dsimic (talk | contribs) 08:44, 4 September 2015 (UTC)
- It breaks edit summary linking. --Redrose64 (talk) 08:42, 4 September 2015 (UTC)
shortcut v. anchor
Module:Shortcut includes CSS to move up from the link by 3em:
local anchorDiv = root :tag('div') :css('position', 'relative') :css('top', '-3em')
Module:Anchor has no such move. Related discussions above. I don't know Lua. --21lima (talk) 23:37, 6 September 2015 (UTC)
[C]leaner code
This can be more lean and clean by changing:
ret[#ret + 1] = '<span id="' .. anchor .. '"></span>'
to:
ret[#ret + 1] = '<span id="' .. anchor .. '" />'
— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 08:21, 13 March 2016 (UTC)
- I have no opinion but the matter was discussed in the archive. Search for "self closing" for one comment, and see the immediately following comment which has "self-closing". Johnuniq (talk) 09:06, 13 March 2016 (UTC)
- That still is invalid HTML. And even though HTML Tidy would correct it, we certainly should not rely on it so we can use "cleaner" but invalid code.
-- [[User:Edokter]] {{talk}}
10:02, 13 March 2016 (UTC)
Template-protected edit request on 18 March 2016
![]() | This edit request to Template:Anchor has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I would like to add the name of "Garware-Wall Ropes Ltd." in the list. They are the pioneers in the synthetic cordage industry in India and are world’s largest producer of polymer cordages. Their website url is http://garwareropes.com/. 115.111.32.170 (talk) 09:56, 18 March 2016 (UTC)
Not done: this is the talk page for discussing improvements to the template
{{Anchor}}
. Please make your request at the talk page for the article concerned. -- John of Reading (talk) 10:05, 18 March 2016 (UTC)
Anchors not working?
I've noticed that anchors have not been working for me several times today on different pages. I am just taken to the top of the page. Is anyone else finding this? — Martin (MSGJ · talk) 15:43, 19 October 2015 (UTC)
- Examples? --Redrose64 (talk) 22:34, 19 October 2015 (UTC)
- Can't find any now. Perhaps it was my browser being silly. — Martin (MSGJ · talk) 12:32, 20 October 2015 (UTC)
- To editors MSGJ and Redrose64: Oh, I find this all over, just not 100% of the time. Happens in Firefox for Windows, bunches & bunches of version numbers back, and I stay current (with loads of add-ons and tons of tabs open). What fixes it for me is to reload while overriding the cache, which I've always found odd. Hm. I've never noticed if it only happens when opening in a new tab as opposed to the same one. Anyway, if I notice it again, I'll try to duplicate it with add-ons disabled. --Geekdiva (talk) 03:24, 18 January 2016 (UTC)
- The same here. Sometimes anchors work, sometimes they do not. ATM https://wiki.riteme.site/w/index.php?title=Qt_5.6_LTS&redirect=no is not working. Firefox 45.4.0 with NoScript on + blocking "wikipedia.org". I only enable when using "HotCat", I dislike the scripts here. AFAIK anchors have nothing to do with JS, they are HTML-only. User:ScotXWt@lk 07:42, 13 October 2016 (UTC)
- To editors MSGJ and Redrose64: Oh, I find this all over, just not 100% of the time. Happens in Firefox for Windows, bunches & bunches of version numbers back, and I stay current (with loads of add-ons and tons of tabs open). What fixes it for me is to reload while overriding the cache, which I've always found odd. Hm. I've never noticed if it only happens when opening in a new tab as opposed to the same one. Anyway, if I notice it again, I'll try to duplicate it with add-ons disabled. --Geekdiva (talk) 03:24, 18 January 2016 (UTC)
- Can't find any now. Perhaps it was my browser being silly. — Martin (MSGJ · talk) 12:32, 20 October 2015 (UTC)
@ScotXW: I examined the problem at my sandbox (permalink). The reason the anchor fails in the example you gave is that it is used in the "style" part of a cell in a table, and that displays nothing on the page, so no output from the anchor occurs. I put a solution using #Xt5.6
to show that it can work.
- User:Johnuniq/sandbox#Qt5.6 (permalink) (this does not work)
- User:Johnuniq/sandbox#Xt5.6 (permalink) (this works)
Johnuniq (talk) 09:42, 13 October 2016 (UTC)
- @Johnuniq Thank you very much! I would not have come up with this in a 1000 years. User:ScotXWt@lk 16:07, 13 October 2016 (UTC)
- You can do it without
{{anchor}}
, by using theid=
attribute- User:Johnuniq/sandbox#Zt_5.6 (permalink) (this works)
- You are limited to one id per cell. --Redrose64 (talk) 15:56, 13 October 2016 (UTC)
- Interesting, thanks. Trouble is, my brain is full. Johnuniq (talk) 23:07, 13 October 2016 (UTC)
Edit request: pls add the new Category:Wikipedia section templates
![]() | This edit request to Template:Anchor has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please add the new Category:Wikipedia section templates to the template. --Fixuture (talk) 01:34, 8 January 2017 (UTC)
Not done:
{{edit template-protected}}
is usually not required for edits to the documentation, categories, or interlanguage links of templates using a documentation subpage. Use the 'edit' link at the top of the green "Template documentation" box to edit the documentation subpage. Primefac (talk) 01:52, 8 January 2017 (UTC)
Typo
In the third-from-last line under "Examples", the page has "Eurpoean". Nortonius (talk) 10:18, 17 February 2017 (UTC)
- @Nortonius: fixed by Michael Bednarek. Actually, you could have fixed it yourself too, as the documentation page is not protected. Thanks for pointing it out. :) Best — Mr. Stradivarius ♪ talk ♪ 15:39, 17 February 2017 (UTC)
- Aha! You're welcome, and thanks Mr. Stradivarius, I had no idea! Nortonius (talk) 15:43, 17 February 2017 (UTC)
Suggestion... need examples with renderings.
This looks to be outdated and could use a face lift to make it easier to understand. A perfect example of a perfect example is Help:List-defined references#Examples. I would be happy to do it but I'm presently tied up with another article I'm working on, that is dominating my time. If anyone has time, can you please work on this? MagnoliaSouth (talk) 20:47, 28 March 2015 (UTC)
- MagnoliaSouth: I recently made a sizable expansion to the "Examples" section of the template documentation (#5). I'd love to know if this makes the template seem easier to understand and use. Thanks! KDS4444 (talk) 21:00, 1 February 2017 (UTC)
- KDS4444: Excellent! I apologize for my tardiness but my mother became very ill and passed away. It was much more the time domination. Anyway, I just wanted you to know that I do appreciate the changes. You did a very fine job! MagnoliaSouth (talk) 18:15, 21 September 2017 (UTC)
- Dude... I am so sorry to hear this. I guess I don't know what your relationship with your mom was like, but whatever it was like, she was your mom and now she is gone and there is a certain pain there that... Anyhow. I am sorry to hear this. On another note, I am very glad to know you like what I did here. Sometimes I fight with whether or not other Wikipedia editors consider me to a burden rather than benefit, and maybe I should just walk away and leave well enough alone. Any expression of gratitude seems like a real rarity, so I have to thank you deeply for that. Maybe that's the nature of collaborative editing. But thank you for noticing. And for saying something. Seven months later...! KDS4444 (talk) 00:17, 22 September 2017 (UTC)
Template-protected edit request on 19 January 2017
![]() | This edit request to Module:Anchor has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I've copied the module into a sandbox and made the module much simpler and faster, removing all dependencies and simplifying the algorithm. Could anyone copy my sandbox to the main module? Luis150902 (talk | contribs) 09:21, 19 January 2017 (UTC)
- Links to templates/modules:
- Template:Anchor • Template:Anchor/sandbox
- Module:Anchor • Module:Anchor/sandbox • Module:Anchor/sandbox2
- I temporarily disabled the edit request because I think some testing with an actual template would be needed. A quick look at Module:Anchor/sandbox2 seems to show it only gets parameters from
{{#invoke:...}}
whereas it needs to get the template parameters before it can work in Template:Anchor. Why was there a need set up sandbox2 rather than use Module:Anchor/sandbox? Would Mr. Stradivarius like to comment? I find Module:Arguments a bit opaque for a simple module like this, and its need to calltableTools.compressSparseArray
looks like a lot of overhead although I'm sure it amounts to nothing in actual usage. Johnuniq (talk) 09:56, 19 January 2017 (UTC)- @Luis150902 and Johnuniq: I think the idea of ignoring the order of the anchors is a good one - as they are invisible and will attach to the same point in the DOM, I can't think of a drawback of changing their order. There are a few things that would break with this change, though:
- If there are any blank arguments (e.g. the first argument in
{{anchor||foo}}
) then they will create spans with an empty id attribute (<span id=""></span>
), which we should avoid. - We should be trimming whitespace from the arguments, so that
{{anchor| foo }}
produces<span id="foo"></span>
, not<span id=" foo "></span>
. - If there are any template transclusions with named arguments (e.g.
{{anchor|foo=bar}}
), then they will create anchors where none existed before.
- If there are any blank arguments (e.g. the first argument in
- Also, I would avoid repeating the for loop in the
main
and_main
functions. DRY code is good code, IMO. :) Best — Mr. Stradivarius ♪ talk ♪ 01:08, 20 January 2017 (UTC)- A thought - maybe anchor order makes a difference to people editing Wikipedia with screen readers? — Mr. Stradivarius ♪ talk ♪ 14:14, 20 January 2017 (UTC)
- As regards whether the anchor is placed before, within or after a section heading (remember that section headings auto-generate anchors) - it definitely makes a difference. But if the question is merely about when two anchors are placed consecutively, the order of those is immaterial. --Redrose64 🌹 (talk) 21:43, 20 January 2017 (UTC)
- @Mr. Stradivarius: I have added tests for named anchors as well as for mixtures of both in my sandbox and I am now using DRY code. All 9 tests have passed. Luis150902 (talk | contribs) 16:56, 31 January 2018 (UTC)
- @Luis150902: Thanks for the code update! I've added a couple more tests for whitespace-related things which aren't passing right now. You might also want to consider using the inequality operator
~=
- that means you can dov ~= ""
instead ofnot (v == "")
, which is a little bit easier to read in my opinion. And if you want, you can also check whether arguments are positional by doingtype(k) == "number"
. If this was being called from Lua then that wouldn't be enough, as you can pass in keys like1.5
; but if we assume that the module is being called from a template, then keys like those would be turned into strings. After the tests pass I think we're probably good to roll it out to the wider world. Best — Mr. Stradivarius ♪ talk ♪ 13:41, 1 February 2018 (UTC)- @Mr. Stradivarius: After the code modifications, all 12 tests have passed, including the tests you added. Luis150902 (talk | contribs) 18:30, 14 February 2018 (UTC)
- @Luis150902: Thanks for the code update! I've added a couple more tests for whitespace-related things which aren't passing right now. You might also want to consider using the inequality operator
- A thought - maybe anchor order makes a difference to people editing Wikipedia with screen readers? — Mr. Stradivarius ♪ talk ♪ 14:14, 20 January 2017 (UTC)
- @Luis150902 and Johnuniq: I think the idea of ignoring the order of the anchors is a good one - as they are invisible and will attach to the same point in the DOM, I can't think of a drawback of changing their order. There are a few things that would break with this change, though:
Section heading examples
Section headings already have anchors attached to them, so they do not need additional anchors. For example, this section of the talk page will have the heading #Section_heading_examples
. So, please take out examples showing use with section headings. They are unnecessary. This template would be better in tables.
Also, would it not be better for text to be included inside the anchor?
{{Anchor|anchor_name|anchor text}}
that would show <span id="anchor_name">anchor text</span>
. Something about empty anchors bugs me.
So please make the change to the documentation and take out the examples with headings and maybe add some text to the anchor so it will not be an empty tag. LA (T) @ 13:07, 5 January 2018 (UTC)
- @Lady Aleena: This is a rather late reply, but I'm afraid you're slightly mistaken about the uses of anchors. Anchors are used in many cases where the title of a section has been changed, to preserve old links to that section (mostly in policy pages, because mainspace articles don't have that many links to individual sections.)
- However, it may be worthwhile as you suggest to add table examples. E to the Pi times i (talk | contribs) 14:53, 8 April 2018 (UTC)
Always substituted?
There was discussion to allow substituting this template and substitution was enabled. The arguments for and against substitution are the same across all articles (maybe in a given namespace). So I think this template should either always be substituted, or never. What do you think? wumbolo ^^^ 08:48, 27 May 2018 (UTC)
- Option 3: sometimes. --Redrose64 🌹 (talk) 21:02, 28 May 2018 (UTC)
Module overkill
To provide such simple functionality as adding html tags to a page, I guess that normal template parameters could do the job. If the maximum number of parameters (say, 100?) is actually insufficient, the template could simply be used multiple times. Why is a module being used for this task? ~ ToBeFree (talk) 19:42, 9 August 2018 (UTC)
- @ToBeFree: A module can use only the parameters specified by the user, but a template can't. For example, if we had an anchor template with 100 anchor parameters, and the user specified only 1, then the template would make 99 unnecessary parameter lookups. And if we wanted to use multiple templates with one parameter each, we would need to change all of the transclusions that used more than one anchor. — Mr. Stradivarius ♪ talk ♪ 11:17, 11 August 2018 (UTC)
- @Mr. Stradivarius: Oh, I didn't expect a module to be able to be more performance-efficient than a template. Thanks for the explanation!
~ ToBeFree (talk) 16:32, 11 August 2018 (UTC)
- @Mr. Stradivarius: Oh, I didn't expect a module to be able to be more performance-efficient than a template. Thanks for the explanation!
Having trouble with the template anchor creation
I'm still having trouble with the anchor code I coded but it says Script error. Xandershelton183 (talk) 01:48, 1 December 2019 (UTC)
- Can you link us to the 2 articles you are attempting to change. Then we can examine what you are trying to do. Stepho talk 07:36, 1 December 2019 (UTC)
subst leads to CW Error #85
Not only does substitution lead to problems, it further prevents further anchors from being easily added in the future as needed. Can we please discourage this behavior in the documents, if not prevent it outright with Module:Unsubst? Jerod Lycett (talk) 08:23, 15 January 2020 (UTC)
- This may (or may not) be related. This dummy edit (which created an edit conflict) apparently broke a bunch of stuff, including anchors I had substituted earlier; fortunately, I could get a couple hours' copyediting back on this GAN candidate. I don't know how it happened, but I won't substitute this template again. Miniapolis 17:10, 11 April 2020 (UTC)
- I really don't think that Diannaa's edit was the direct cause of any problem (BTW it wasn't a WP:DUMMYEDIT, since it did have effect on the rendered page: it altered a hyphen-minus to an en-dash); and nor do I think that substituting
{{anchor}}
is itself an issue. Your edit (which was a full 38 minutes later) is the problematic one; if you have had an edit window open for more than a minute or two, you should always use the Show changes feature to see what else you're about to alter. --Redrose64 🌹 (talk) 20:41, 11 April 2020 (UTC) - @Miniapolis: Have a look at Wikipedia:Village pump (technical)/Archive 180#Character substitution. I think that the problem described there explains your issue. --Redrose64 🌹 (talk) 21:18, 12 April 2020 (UTC)
- Thanks for the ping and the link, Redrose64; the edit-conflict tool was apparently the culprit. I've had it enabled for a while with no problems (except for not being able to figure out how it works
), but have disabled it. Stay well and all the best, Miniapolis 15:35, 13 April 2020 (UTC)
- @Redrose64: I copyedit articles section by section, to minimize edit conflicts. The section on which Diannaa and I were working is long, which was why my edit was 38 minutes after hers; I had been working on it longer than that. Miniapolis 17:04, 13 April 2020 (UTC)
- Thanks for the ping and the link, Redrose64; the edit-conflict tool was apparently the culprit. I've had it enabled for a while with no problems (except for not being able to figure out how it works
- I really don't think that Diannaa's edit was the direct cause of any problem (BTW it wasn't a WP:DUMMYEDIT, since it did have effect on the rendered page: it altered a hyphen-minus to an en-dash); and nor do I think that substituting
Template-protected edit request on 24 September 2020
![]() | This edit request to Module:Anchor has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
An anchor
CSS class should be added in line 21, like this:
ret[#ret + 1] = '<span class="anchor" id="' .. anchor .. '"></span>'
I have figured out that with CSS top paddings (applied via browser add-on), it might be possible to allow navigating to an in-section anchor while still having the section title on the screen. 79.249.159.6 (talk) 21:54, 24 September 2020 (UTC)
Simple directions
Could someone please give a simple explanation for me. It would read like:
- If you have moved a section of one article to a newly created page, place (this) anchor (where) in the source article and (this) anchor (where) in the new article. Much obliged! Jzsj (talk) 20:57, 11 October 2020 (UTC)
Undocumented no-arguments syntax: embrace or extinguish
I noticed this weird construct on a page:
==={{Anchor}}Yesterday's section title===
This usage is wrong. Parameter 1 is "required". The template's behavior in this case is undocumented.
It doesn't show warnings, such as red text in show-preview or adding the page to a hidden maintenance category.
It doesn't break anything, because it either does nothing at all or (unlikely) creates a second anchor of the same name that gets optimized away, with a net result of nothing. (The page HTML shows only one <span class="mw-headline" id="Yesterday's section title">Yesterday's section title</span>
.)
The editor might have picked up a bad habit.
The editor might have intended to create a visible anchor (an anchor with the same name as the section title). But no template is necessary for that – it is the default behavior.
The editor might have intended to show a reminder, hinting that some page might link to [[Article#Yesterday's section title]]
. IF this anchor is in use, AND someone renames the section title, THEN they should create an anchor with the old name?
But the recommended format is to put the anchor above the section title:
{{Anchor|Yesterday's section title}}
===Today's section title===
Possible remedies include no action at all (it's harmless); red warning text during show-preview; and/or a hidden maintenance category. Also, a bot could clean up the unknown number of instances. - A876 (talk) 01:32, 15 October 2020 (UTC)
Template inside heading best practice for the benefit of mobile users
Mobile users cannot edit an entire article, only sections, which are defined to start at the start of a heading (or the article) and end at the start of the next heading of equal or higher level. With that being the case, anything that pertains to a section should be after the section opens so that mobile editors can see and/or edit it when they open that section. A mobile editor will not see an anchor that's placed before the section unless they opened a higher level section, so the anchor should be placed after the ==
. Hairy Dude (talk) 00:17, 30 November 2020 (UTC)
- Templates inside headings cause other problems, see older threads on this page and its archives. --Redrose64 🌹 (talk) 20:44, 30 November 2020 (UTC)
Simplify the explanation?
I cannot make sense of this article. Hypothetical scenario:
Let's say I want to make a link on a page about New York to the history of the United States, and I want this link to read [history of the US]. I want the link to go to a section titled "History" of the United States article. What do I type before the History section header to make an anchor?
{{anchor|History}}? {{anchor|United States|History}}? {{anchor|history of the US}}? {{anchor|United States|history of the US}}?
I can't find an explanation of what the different parts of the template mean.
Cheers, Fredlesaltique (talk) 04:57, 13 February 2021 (UTC)
- This template is not required in that scenario. What's needed is a "section link" as described at Help:Link#Section linking (anchors). (The wording there and, most of all its shortcut [[WP:ANCHOR]], are most unfortunate.) In your case, the code in the article would be something like "New York ... in [[United States#History|America's history]]." which produces ""New York ... in America's history." HTH -- Michael Bednarek (talk) 07:41, 13 February 2021 (UTC)
- @Michael Bednarek: So I know how to section link, but the problem is that if the name of that section "History" changes to something like "History and society," then the link no longer functions correct? So I want to make an anchor for the History section so that even if the name changes, the link will still function.
- So in that case what would the anchor look like? I can't make sense of the syntax :/
- Thanks for reply by the way, Fredlesaltique (talk)
- The placement of anchors in section headings has been discussed here before. There's no consensus on its best placement. I suggest to place {{anchor|History}} before the section heading in the target article; others recommend to place it directly after. Either way, it's good form to add an HTML comment like, "<!-- article xxx redirects here. -->". -- Michael Bednarek (talk) 03:57, 14 February 2021 (UTC)
- @Michael Bednarek: Welp, I went ahead and rewrote it if you want to make sure I didn't make an error! Thanks for all the help. Fredlesaltique (talk) 03:12, 15 February 2021 (UTC)
- @Michael Bednarek: Apart from placement, what do the constituent parts do? Like I saw the example on the template page: {{anchor|Foo|Foo bar}}
- Foo = ? The name of the article?
- Foo bar = ? The name of the section?
- Thanks for the help by the way. Fredlesaltique (talk) 05:34, 14 February 2021 (UTC)
- As explained in the first sentence overleaf,
The template {{Anchor}} inserts one or more invisible HTML fragment identifiers (anchor names) in a page.
. That means, the example creates two anchors, "Foo" and "Foo bar". This is further explained overleaf at "TemplateData". Such multiple anchors may be useful if the section in question is to be targeted from various sources, using different names, for instance because of spelling differences (Humour vs. Humor). -- Michael Bednarek (talk) 05:51, 14 February 2021 (UTC)
- As explained in the first sentence overleaf,
How to create anchor for Template:sfn targets?
I want to create a link target for Template:sfn without using Template:cite. When I click a link created with {{sfn}}, the target citation is highlighted. I can create a link target with {{anchor}}, but is there a way to create a similar highlight effect with a plain wikitext citation that doesn't use any of the citation templates which use separate citation fields? Daask (talk) 16:14, 25 February 2021 (UTC)
{{anchor}}
won't give you the highlighting. You can wrap a plaintext citation in{{wikicite}}
and give it the same id that{{sfn}}
expects:- A couple of
{{sfn}}
templates: - and their matching plain text citations wrapped in
{{wikicite}}
:{{wikicite |ref=CITEREFBlueYellow2021 |reference=Blue + Yellow = Green}}
- Blue + Yellow = Green
{{wikicite |ref={{sfnref|Blue|Green|2021}} |reference=Blue - Green = Yellow}}
- Blue - Green = Yellow
- A couple of
References
Multiple anchors in |- table element don't work
If multiple anchors are placed in the |- table element in front of a table row, only the last anchor seems to work. This is regardless if the anchors are created by a single invocation of {{anchor}} with multiple anchors, or by multiple invocations of the template in a row. As a workaround, the subsequent anchors can be moved to the start of following table element (the first column of that table row). Most browsers still seem to set the focus on the corresponding table row correctly. --Matthiaspaul (talk) 09:50, 3 June 2020 (UTC)
- @Matthiaspaul: I'm surprised that they work at all. The
|-
markup starts a new table row by emitting a<tr>
tag, the remainder of the line becomes the attributes of the tag. For example,becomes|- id="Foo"
The<tr id="Foo">
{{anchor}}
template emits one or more empty<span>...</span>
elements, soyields{{anchor|Foo|Bar}}
What you're suggesting is doing it like this<span id="Foo"></span><span id="Bar"></span>
but that becomes|- {{anchor|Foo|Bar}}
which is, quite simply, invalid HTML. Your browser may attempt to resolve the error by ignoring the second < and the last > which means that it is treating it as if it were<tr <span id="Foo"></span><span id="Bar"></span>>
which is still against the HTML spec (a<tr span id="Foo"></span><span id="Bar"></span>
<tr>...</tr>
element may not contain anything other than<th>...</th>
and<td>...</td>
elements). Put another way, the{{anchor}}
template may only be used where a<span>...</span>
element is valid - essentially, anywhere that visible text might be used. If you were to provide some kind of context I could advise on the best markup to use. --Redrose64 🌹 (talk) 22:07, 3 June 2020 (UTC)- Hi, the context is Talk:List of 7400-series integrated circuits#74888 anchor.
- I now had a look at the generated HTML as well. Fortunately, Mediawiki does not create invalid HTML but just strips off all but the last anchor. So, rather then generating:
<tr <span id="Foo"></span><span id="Bar"></span>>
- or (what I would have expected based on what f.e. IPB would generate)
<tr><span id="Foo"></span><span id="Bar"></span>
- it generates:
<tr id="Bar">
- So, the solution is to either only define one anchor in
|-
and the remaining ones in the first column cell or just move all anchors there. - --Matthiaspaul (talk) 22:47, 3 June 2020 (UTC)
- For anyone else wondering here to find out how to section link in tables: Help:Table#Section link or map link to a row anchor.
- As the documentation says
{{Anchor}}
shouldn't be used in a table after|-
, cause it creates invalid HTML. As Redrose64 and Matthiaspaul wrote above,{{Anchor}}
inserts a<span>
tag within the table, and MediaWiki (most likely the dependency RemexHtml) cleans up this invalid HTML. This also cleans up any additionalid
attributes other than the first one as an element can only have 1id
. So it 'strips off' all other anchors, not just the last one. Afterall this composes a valid HTML code for the simple user, but only for now as this can misbehave in unexpected ways if the parser changes in MediaWiki. - Generally within tables the use of
id
is the best way. It's a possible workaround to have multiple anchors in the same table by using{{Anchor}}
BUT only within the table content, where the text goes. ~ Boro (talk) 10:49, 8 May 2021 (UTC)- I should have replied to Matthiaspaul last June, I don't know why I didn't. The
id=
attribute is valid on all HTML elements, there are no exceptions. Any opening tag may have oneid=
attribute, but no more than one. Table markup in MediaWiki uses five different characters or character combinations to initiate elements, and each may optionally useid=
as follows:There are three pieces of text in this table, and an{| id="Table-A" |+ id="Caption-B" |Caption text |- id="Row-C" ! id="Header-D" |Header cell text |- | id="Data-E" |Data cell text |}
{{anchor}}
tag may be inserted immediately before any of these if extra anchors are required. --Redrose64 🌹 (talk) 13:32, 8 May 2021 (UTC)
- I should have replied to Matthiaspaul last June, I don't know why I didn't. The
Typo
In §Template: Anchor#Use in tables:
- Too see how to set anchors in tables
--Thnidu (talk) 06:01, 2 June 2021 (UTC)
- @Thnidu: At the top of Template:Anchor, find the line with "Template documentation". You can click View to view the documentation page where you can edit it as normal. Johnuniq (talk) 06:54, 2 June 2021 (UTC)
- @Johnuniq: Thanks. ... I see that it has been fixed (by you?), but the history page has no trace of the change. (*boggle*) Thnidu (talk) 21:39, 2 June 2021 (UTC)
- The documentation of a template is usually not on the template page itself, but on a /doc subpage, so at Template:Anchor/doc. It then gets transcluded on the template's main page. That's why you could edit the documentation; it's on a different page with a different protection level. ―Jochem van Hees (talk) 22:04, 2 June 2021 (UTC)
- No, it wasn't me. I was leaving it for you so you could see the idea. You can check it now: click View. That will take you to a new page (usually something/doc). On that new page, click history to see who changed what. Johnuniq (talk) 01:54, 3 June 2021 (UTC)
- @Johnuniq: Thanks. ... I see that it has been fixed (by you?), but the history page has no trace of the change. (*boggle*) Thnidu (talk) 21:39, 2 June 2021 (UTC)
- Ooh, nice catch! I made that typoo, thanks foor fixing it! ~ Boro (talk) 09:13, 3 June 2021 (UTC)
subst:anchor
Hello, what is the difference between == Section header{{subst:anchor|Anchor name}} ==
and == Section header{{anchor|Anchor name}} ==
?
The result seems to be the same. It could be clarified in the documentation Template:Anchor#Basic_format.
--Baptx (talk) 16:10, 20 July 2021 (UTC)
- It is explained in the last paragraph of the section Rationale for substitution in the header :) ―Jochem van Hees (talk) 16:34, 20 July 2021 (UTC)
- @Jochem van Hees: thanks, it is displayed at the end of the section:
The technical complications are described on Wikipedia:Manual_of_Style#Section_headings:Anchors should also never be left unsubstituted within a section header, as this violates MOS:HEADINGS and causes technical complications.
The advantage of using
{{subst:Anchor}}
, or simply inserting the<span>
tags directly, is that when edits are made to the section in the future, the anchor will not be included in page history entries as part of the section name. When{{Anchor}}
is used directly, that undesirable behavior does occur. - So if I understand correctly, the issue is that in the edit summary, instead of having
/* Section name */
we will have a wrong link/* Section name {{anchor|alternative section name}} */
. - I noticed that subst:anchor does not work on the French Wikipedia (fr:Special:diff/184808386) so I used
<span id="Anchor name"></span>
instead (fr:Special:diff/184837653). What is class="anchor" for? It looks like it is not used on the French Wikipedia so I did not add it. --Baptx (talk) 17:25, 20 July 2021 (UTC)
- @Jochem van Hees: thanks, it is displayed at the end of the section:
- Hm yeah it looks like the French Wikipedia uses more a complex template code for extra parameters. I do not know much about the French Wikipedia, but I cannot find any information about about how you're supposed to use it there. I think that typing the span manually is for now a good idea.
- About the
class="anchor"
thing: I have no idea, but it is probably not important. It looks like it was added after this edit request last year, and it looks like this is only useful for some people using a certain browser add-on or something. ―Jochem van Hees (talk) 20:46, 20 July 2021 (UTC)
Documentation boldly changed; some unaddressed objections in preceding discussion, however
![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/ea/Purple_arrow_down.svg/18px-Purple_arrow_down.svg.png)
Please refer to Wikipedia_talk:Manual_of_Style/Archive_222#Instructions_on_the_placement_of_"Anchor"_templates.
Template:Anchor's documentation was boldly changed with this revision; however, I see some unaddressed objection in the discussion. It seems to me that placing the anchor in the previous section just above the next heading is the best option. While it does have the problem that a section could be moved with the anchor then being in the wrong place, I think this is better than the result of substituting the template in the heading of the section the anchor links to.
Please let me know your thoughts. Regards, DesertPipeline (talk) 10:08, 3 August 2021 (UTC)
- What is the objection that you think is not addressed? ―Jochem van Hees (talk) 16:28, 9 August 2021 (UTC)
- User:Jochem van Hees: Actually, I probably should've changed the message before I posted it here. The section wasn't about changing it to say "the anchor goes inside the heading with substitution". That was just something one or two people discussed in the section. I don't think it's the right option because it makes the section title a mess. This is something that others brought up in that section too. That wasn't addressed. Also, the documentation should probably be changed back until there's been a proper discussion on the matter. DesertPipeline (talk) 09:06, 10 August 2021 (UTC)
- Well yeah I was also one of the people who had that objection too, but I changed my mind after someone proposed to put the span tag after the section title, making it a lot easier to read. After nobody disagreed for a while I boldly assumed consensus, but if you disagree then yes we should reopen the discussion. ―Jochem van Hees (talk) 10:19, 10 August 2021 (UTC)
- User:Jochem van Hees: Do you mean that previously the span tag enclosed the section title? I think that it still looks messy regardless if that's the case. And doesn't it show up in the edit summary if you clicked edit on that section? If so, that's another problem I have with it – not just messing up the heading but also causing issues with edit summaries. DesertPipeline (talk) 12:23, 10 August 2021 (UTC)
- @DesertPipeline: if the anchor is left unsubstituted in the header then the anchor does show up in edit summaries; if it is substituted it does not cause such issues. That is why the advice is to substitute it. I don't see how having the anchor in the edit summary would be a good thing. ―Jochem van Hees (talk) 15:01, 10 August 2021 (UTC)
- User:Jochem van Hees: If it doesn't show in the edit summary then maybe it's okay. I still dislike the appearance of the page when doing it this way though. Do you think that's better or worse than the anchor potentially not being moved if in the previous section at the very bottom? DesertPipeline (talk) 17:53, 10 August 2021 (UTC)
- Regarding positioning: the anchor must not be later than the heading text - that is because the anchor is the point to which a browser will move when a link is followed, they won't backtrack to the start of the section heading.
- For users who rely on assistive technology such as screen reader software, that point is where the software starts reading out the text, so in such cases the section heading does not get read out to the user.
- For users with small screens - such as mobile phones - a long heading might be partially or wholly off the screen.
- So the anchor needs to be either before the section heading, or within the heading and before the first word of the heading text. Putting it before the section heading has the disadvantage mentioned above that if a section is moved, care must be taken to keep the anchor adjacent to its heading. This is particularly a danger with discussion pages, where the action of archiving takes the content beginning at one heading (inclusive) and ending at the next heading (exclusive), so might take an anchor with it if that anchor happens to be at the bottom of a section.
- Regarding substitution: if the anchor template is used within a heading but is not substituted it can pollute the true section name and cause links to that section to fail. Generally speaking, unsubstituted templates (of any kind) should not be used in section headings.
- I am absolutely certain that all of this has been discussed before. Graham87 (talk · contribs) - who is a screen reader user - may recall where that was. --Redrose64 🌹 (talk) 18:16, 10 August 2021 (UTC)
- @Redrose64: I have no idea; I don't recall hearing about any of this. Graham87 01:45, 11 August 2021 (UTC)
- Oh, does the anchor being in the header, but just after the header text, mean that screenreaders won't read it? Because that's how it is right now, and we might need to change it if so. ―Jochem van Hees (talk) 09:21, 11 August 2021 (UTC)
- It's fine wherever it is. Graham87 09:34, 11 August 2021 (UTC)
- Regarding positioning: the anchor must not be later than the heading text - that is because the anchor is the point to which a browser will move when a link is followed, they won't backtrack to the start of the section heading.
- User:Jochem van Hees: If it doesn't show in the edit summary then maybe it's okay. I still dislike the appearance of the page when doing it this way though. Do you think that's better or worse than the anchor potentially not being moved if in the previous section at the very bottom? DesertPipeline (talk) 17:53, 10 August 2021 (UTC)
- @DesertPipeline: if the anchor is left unsubstituted in the header then the anchor does show up in edit summaries; if it is substituted it does not cause such issues. That is why the advice is to substitute it. I don't see how having the anchor in the edit summary would be a good thing. ―Jochem van Hees (talk) 15:01, 10 August 2021 (UTC)
- User:Jochem van Hees: Do you mean that previously the span tag enclosed the section title? I think that it still looks messy regardless if that's the case. And doesn't it show up in the edit summary if you clicked edit on that section? If so, that's another problem I have with it – not just messing up the heading but also causing issues with edit summaries. DesertPipeline (talk) 12:23, 10 August 2021 (UTC)
- Well yeah I was also one of the people who had that objection too, but I changed my mind after someone proposed to put the span tag after the section title, making it a lot easier to read. After nobody disagreed for a while I boldly assumed consensus, but if you disagree then yes we should reopen the discussion. ―Jochem van Hees (talk) 10:19, 10 August 2021 (UTC)
- User:Jochem van Hees: Actually, I probably should've changed the message before I posted it here. The section wasn't about changing it to say "the anchor goes inside the heading with substitution". That was just something one or two people discussed in the section. I don't think it's the right option because it makes the section title a mess. This is something that others brought up in that section too. That wasn't addressed. Also, the documentation should probably be changed back until there's been a proper discussion on the matter. DesertPipeline (talk) 09:06, 10 August 2021 (UTC)
I think the best option would be to get things fixed so that an anchor template (unsubstituted) can be placed right after the heading. Is that possible? Until that time, though, I guess the "substitute inside the heading" option is the best. I don't really like the way it looks, but I'm convinced by the points here, especially with discussion section anchors. I didn't think of that; I was only really thinking of article anchors. DesertPipeline (talk) 13:24, 11 August 2021 (UTC)
- A technical solution is needed, although I have no idea what. The point is that all solutions are bad but some magic and yet-to-be-invented wikitext might provide a better solution. For example, a new "anchor" parser function might be capable of inserting given anchors at the current position, except that if that position is just after a heading, the anchor would be inserted in the heading. Currently, substing in the header is best. Johnuniq (talk) 02:12, 12 August 2021 (UTC)
- Please don't bake-in an anchor into the heading text itself. We lose the ability to click the little arrow in the edit history to get the change. Edit summaries fail to follow the edit history in that case. It works a lot better when header text is not intertwined with anchor. (This is basically the argument of User:Jochem van Hees.) --Ancheta Wis (talk | contribs) 02:45, 16 August 2021 (UTC)
- Are you talking about using
{{anchor|example}}
in a heading, or using that with "subst:" which gives<span class="anchor" id="example"></span>
in a heading? If the latter, a page demonstrating the problem would be good. Johnuniq (talk) 05:02, 16 August 2021 (UTC)- I'm talking about this very page: this very thread, from User:DesertPipeline 10:08, 3 August 2021 (UTC) to 17:53, 10 August 2021 (UTC). which I tagged with
{{anchor|→plusExample}}
"Please don't bake-in an anchor into the heading text itself ..etc." after 02:12, 12 August 2021 (UTC) —See "→plusExample: click the little arrow to see the text of my reply" in the edit history --Ancheta Wis (talk | contribs) 09:48, 16 August 2021 (UTC)- I saw that and the click seems to work. How is that related to a heading? Is this a riddle? Johnuniq (talk) 10:38, 16 August 2021 (UTC)
- @Johnuniq: If used inside a heading and without substitution, as in
{{anchor|Extra id for section}}
, the → link (found in diffs, page history, contribs, watchlist, recent changes, etc.) is broken. If substituted, as in{{subst:anchor|Extra id for section}}
, the → link works as expected. --Redrose64 🌹 (talk) 21:37, 16 August 2021 (UTC)
- @Johnuniq: If used inside a heading and without substitution, as in
- I saw that and the click seems to work. How is that related to a heading? Is this a riddle? Johnuniq (talk) 10:38, 16 August 2021 (UTC)
- I'm talking about this very page: this very thread, from User:DesertPipeline 10:08, 3 August 2021 (UTC) to 17:53, 10 August 2021 (UTC). which I tagged with
- Are you talking about using
- A new syntax for heading anchors would actually be a good idea in my opinion. I noticed that MediaWiki already sometimes puts anchors in the HTML of the headings automatically, to escape certain characters that are in the heading. I don't know where one would propose a change to the software though. ―Jochem van Hees (talk) 12:42, 16 August 2021 (UTC)
- @Jochem van Hees: There is no "sometimes" about it, and it's nothing to do with escaping certain characters - MediaWiki always puts anchors into section and subsection headings that are after the table of contents (TOC) - otherwise the TOC simply wouldn't work at all. You can use your browser's "View HTML source" (or equivalent) feature to check this - once past the
<div id="toc" class="toc" role="navigation" aria-labelledby="mw-toc-heading">...</div>
, look for the characters<h
followed by an integer in the range 1-6). For example, the HTML for the heading of this section isIf a HTML element has an<h2><span id="Documentation_boldly_changed.3B_some_unaddressed_objections_in_preceding_discussion.2C_however"></span><span class="mw-headline" id="Documentation_boldly_changed;_some_unaddressed_objections_in_preceding_discussion,_however">Documentation boldly changed; some unaddressed objections in preceding discussion, however</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Template_talk:Anchor&action=edit&section=13" title="Edit section: Documentation boldly changed; some unaddressed objections in preceding discussion, however">edit</a><span class="mw-editsection-bracket">]</span></span></h2>
id=
attribute, that is an anchor. Theid=
attribute is valid on all HTML elements, there are no exceptions. The purpose of the{{anchor}}
template is to add extra anchors (using an empty<span>...</span>
element) when there is a possibility that the automatically-generated one might change with time. --Redrose64 🌹 (talk) 20:58, 16 August 2021 (UTC)- Yes I know; that's exactly what I just said. MW automatically puts an anchor in the heading, and in this case to turn ; and , into .3B and .2C. I said "sometimes" because this does not happen when there is nothing to substitute. The reason why I mentioned all this is because maybe in the future with some special syntax MediaWiki could allow editors to put their own anchors in the heading as well, besides only the auto-generated ones. ―Jochem van Hees (talk) 21:09, 16 August 2021 (UTC)
- @Jochem van Hees: There is no "sometimes" about it, and it's nothing to do with escaping certain characters - MediaWiki always puts anchors into section and subsection headings that are after the table of contents (TOC) - otherwise the TOC simply wouldn't work at all. You can use your browser's "View HTML source" (or equivalent) feature to check this - once past the
- Please don't bake-in an anchor into the heading text itself. We lose the ability to click the little arrow in the edit history to get the change. Edit summaries fail to follow the edit history in that case. It works a lot better when header text is not intertwined with anchor. (This is basically the argument of User:Jochem van Hees.) --Ancheta Wis (talk | contribs) 02:45, 16 August 2021 (UTC)
I can only repeat what I posted back in May — Placing the anchor above the section heading is the only "correct" solution ...
.
Substituting the anchor template is A Very Evil Bad Thing – many editors would have trouble seeing the purpose of the div span tag. Having the template remain in the wiki text provides a strong cue to an editor that it is intended to be there as the target of inbound links.
Placing the anchor template on the heading line but outside the heading fails due to technical limitations that will not be solved in this decade.
Placing the anchor template inside the heading (without substituting) messes up edit summaries – although this might just be changed within this decade.
Placing the anchor template below the section heading results in the heading being out of sight after the jump and so is a Fairly Bad Thing, but at least the template is still a template.
So, the only remaining option is as the documentation said before May — Place the anchor template above the section heading — GhostInTheMachine talk to me 18:59, 16 August 2021 (UTC)
- You say that "many editors would have trouble seeing the purpose of the div tag" – well if the anchor is placed above the heading then many editors would not even see the tag in the first place; because it does not show up when editing the section in question. And if someone edits the section above it, then they see only the anchor and not the heading below the anchor, and also probably accidentally put a newline between them. I think that something that has been made very clear by now in the discussion is that all methods of placing the anchor have disadvantages (or are "A Very Bad Thing"), and we have to choose between the lesser of the evils. ―Jochem van Hees (talk) 21:17, 16 August 2021 (UTC)
- Also, I don't get why it is "A Very Evil Bad Thing" that people don't understand what a span tag is for. I don't know about you, but when I see some code that I don't understand, I don't touch it. And you can always just place an explanatory comment below the heading. I have never seen the span tags cause a problem this way before. ―Jochem van Hees (talk) 21:23, 16 August 2021 (UTC)
Quotes in anchors
If the anchor contains quotes, this produces invalid HTML: {{anchor|"}}
currently gives <span class="anchor" id="""></span>
. The quotes should be replaced with "
. ―Jochem van Hees (talk) 12:08, 12 January 2022 (UTC)
- This is covered in Template:Anchor#Limitations. Better to keep anchor names as plain text — GhostInTheMachine talk to me 17:33, 12 January 2022 (UTC)
- Oh. Makes me wonder why that can't be done automatically. ―Jochem van Hees (talk) 21:15, 12 January 2022 (UTC)
- It would be helpful if the template displayed some sort of error message (in edit preview) if the anchor name contained any Bad Characters — GhostInTheMachine talk to me 09:42, 13 January 2022 (UTC)
- Oh. Makes me wonder why that can't be done automatically. ―Jochem van Hees (talk) 21:15, 12 January 2022 (UTC)
search
How can we find links or redirects to anchors? The What links here only gives whole pages. Gah4 (talk) 01:34, 29 January 2022 (UTC)
- @Gah4: Er, it already does. Have a look at this: Pages that link to "Help:Redirect", particularly the entries for Wikipedia:Hard redirect and Wikipedia:Hard redirects. --Redrose64 🌹 (talk) 20:02, 29 January 2022 (UTC)
- I wish to find articles with links to Toyota#Japan and replace the link with Toyota Store (actually 1 of about 6 new names, depending on other factors). How do I find those old links ? The suggestion by Redrose seems to find the articles already changed to the new links but not the old style links that I wish to change. There are thousands of articles linking to Toyota but I suspect only dozens going to Toyota#Japan. Stepho talk 02:56, 30 January 2022 (UTC)
- (ec) Redrose64: I don't think that covers the OP's question. Take Animal Farm which has
{{anchor|moreEqual}}
; this is not used with the article, so in which other article might it be used? I don't think that can easily be discovered. Another use of anchors (and redirects) that can probably not be discovered is in edit summaries, where they are quite helpful. -- Michael Bednarek (talk) 03:00, 30 January 2022 (UTC)- Yes, exactly. (Did you find it from edit summaries?). If I go to Animal Farm#moreEqual and then What links here? it doesn't give what links to Animal Farm#moreEqual, but to all of Animal Farm. Maybe not quite as many as Toyota, but there are many of them. Gah4 (talk) 04:08, 30 January 2022 (UTC)
- There is no means for finding out what links to a page from edit summaries; therefore, there is no means for finding out what links to an anchor from edit summaries. --Redrose64 🌹 (talk) 08:19, 30 January 2022 (UTC)
- Sorry, the problem isn't to find them in edit summaries, someone else asked about that. But the actual question came from searching for Animal Farm#moreEqual, but I didn't say that. So maybe Redrose64 found that from edit summaries. I just want to know what links or redirects to Animal Farm#moreEqual. But maybe others in the future. Gah4 (talk) 11:00, 30 January 2022 (UTC)
- It seems that
insource:/moreEqual/
works, since it doesn't occur anywhere else. That isn't quite general enough, though. It seems thatinsource:/#moreEqual/
doesn't work, even with more qualification. There is no matching of the#
. Gah4 (talk) 11:52, 30 January 2022 (UTC)
- There is no means for finding out what links to a page from edit summaries; therefore, there is no means for finding out what links to an anchor from edit summaries. --Redrose64 🌹 (talk) 08:19, 30 January 2022 (UTC)
- Yes, exactly. (Did you find it from edit summaries?). If I go to Animal Farm#moreEqual and then What links here? it doesn't give what links to Animal Farm#moreEqual, but to all of Animal Farm. Maybe not quite as many as Toyota, but there are many of them. Gah4 (talk) 04:08, 30 January 2022 (UTC)
- (ec) Redrose64: I don't think that covers the OP's question. Take Animal Farm which has
- I wish to find articles with links to Toyota#Japan and replace the link with Toyota Store (actually 1 of about 6 new names, depending on other factors). How do I find those old links ? The suggestion by Redrose seems to find the articles already changed to the new links but not the old style links that I wish to change. There are thousands of articles linking to Toyota but I suspect only dozens going to Toyota#Japan. Stepho talk 02:56, 30 January 2022 (UTC)
- Is this search (using
insource:/"Toyota#Japan"/
) what you wanted? It finds 63 uses of the textToyota#Japan
which should just be links. It is not a "kind" search, so it should probably be limited by a category. Adding a check forInfobox automobile
to the search returns 56 of the 63 results — GhostInTheMachine talk to me 12:02, 30 January 2022 (UTC)- Yes, that is exactly what I want. Thank you very much. Stepho talk 21:56, 30 January 2022 (UTC)
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)
- Heading heights differ between skins. Izno (talk) 15:38, 24 March 2022 (UTC)
- 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)
- Yes, template substituting makes the page source code ugly, let's hope for a better solution. fgnievinski (talk) 18:08, 23 April 2022 (UTC)
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)
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)
- @Umofomia: See #Documentation boldly changed; some unaddressed objections in preceding discussion, however above. --Redrose64 🌹 (talk) 05:27, 12 August 2022 (UTC)
- Thanks @Redrose64; I saw that thread, though the discussion there seemed a bit unfocused, with commenters primarily arguing about the use of
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)
- Thanks @Redrose64; I saw that thread, though the discussion there seemed a bit unfocused, with commenters primarily arguing about the use of