Template talk:Anchor/Archive 1

Archive 1

Archive 2

How to Use

{{anchor}} provides a convenient template for creating other anchors within documents, however, it doesn't do all work for you. Most of the time, you can use anchor like this: {{anchor|section_name}}. However, section name must contain only A-Z, a-z, 0-9, hyphens (-), colons (:) and periods (.) and must start with an alphabetical character. Thus, a section name like:

==This is a section==

Would be anchored like:

{{anchor|This_is_a_section}}

Here are a few more examples, the most notable caveat being that the period is used in place of the percent (%) to signify character encoding.

==Oh, I know, it's a goose!==
{{anchor|Oh.2C_I know.2C_it.27s_a_goose.21}}
==Æther blast costs 345€
{{anchor|.C3.86ther blast costs 345.E2.82.AC}}

The easiest way probably is to use a sandbox, make a real heading with unicode characters in it, and see how it turns up in your URL.

The best place to place an anchor when you need it to refer to mulitple sections is here:

=={{anchor|Name1}}{{anchor|Name2}}{{anchor|Name3}}Real Name==

While it may seem convoluted, putting the anchors here has two purposes:

1. First, on a section edit, you will be able to edit the anchors (as opposed to putting the anchors right before the heading)
2. Second, almost emulates the regular behavior of section headings.

— Ambush Commander^(Talk) 13:25, August 17, 2005 (UTC)

The parameter is not obligatory anymore. When it is not specified, anchor is used per default. --Eleassar ^{my talk} 10:40, 21 September 2006 (UTC)

template:anchor versus m:wikt:yi:template:anchor

Hi!

=== {{anchor|anchor=chat}}[[wikt:project:IRC|« שמועס »]] ===

generates:‎

« שמועס »

If you look at the source code of the page you will not find any « id » named « chat ». Best regards
‫·‏לערי ריינהארט‏·‏T‏·‏m‏:‏Th‏·‏T‏·‏email me‏·‏‬ 05:55, 9 January 2008 (UTC)

This is because the yi template was setup with a named parameter while the en template uses unnamed parameters, the correct code on is: === {{anchor|chat}}[[wikt:project:IRC|« שמועס »]] ===. —Dispenser (talk) 06:16, 9 January 2008 (UTC)

some interlanguage links

re:‎
Help → commons:template:anchor · Talk

<font id="{{{anchor|anchor}}}" ></font><noinclude>
'''{{ns:help}}''' → [[commons:template:anchor]] · 
[[commons:template talk:anchor|{{ns:talk}}]]

was changed to:‎

<span id="{{{anchor|anchor}}}" ></span><noinclude>
<br clear="all" />
'''{{ns:help}}''' {{ #ifeq: {{urlencode:{{DIRECTIONMARK}}}} | %E2%80%8E | → | ← }} 
[[commons:template:anchor]] · [[commons:template talk:anchor|{{ns:talk}}]]

ar:template:anchor bg:template:anchor ca:template:anchor cs:template:anchor da:template:anchor de:Vorlage:Anker el:template:anchor en:template:anchor eo:template:anchor eu:template:anchor fa:template:anchor fi:template:anchor fr:template:anchor hsb:template:anchor he:template:anchor hu:template:anchor is:template:anchor ja:template:anchor ko:template:anchor ks:template:anchor la:template:anchor mi:template:anchor nds:template:anchor nl:template:anchor nn:template:anchor no:template:anchor oc:template:anchor pl:template:anchor ps:template:anchor pt:template:anchor rmy:template:anchor ro:template:anchor ru:template:anchor sd:template:anchor simple:template:anchor sl:template:Sidro sq:template:anchor sr:template:anchor sv:template:anchor sw:template:anchor te:template:anchor tn:template:anchor uk:template:anchor ur:template:anchor vi:template:anchor yi:template:anchor zh:template:anchor

</noinclude>

because <font ... >...</font> is deprected; the code is identical both at RTL and LTR wikis; best regards
‫·‏לערי ריינהארט‏·‏T‏·‏m‏:‏Th‏·‏T‏·‏email me‏·‏‬ 03:20, 16 February 2008 (UTC)

Firefox 3

Hi, in Mozilla Firefox 3 beta 4, redirections to anchors don't always work correctly. It looks like a bug in Firefox. 4.242.108.207 (talk) 15:48, 21 March 2008 (UTC)

Actually, it's a bug in MediaWiki. I had my user agent switched, and so MediaWiki decided to serve me something for another browser, instead of including a more graceful/standards compliant redirection. 4.242.108.207 (talk) 16:42, 21 March 2008 (UTC)

Clean up error message, please

{{EditProtected}}

Please change:

<div style="background:yellow">[[Template:Anchor]]: too many anchors</div>

to


<div style="background:yellow">[[Template:Anchor]] (or Anchors): too many anchors, 
Maximum is ten</div>

• so people know the ceiling when they bump into it! Thanks // FrankB 15:54, 23 February 2009 (UTC)

 Done Ruslik (talk) 17:55, 23 February 2009 (UTC)

{{editprotected}} Please fix the HTML syntax error introduced in the last edit:

<div style="background:yellow">[[Template:Anchor]] (or Anchors): too many anchors, 
maximum is ten</div

should read

<div style="background:yellow">[[Template:Anchor]] (or Anchors): too many anchors, 
maximum is ten</div>

Thanks. — Emil J. 13:36, 24 February 2009 (UTC)

I second that. There is a missing '>' in the closing '</div'.

Also... could 'div' be changed to span please? Better yet, use {{{1}}} which would be consistent with mediawiki handling (and also trappable with #iferror). -- Fullstop (talk) 17:21, 24 February 2009 (UTC)

Done and done. Also fixed the invalid self-closing spans for when Tidy isn't being used. --- RockMFR 18:35, 24 February 2009 (UTC)

A technical note about this - application/xhtml+xml is not typically used at the present time, so self-closing spans and divs don't really mean what they should mean. It doesn't make a difference on Wikipedia since HTMLTidy is being run on everything, but re-users might not want to do this. --- RockMFR 18:44, 24 February 2009 (UTC)

Good point. Also interesting: Tidy only discards empty spans if they don't have ids. -- Fullstop (talk) 19:12, 24 February 2009 (UTC)

After-heading trick does not quite work

In the article Chevrolet Corvette, I merged two sections and placed an Anchors template in the merged section's heading. I then tried (without saving the edit) replacing

==Future development{{Anchors|C7|Corvette sedan}}==

with

==Future development==
{{Anchors|C7|Corvette sedan}}
 <!-- this blank line recommended, the browser will then position 
      vertically aligned to the heading -->

on Internet Explorer 8 (with and without using its global compatibility list), Firefox 3.0.10, Opera 10 beta, and Safari 4 beta on Windows. When using the Anchor (I typed "#C7" and so on after the "...&action=submit" URL), only Firefox 3 positions the view before the heading line, like clicking a regular heading link would; the other three browsers go below that and don't show the heading. (Safari 4 positions the view after the heading line in both Anchors cases, which surprised me!) --an odd name 01:11, 8 June 2009 (UTC)

Firefox 3.5.2 on a mac had the same behaviour. I think this suggestion should be removed. RobHar (talk) 16:14, 18 August 2009 (UTC)

Done. I've removed the suggestion, and cleaned up the doc while I was at it. -- Fullstop (talk) 23:44, 19 August 2009 (UTC)

Hello. What about this?

=={{Anchors|C7|Corvette sedan}}Future development==

I found that this WORK with Safari 4. --Explorer09 (talk) 12:36, 20 January 2010 (UTC)

But it still screws up edit summaries. Just place it before the heading like most examples do. Happy‑melon 16:26, 20 January 2010 (UTC)

Anchorencode not needed

I just went through my to-do list, and it says: "Tell the editors of {{anchor}} that they don't need {{anchorencode:}} in it."

I remember doing some tests and when using <span id="anchor"></span> I noticed that MediaWiki does the encoding for us. {{anchorencode:}} is only needed when one puts together full URLs. I guess someone else should double-check this before removing {{anchorencode:}} from this template.

--David Göthberg (talk) 01:59, 13 February 2010 (UTC)

Interwiki help request

I've added this template to gv.wiki, and have some trouble using it. It looks as though you can't use this within tables, which is irritating. Does anyone know whether this is true, or maybe I'm just doing something wrong? -- Shimmin Beg (talk) 09:15, 30 March 2010 (UTC)

Works here. Observe links from REDIRECTS to the table List of opera genres. Example: Possenspiel will open "List of opera genres" and position the browser at "Possenspiel". There are many other tables like that, e.g. all of List of Latin phrases, e.g. observe in hoc sensu. -- Michael Bednarek (talk) 06:20, 14 April 2010 (UTC)

Hmm. Those seem to use Template:Section instead, which as far as I can see doesn't call Anchor. I'm not clear on the difference, except that Anchor allows multiple foos and Section doesn't. Maybe I should use Section instead? -- Shimmin Beg (talk) 20:58, 21 April 2010 (UTC)

Usage is confusing (wrong?)

The docs need to be fixed (or would someone please explain what I'm missing). The "Usage" suggests that the following is the recommended procedure (but it seems a bad idea; see below):

==Section title==

{{anchor|foo}}

And the docs specifically say (this seems totally wrong; see below):

For example, ==Heading{{anchor|foo}}== will not work.

When I put the anchor in a line after the heading, a link to the anchor goes to the text after the heading, and the heading is not visible (example: Pesher#Barbara Thiering pesher).

Just above, we see the correct usage, and I noticed another example:

• Chevrolet Corvette#C7 correctly goes to =={{Anchors|C7|Corvette sedan}}Future development==
• WP:EL#registration correctly goes to === Sites requiring registration {{anchors|registration}}===

What is the recommended procedure (anchor in heading line, before heading or after heading)? Johnuniq (talk) 10:20, 28 October 2009 (UTC)

I just did some testing. You are right that it works better to put the {{anchor}} template in the heading, since that makes the browser show the heading, which is what we want. If we put the {{anchor}} template below the heading then most browsers scroll below the heading, which is bad.

The doc currently states that putting the anchor in the heading "breaks links to the normal heading". But that is not true, the normal headings still work fine as link targets. And the table of content looks fine and works fine. Perhaps MediaWiki used to have that problem but have been fixed since then? For demonstration I added the anchor {{anchor|USAGE IS}} to the section heading of this message. And as anyone can test, both #USAGE IS and #Usage is confusing (wrong?) works fine here.

But there is one problem: The edit summary shows the {{anchor}} template, which is a bit ugly. (See the revision history, this edit will look somewhat ugly.) A simple solution is to not use this template, but instead use <span> tags directly. Like this:

== A heading <span id="Your anchor"></span> ==

That's what I use in the pages I make, and it has worked fine for some years now. I find that almost as easy to type as using this template.

So I thinks we should add that recommendation to the doc of this template. That is, don't use this template, instead use <span> tags directly and put them in the section headings.

--David Göthberg (talk) 00:44, 23 December 2009 (UTC)

Thanks for your response, and yes I see that having the anchor in the heading line is ugly when editing (and the docs have been tweaked since my first message). I noticed an edit to WP:EL which used your span trick, although it combined it like this (this is one line just before the heading):

{{{1}}}

And here is a link to the above: WP:EL#AVOID. Directly using html somehow seems unsatisfactory, but it seems to work well. I'm inviting thoughts at VPT. Johnuniq (talk) 08:54, 23 December 2009 (UTC)

What about this?

{{anchor|foo}}

==Section title==

The anchor won't break the title and linking to the anchor will display the title, but editing the section won't show you the anchor. Perhaps the page renderer could be adjusted to produce the code that this would from wikitext that has the anchor below the title? OrangeDog (τ • ε) 12:54, 23 December 2009 (UTC)

Johnuniq: Right, using a self closing <span id="Your anchor" /> is equivalent to using <span id="Your anchor"></span>, both works fine. I just personally prefer <span id="Your anchor"></span>, but people can use whichever they prefer. (The page renderer automatically changes the self closing <span /> to <span></span>.)

OrangeDog: Yes, fixes to the MediaWiki software would be welcome. But it isn't the page renderer that is at fault here, it already handles the template fine. What would help is if the edit summary handles templates in the heading in the same way as the page renderer does. (Well, it is the page renderer that adds the edit summary, but you get what I mean.) But it is very unlikely that the devs will bother to fix this, since it is probably tricky to fix and isn't that much of a problem.

So I suggest people instead use the <span> tags directly.

--David Göthberg (talk) 15:06, 23 December 2009 (UTC)

Self-closing spans do not seem valid according to various HTML documentation. So I added back the </span>s. — Edokter • Talk • 15:26, 23 December 2009 (UTC)

As David tried to explain, self-closing spans are automatically converted to empty pairs by MediaWiki prior to rendering as HTML so this is not a problem and no invalid HTML is produced either way. The only drawback would be the extent to which differences in wikitext confuse editors seeking consistency or trying to comply with the standards! — Richardguk (talk) 15:48, 23 December 2009 (UTC)

How about advising use of the template with subst in section headings, like:
== Example {{subst:anchor|foo}} ==
That way things are kept simple for editors but the template code gets converted automatically to prevent section edit summaries getting obfuscated. — Richardguk (talk) 15:48, 23 December 2009 (UTC)

That would cause the entire template code to be dumped in the header; I would defenitely advise against that. — Edokter • Talk • 16:06, 23 December 2009 (UTC)

It seems there is no accepted and problem-free way of handling anchors. In summary, you can put {{anchor|foo}}:

1. Before the heading (but that fails if an editor moves the section starting with the header line without including the anchor in the preceding line).
2. After the heading (but when jumping to the anchor, the heading is often not displayed).
3. In the heading line (but that gives an ugly edit summary which appears in the history).

The docs now say to use (3) (works well for the reader, and is likely to work after future editing), but I like David Göthberg's procedure and will try it when I next need an anchor. Johnuniq (talk) 00:59, 24 December 2009 (UTC)

I should perhaps clarify: Using <span> tags directly is the well established and problem-free way of adding anchors. While this template is just a typing aid when placing anchors in other places than section headers. But since most anchors go to sections then I think this template should be deprecated, and at the top of its doc we should add an explanation how to instead use <span> tags directly.

--David Göthberg (talk) 01:47, 24 December 2009 (UTC)

I think WP:CSD should give sufficient justification for why this template is not deprecated. :P Happy‑melon 11:24, 26 December 2009 (UTC)

Happy-melon: Huh? What do you mean? I didn't mean we should delete this template. I just meant "deprecate" in the usual computer programming sense: Just add a recommendation to not use this template and instead explain how to directly use <span> tags instead.

--David Göthberg (talk) 14:14, 26 December 2009 (UTC)

Just reading this after noticing issue 3. I agree that of the three options it's the least bad, mainly because it only affects editors and can be fixed with the Delete key, but it's still pretty bad. I imagine editors who are unfamiliar with the template will simply remove it from the page rather than have to deal with it. This will cause page article that link to the anchor to link go to the top of the article and that could be confusing for readers. It's been 5 months since this came up; has there been any progress on fixing this?--RDBury (talk) 06:50, 30 May 2010 (UTC)

add a reason parameter?

If we changed the first line of this template to read <!-- {{{reason|}}} then the user could add a short hidden comment about why the anchor has been added. would that be useful, or redundant? --Ludwigs2 17:05, 9 July 2010 (UTC)

I think it would be redundant/unnecessary in three ways: 1) code in comments doesn't get executed; 2) editors may place reasons in an HTML comment ({{Anchor|pageanchor}}<!-- reason -->); 3) editors may add named parameters ad libitum, without any effect: {{Anchor|pageanchor|reason=linked from Main Page}}. -- Michael Bednarek (talk) 05:13, 10 July 2010 (UTC)

makes sense. ok, scratch the idea. --Ludwigs2 06:39, 10 July 2010 (UTC)

Looking for help

Hello! I'd be happy if somebody could help with this problem. Thanks. bamse (talk) 00:39, 11 January 2011 (UTC)

Couldn't find it with that link. Why not just describe the problem? I'll help if I can.

 —  Paine Ellsworth ( CLIMAX )  23:31, 12 January 2011 (UTC)

It seems the discussion has been archived without being resolved. The correct link now is this one. Hopefully you can fix it somehow. Please feel free to ask if anything is not clear. bamse (talk) 00:01, 13 January 2011 (UTC)

I poseted there as well, but the links do seem to work correctly. — Edokter • Talk — 00:06, 13 January 2011 (UTC)

Not sure whether it is relevant, but I have a small laptop screen and the two images are one above the other. The links don't work for me. Possibly on a bigger screen the images are side by side!? bamse (talk) 01:55, 13 January 2011 (UTC)

I have a big screen and the images are one above the other as well. It may be a browser problem; try it on a different computer. — Edokter • Talk — 11:59, 13 January 2011 (UTC)

Same problem with firefox, IE and opera. Just to make sure, if you click on the "see image" link after "shinogi-zukuri", is the top of your screen aligned with the top of the first or the top of the second image? bamse (talk) 16:37, 13 January 2011 (UTC)

It takes me to the top of the second image in Chrome, but to the first image in IE8. After some investigating, it seems IE and Firefox have a problem with anchors in between floating element; they are always placed on the top of the floating stack, even without the template. I'm afraid I don't have a solution. — Edokter • Talk — 17:05, 13 January 2011 (UTC)

I've moved the image down, so the floating stack is broken up. That seems to work, even thought the images may have some space between them. — Edokter • Talk — 17:16, 13 January 2011 (UTC)

This is my first chance to return. It looks like the problem has been solved by recent edits. I use IE8 and Firefox; both click to the anchors as one would expect them to. Are your browsers now performing the anchor switch as you expect them to?

 —  Paine Ellsworth ( CLIMAX )  23:23, 13 January 2011 (UTC)

Perfect! Thanks a lot to both of you. bamse (talk) 23:50, 13 January 2011 (UTC)

You're welcome! (I'd be glad to take the credit, but Edokter did all the work. <g>)

 —  Paine Ellsworth ( CLIMAX )  08:13, 14 January 2011 (UTC)

Superscript and subscript cannot be used

I have added a note to the template documentation about this template not working with markup code such as  and  (superscript and subscript). [1]

Came across this when retitling a section in Heart rate from "Measuring HR_max" to "Maximum heart rate". [2]

According to Wikipedia:Article_titles#Italics_and_other_formatting this formatting should not be used in titles anyway, but still worth noting.

If I'm mistaken, please correct. (BTW, since reading the above I have changed the anchor tag to <span> as advised, but it didn't alter the subscript not working.) --jjron (talk) 06:50, 10 February 2011 (UTC)

Capitalization

Would be nice if there was an answer somewhere whether the first letter of the anchor name should be capitalized (to upper case) or not. I searched but could not find. Olli Niemitalo (talk) 21:37, 9 February 2012 (UTC)

I don't know the answer, but I do remember that some browsers don't follow REDIRECTs to anchors where the capitalisation differs. I don't see why anchors which refer to lower case entities, in lists for example, should be in upper case. -- Michael Bednarek (talk) 13:35, 10 February 2012 (UTC)

There is no rule regarding capitalization, as long as the link and the anchor match, because the anchor is case-sensitive. — Edokter (talk) — 15:21, 10 February 2012 (UTC)

Therefore my procedure is to use all lowercase: there is no reason an anchor should "look nice" as if part of a sentence, so make it short and simple without capitals and probably without spaces. An anchor is case sensitive on some browsers/systems only (it's not case sensitive on Internet Explorer). Johnuniq (talk) 00:16, 11 February 2012 (UTC)

CSS-hidden anchors

Can the anchor template be made like this

<span id="{{{1}}}" class="anchor" style="display:none">{{{1}}}</span>

<span id="{{{2}}}" class="anchor" style="display:none">{{{2}}}</span>

and so on

In this way users can see the anchors by adding the following text to their CSS subpage:

span.anchor {display:block !important}

jfd34 (talk) 04:13, 12 May 2012 (UTC)

That would also show the text to users of text browsers, and to search engines if they don't handle "display:none". Are we sure this is a good idea? Anomie⚔ 04:28, 12 May 2012 (UTC)

What links to this *here* section?

Is there a good way ascertain which (a) pages or (b) articles currently link to an article section, using its current heading? For many many section headings there must be no in-links. In those cases, one may (with impunity?) replace a section heading without inserting any anchor.

(There are good ways and good ways. I have in mind a method that doesn't require programming but welcome a more general education.) --P64 (talk) 22:52, 24 May 2012 (UTC)

Anchor precedes section heading

What are the decisive problems with anchor placement immediately prior to a section heading? (rather than within a heading) I know that an editor of the preceding section may delete the anchor ignorantly. I suppose that a whole-page editor may rearrange sections innocently and displace the anchor. Any other? --P64 (talk) 22:53, 24 May 2012 (UTC)

One prolific editor said that he sometimes moved sections by editing a section and deleting all of it (copying it to his local clipboard), then editing some other section and pasting the deleted section at the end. He never even saw the anchor that used to be in front of the original section. To me, the problem is the ugliness and surprise factor: if I edit a section and see some weird template at the end (which is an anchor for the next section), that template is just going to worry or irritate me. Suppose I want to add some text at the end of the section: if I put it literally at the end, it will be after the anchor but I will never know that I just broke its functionality. The anchor problem needs to be solved with some MediaWiki fix with special syntax to add anchors on the line immediately after the heading. Johnuniq (talk) 23:15, 24 May 2012 (UTC)

Yeah, that's pretty much it, AFAIK. And that would be a good fix, if we could manage it. — kwami (talk) 23:19, 24 May 2012 (UTC)

0. I agree. Sometimes I wish to put a reference in a section heading but this fix seems more important to me.

1. By the way, I visited to read and enquire because another editor using AWB recently inserted one line whitespace between {{anchor}} and the following section heading. (I asked that editor whether the lack of whitespace is a problem; probably didn't ask clearly.)

---

between lines: anchor text (hyphen/dash, etc)

2. Since then another editor has replaced hyphen with en-dash in the anchor name, from "1950-1970s" to "1950–1970s". I expect this to break any existing section link that uses #1950-1970s (hyphen) --am I right? Those anchors exist only because I was concerned not to break any existing link, when I divided in three with section headings 1950s, 1960s, 1970s!

That concern motivates my preceding enquiry, #What links to this *here* section?. For me, many or most anchors created have this purpose only, to avoid breaking unknown existing links. --P64 (talk) 20:59, 25 May 2012 (UTC)

Yep, that's why we use anchors. For the AWB "fix", you might want to bring that to the attention of the AWB folks. And yes, anchors should not be "fixed" unless they are broken. — kwami (talk) 21:57, 25 May 2012 (UTC)

That's why anchors should use just alphanumerics and perhaps if your really must, a space. You are correct that "fixing" a dash in an anchor will break it, and there is no reasonable way to find links coming in that use the anchor. If you want to mention the article I'll check the "what links here" with a script. Johnuniq (talk) 23:19, 25 May 2012 (UTC)

(reply to Johnuniq) Bermuda Bowl

Last version with hyphen headings 1950s-1970s and 1980s-2000s (hyphens, altho not easy for me to say; perhaps unfortunate AWB did not catch it at this stage?)

latest revision 04:04, 24 May 2012 --AWB used for the preceding revision. If i understand correctly, AWB use would be reported in the edit summary (required by policy?); this visit was prompted by my discussion of the preceding and anchor-fixing was human error, iiuc.

TIA ...

Agreed that anchors should never, ever be "fixed". They should never be visible to WP readers, so there is no reason to "fix" it. And, as pointed out, it breaks the links. It should be undone immediately and reported to the editor and the AWB folks. It is a common and good thing for section headings to have their hyphens fixed and an anchor inserted with the old form so that old links continue to work - all nice and transparent to other users.  Stepho  talk  05:37, 26 May 2012 (UTC)

P.S. Thanks all for great excellent replies once i asked clearly or with emphasis ;-)

I have yet reported nowhere except to the editor because I suspect human error, perhaps this editor's own automation error. (The preceding edit cites AWB.) --P64 (talk) 18:39, 26 May 2012 (UTC)

---

Almost forgot, the white space between the anchor and the section header makes no difference to what is seen by readers. AWB tends to separate section headers from anything else, so we might just have to live with that one.  Stepho  talk  05:40, 26 May 2012 (UTC)

Hey, could we produce an anchor template that generates a section heading? That is, the section heading embedded in the anchor, rather that the anchor in the section heading. Maybe that could avoid some of the editing problems. — kwami (talk) 07:38, 26 May 2012 (UTC)

Then the edit link for the section would try to edit the template. It would also screw up bots and scripts that try to find sections in the wikitext. Anomie⚔ 23:06, 26 May 2012 (UTC)

Help!

I have been trying to get this template to work like it is described on the /doc page. So far, I can only get it to work either above or below a section/subsection title. If I place it within a title, then it does not work. A click on the link will either go to the top of the target page, or it won't do anything at all. This is true for both the vector and simple skins, and I use an IE8 browser. How do I get this to work right?
 —  Paine Ellsworth ( CLIMAX )  02:06, 6 January 2011 (UTC)
PS. By accident I found that the anchor template will work within a section title if the title is a [[wikilink]].

Okay, I've figured out how to make this template work within the section titles for my IE8 and FireFox browsers. (Yes, it doesn't work in FireFox either.) But I still need some help to make sure that we get good cross-browser tests. So, if anybody has a different browser or earlier versions of IE and/or FF, please use the following testcases link to make a brief check of the sandboxed code...

• Testcases page

Then you can return here to leave a quick note of your test result. Thank you very much!

Header and anchor text

(For testing. Header should be visible.)

Of course, there is still the problem cited above that the anchor appears in the editsummary. This might become a big problem when several anchors are used. They would fill the editsummary and leave little or no room for editors to type in the reason for their edit. Is there any way to hide the anchor(s) from the editsummary?

 —  Paine Ellsworth ( CLIMAX )  17:05, 8 January 2011 (UTC)

I tried a couple of skins with IE6 and both links worked correctly. I guess you know that WP:VPT would be the place to get the best info on this.

The two test cases (in Firefox 3.6) worked fine, but changing the space before "anchor" to "<" made the WITHOUT anchorencode fail (WITH worked). Changing that space to an ampersand made both test cases work. Changing it to "&lt;" (four characters) caused the WITH to fail, while WITHOUT worked (the reverse of previous result). I also tried "á" which worked in both cases. It is probably not worth worrying about strange characters.

I like David Göthberg's advice above to deprecate this template and document how to use <span>.

BTW, in your sandbox, instead of using <br> with the "Content...", you can put a line containing <poem> before the text, and a line containing </poem> after. Johnuniq (talk) 03:10, 9 January 2011 (UTC)

Thank you for the tips! specially the poem tag. I used it in the poetry section of my talk page. And thank you for your tests and the input! What do you think about the editsummary challenge? I thought about using template shortcuts, but then we'd eventually have a long list of shortcuts that editors would have to sift thru to see if the one they want to use is not on the list. Not good, nor elegant. I wonder if the markup can place a one-line-up scroller so we could go back to putting anchors beneath section titles? Something like the div style overflow="xxx"? Anyway, it's good to get your thoughts!

 —  Paine Ellsworth ( CLIMAX )  11:07, 9 January 2011 (UTC)

PS. I have summed up the problems as I see them with the Anchor templates here in a deletion discussion on the {{Section}} anchor.

I have not needed an anchor for a while, but the suggestion by David Göthberg above looks best to me: use == A heading <span id="Your anchor"></span> == (that is, deprecate this template). I think I tested it during that earlier discussion (a year ago!) and found it to work well. Using html leaves a bad taste, but if it solves all the problems it might be the best approach. I really hate the edit summary you get when the anchor template is used. Johnuniq (talk) 07:29, 10 January 2011 (UTC)

I try to remember to use them when I rename sections. I used the span tag as you suggested here, where I recently changed the section title. Whether I place it after or before the section title, it doesn't work. Double checked and triple checked, but it does not work. I left it there in case you would like to try your hand. Can't figure what the heck I'm doing wrong. Probably something unsmart <g>.

 —  Paine Ellsworth ( CLIMAX )  23:24, 12 January 2011 (UTC)

Very irritating! In FireFox, the vertical position of the anchor appears to be just under the baseline of the letters in the heading: clicking the link shows the descenders on some characters of the heading, with the letters of the header not visible. Worse still, the link works perfectly in IE6 (i.e. all heading is visible)! This needs to be asked at WP:VPT. Do you want to do that? (I am watching Billy the Kid and will notice if you get it working). Johnuniq (talk) 03:45, 13 January 2011 (UTC)

It appears that the "simple" anchor (html only) is working now... Billy the Kid#People claiming to be Billy the Kid... at least it works in IE8 and Firefox. Perfectly, too, planting me with the section title right at the top of my screen just like it's supposed to. How do you see it, Johnuniq?

The "big" secret is to eliminate the </span> tag, that is, the end span tag. And the lesser secret is that the anchor must be inserted before the section title.
 —  Paine Ellsworth ( CLIMAX )  08:02, 14 January 2011 (UTC)

• PS. Now all we have to do is solve the anchor(s) appear in the edit summary challenge.

Amazing, yes, it also works well in IE6. There is html tidy code which is presumably adding a closing tag to the unclosed "span". I had a quick look at the html code and I think I have accurately shown the relevant bits below. It makes the result seem logical.

# Revision at 07:37, 14 January 2011: wikitext + html
== <span id="People claiming to be Billy the Kid"> People who claimed to be Billy the Kid ==
<h2>
 <span class="mw-headline" id="People_who_claimed_to_be_Billy_the_Kid">
  <span id="People_claiming_to_be_Billy_the_Kid">People who claimed to be Billy the Kid</span>
 </span>
</h2>

# Revision at 07:44, 13 January 2011: wikitext + html
== People who claimed to be Billy the Kid <span id="People claiming to be Billy the Kid"></span> ==
<h2>
 <span class="mw-headline" id="People_who_claimed_to_be_Billy_the_Kid">
  People who claimed to be Billy the Kid
  <span id="People_claiming_to_be_Billy_the_Kid"></span>
 </span>
</h2>

If you use the above span wikitext to create an anchor (i.e. do not use {{anchor}}), then I believe there is no problem with the edit summary. So, the solution is to not use the template? Still, you have discovered quite a few things, so you might crack that as well. Johnuniq (talk) 10:25, 14 January 2011 (UTC)

Not using </span> may appear to work, but is defenitely not accepted practice; you can not rely on Tidy running on any wiki, so if this text happens to be copied somewhere else, this may cause heaps of trouble. — Edokter • Talk — 14:36, 14 January 2011 (UTC)

Well if you like that, then you're going to LOVE this...

That's how I was going to begin this response and show you the code in the Anchor template, but it looks like you beat me to that one and the Visible anchor, as well. <g> What's the deal on external links and the Anchorencode? Removing it won't break some external links, will it? I know that's a pretty big deal when moving pages and leaving redirects behind. These are transcluded and not substituted, so...

 —  Paine Ellsworth ( CLIMAX )  15:28, 14 January 2011 (UTC)

Anchorencode is ment to format anchors for external links only. Since {{anchor}} is by default not an external destination, using anchorencode is pointless. — Edokter • Talk — 16:02, 14 January 2011 (UTC)

Ahh - okay, it's over my head and you da dokter.  —  Paine Ellsworth ( CLIMAX )  16:24, 14 January 2011 (UTC)

Well, it looks like we're back to square one; although, I wonder if it matters within a section title. Tidy would still spot it and add the /span back in, though. That's interesting how using just the html keeps it out of the edit summary. We just need to figure out how to hide templates in the same manner— maybe span them externally?

 —  Paine Ellsworth ( CLIMAX )  16:24, 14 January 2011 (UTC)

Actually that does work. Spanning the anchor externally keeps the anchor out of the edit summary AND the anchor works like it should. However... the external span shows up in the section title. Still workin' on it, boss.

 —  Paine Ellsworth ( CLIMAX )  16:52, 14 January 2011 (UTC)

This template is simply not very suitable for use in headers; and perhaps it is actually better to use {{visible anchor}} in this case, like this: == {{visible anchor|Header and anchor text}} ==. See how that works. — Edokter • Talk — 17:37, 14 January 2011 (UTC)

Of course that does not solve the edit summary problem (it will always display the template). If you are going to use span, always use it in this form: == <span id="anchor"> Header </span> ==. That way, it does not rely on HTML Tidy, and should work in all browsers. — Edokter • Talk — 17:46, 14 January 2011 (UTC)

It works in IE8 and FireFox. This would get pretty complicated if the anchors are multiple. We'll just have to stick with these templates and hope that editors read the Limitations section of the /doc to rm the Anchor text from the edit summary before typing in their rationale. Seems less than elegant.

 —  Paine Ellsworth ( CLIMAX )  09:56, 15 January 2011 (UTC)

OK, so this edit by Edokter has fixed the anchor. The link Billy the Kid#People claiming to be Billy the Kid now works for IE6 and FireFox. Using the span html in the wikitext (not the template), there is no ugly stuff in the edit summary. Like all good solutions, this one looks pretty obvious in retrospect. Here are the results as above:

# Revision at 17:42, 14 January 2011
== <span id="People claiming to be Billy the Kid"> People who claimed to be Billy the Kid </span> ==
<h2>
 <span class="mw-headline" id="People_who_claimed_to_be_Billy_the_Kid">
  <span id="People_claiming_to_be_Billy_the_Kid">People who claimed to be Billy the Kid</span>
 </span>
</h2>

Johnuniq (talk) 01:18, 15 January 2011 (UTC)

Yes, thank you to Edoktor! It's a good solution for those who learn it and only need to add one anchor or so. But I don't think it's something we want to add to the /doc. I'll work on it.

 —  Paine Ellsworth ( CLIMAX )  10:05, 15 January 2011 (UTC)

I have seen people use span as an anchor (no idea how common it is), so I think there is a good case to document the proper use of span, including the fact that it is the only known method of avoiding the ugly edit summary problem. Of course we would prefer a "wiki" solution. The major problem with the span technique is that other editors may have no clue what it is for—when a template is used, an editor can check the template and its documentation to see its purpose. A workaround would be to add an html comment, but that is mega-ugly in the wikitext. Probably some form of MediaWiki enhancement is needed. That won't happen any time soon. Johnuniq (talk) 01:04, 16 January 2011 (UTC)

The span is briefly described at WP:ANCHOR. I see it as a good, useful bandaid. The overworked bug squishers might be able to come up with something.

 —  Paine Ellsworth ( CLIMAX )  03:37, 16 January 2011 (UTC)

Seems like there is no way to keep it from appearing in the edit summary? One could put the anchor just below the heading, but then there is a slight offset in the browser window. 174.56.57.138 (talk) 14:10, 24 August 2012 (UTC)

Question: using anchors to link to a specific area of long discussions

Is it permitted to insert anchors:

• In the middle of someone else’s (very) long dissertation on a talk page?
• In a closed wiki-discussion such as a closed wp:RFA, wp:AFD, etc. ?

thnx in advance, Ottawahitech (talk) 20:07, 15 November 2012 (UTC)

For the long dissertation, it's best to avoid changing someone else's text. Very modest changes like indentation level are accepted if it makes things clearer (usually applied to new editors), so I guess adding an anchor would be passibly acceptable. I would avoid it if possible and would put a comment just next to it saying that you added it (specifically including your user name in the comment). But this is just my opinion, not official policy. If the original editor complains then remove it and apologise with grace.

For a closed discuss, I would be very, very reluctant to change anything at all.  Stepho  talk  04:18, 16 November 2012 (UTC)

Multiple anchor ids in the same location?

I'm confused why anyone would want to make an anchor point with more than one id. Is this only for multi-lingual usage? If so, why not just use one anchor wrapped in a {{lang}} or {{int}} or whatever it is to internationalize words on the wiki? Thanks for any explanation.— T13   ( C • M • Click to learn how to view this signature as intended ) 13:52, 4 March 2013 (UTC)

I'm not aware of any multi-lingual use for multiple anchors, but I've used multiple anchors occasionally, i.a. in List of Latin phrases, e.g. to create anchors for the terms "exempli gratia" and "e.g." to make the REDIRECTS exempli gratia and e.g. land at the same spot in List of Latin phrases (E). -- Michael Bednarek (talk) 15:17, 4 March 2013 (UTC)

Okay, I can see having two IDs if one is an abbreviation or acronym for the other but up to ten? I suppose if it is a term that may abbreviated multiple ways. Like, with your example if I wanted to catch more people trying to find that spot (The anchor is poorly positioned with your example, the top line of the description is off the top of the page. Perhaps that table should have the first column top-aligned instead of middle aligned OR the anchor point should be followed by a <br />?), then I could set it to {{anchor|exempli gratia|example given|eg|e.g.}}? That is enough for me to create a similar template on my wiki. Since I can see up to four different IDs, I can justify using the mw:Extension:Loops function #forargs: to allow for any number of anchor points. — T13   ( C • M • Click to learn how to view this signature as intended ) 16:49, 4 March 2013 (UTC)

Putting arguments on their own line "can" work...

In the Limitations section it says "Unlike with most templates, putting each anchor name on separate lines, for example:

{{anchor

|humpty
|dumpty}}

will not work as expected." This is can be made to work on any wiki that has the mw:Extension:StringFunctions installed. On the wiki I administrate, I just created a Template:Anchor using the following code: {{#fornumargs:arg|value|<span id="{{#replace:{{#var:value}}|&#13;|}}"></span>}} and it works just fine with IDs on their own lines. — T13   ( C • M • Click to learn how to view this signature as intended ) 17:30, 4 March 2013 (UTC)

it could work here also, but with added expense by adding more parserfunctions (e.g., {{trim}}). Frietjes (talk) 18:44, 4 March 2013 (UTC)

moving anchors inside headings

I'm moving anchors inside headers, and have had one complaint (after several days and several hundred articles) about it messing up edit summaries. Any progress on that front? — kwami (talk) 06:22, 21 June 2011 (UTC)

A second complaint, due to it messing up the links on the history page. Should we warn that the template is disfunctional? Or do we live with the history links not working? — kwami (talk) 13:09, 21 June 2011 (UTC)

I have not looked at the particular complaints you mention, but it's likely I would agree with the complainers that "anchors inside headings" produces ugly side effects for editors. I have not done any work requiring anchors for a while, but last time I looked the only good solution appeared to be to not use the template.

The best way to make an anchor appears to be this:

== <span id="example anchor text">An example heading</span> ==

There is lots of discussion above, for example see my comment with timestamp "01:18, 15 January 2011".

Deprecating this template and including a note explaining the span trick seems best. However, the problem with systematic replacement of the template with span code is that one day (we hope) a solution will be found (fix template? new MediaWiki feature?), and if the current template is retained, it can be found with "what links here" and adjusted to make any solution work. The people at WP:VPT may have some ideas.

Using span has another problem, namely that editors won't understand its purpose, and there is no link for them to learn that it is an anchor. Including a hidden comment ("this is an anchor (with link to explanation)") would be too ugly. Johnuniq (talk) 01:56, 22 June 2011 (UTC)

IMO, an ugly edit summary is just tough luck for us: functionality for the reader tops convenience of the editor. But one of the objections was that the arrow link on the history page for section edits does not take you to the section if there's an anchor in the header. I had never used that before, but evidently some editors do. Still, it seems to be an editor-convenience issue, though this time made permanent in the page history. — kwami (talk) 02:03, 22 June 2011 (UTC)

How bout we use the span trick, but place a dummy anchor below it? S.t. like {{anchor|Dummy anchor for maintenance. Do not remove.}} We could get a bot to replace all header anchors (once they're placed in the headers manually), though we'd need to figure out what to do when headers have 15 of anchors, which a few do.

Do we need the <h2> stuff, or is the span tag in the header sufficient? — kwami (talk) 02:23, 22 June 2011 (UTC)

I see the point that the problem may just be tough luck, but it is more than "I don't like the look of it". The result can fill the edit summary box so the choice is to leave a useless edit summary (too short), or to manually replace the /*...*/ section text in the summary which is too tricky. Also, history pages become harder to follow.

A dummy line below the heading with info and a link might be helpful, but some editors hate clutter and upsetting good editors is not helpful (and conversations about WP:OWN would make it worse). I could live with it, although maintenance is tricky, and a guideline would be helpful (what happens if editor A wants the maintenance line, and B wants to remove it?).

The <h2> is not part of the wikitext (the "see my comment" discussion was a bit misleading because it is actually showing the html of the page source that results from using the span in the wikitext. I have to warn again that I have not used span enough to know if problems are likely, but the "best way to make an anchor" example above is all that is needed. Not sure what to do for multiple anchors. Johnuniq (talk) 02:36, 22 June 2011 (UTC)

We also have cases such as Glossary of contract bridge terms where spanning is used outside headers (just use "\<span id" in the search window), which should perhaps be converted to anchors if we want them all accessible from here. — kwami (talk) 02:41, 22 June 2011 (UTC)

How bout we just add s.t. like Category:Articles which use span tags for section anchors to the articles when we replace the anchors? I don't know how we'd keep them with the section if we split an article, though. — kwami (talk) 03:51, 22 June 2011 (UTC)

I assume that I am the single complainer that kwami mentioned (since I complained on his talk page). I don't like the span method because it is over complicated for editors that are not familiar with the fine details of HTML syntax. This is even more true when you want multiple anchors on a given heading.

== <span id="anchor1"><span id="anchor2"><span id="anchor3">An example heading</span></span></span> ==

John pointed out on kwami's talk page that putting {{anchor|anchor1|anchor2|anchor3}} before the heading is a case of when, not if, it gets broken during a rearrangement of sections. I contend two points: 1) the anchor name is usually pretty similar to the heading text and is just above the section line (possibly with a blank line). The hope is that most editors will see that they belong together, hopefully making the risk low. 2) Complicate spans will confuse less experienced editors enough that they might corrupt it, change the anchor text instead of the section title or simply remove the spans. To me, the probability of less experienced editors ruining the spans is much more likely than the probability of an {{anchor|anchor1}} and its section being separated.

It seems that all of us agree that anchors after the heading is no good, so I won't say anything more about that. And it seems that most of us agree that anchors in the heading make the edit summary history really, really ugly. It seems to me that no solution is without fault, but that putting anchors on the line before the heading is the simplest and least risky method. Of course, if the wiki syntax can be changed to cope with anchors inside the section heading, then I would embrace that with open arms.  Stepho  talk  05:57, 23 June 2011 (UTC)

I am one of those editors who would corrupt anchors placed above a header. I would never see it, because when I edit a section, I only open that section. When moving a section, I might open the entire article if it's short, but for long articles—including most of those well-developed enough for anyone to bother with anchors in the first place—I generally open the section to be moved, delete it, open the section where I want it, and paste it. That would leave the anchor stranded. Likewise, when I move a section to another article, I open it, delete it, and paste it in the new article, leaving the anchor stranded in the old article. I don't know of any specific case, but presumably nearly every time I've moved a section anchored in this way, I've corrupted the anchor. It seems to me that anchors belong in the section they anchor. — kwami (talk) 07:11, 23 June 2011 (UTC)

There is no good solution, and a technical fix is needed (I agree with all points made above). In principle there could be a proposal at WP:VPR, but I suspect it would not be productive. We need to interest someone who has done MediaWiki development (or at least, who has watched development). Johnuniq (talk) 07:43, 23 June 2011 (UTC)

Damn, that's a usage pattern I hadn't thought of (I always open the entire article when shifting/deleting entire sections). I will have a good think over this.  Stepho  talk  07:50, 23 June 2011 (UTC)

Thought I had it by making a single {{Headinganchor}} template that did both the section heading and the anchors. It was looking good (section rendered well and even appeared in the contents) until I noticed that the edit link for that section was not there. See User:Stepho-wrs/test#section6. I guess the edit links are made by scanning for '==' within the page text BEFORE any templates are done but the contents table is made AFTER. :( Oh well, back to thinking...  Stepho  talk  09:27, 23 June 2011 (UTC)

Got the edit link back with a tweak to the template but now it tries to edit the template instead of the article section. I think I need to sleep before I try again.  Stepho  talk  09:34, 23 June 2011 (UTC)

I took it a step further and created a template Template:HA that allows different levels of heading. Yes, it has the same section edit link problem, but I can live with that if it means there is no problem with edit summaries, getting the heading to display when linked tthrough, and making sure eidtors keep the anchor with the heading. Dovid (talk) 19:50, 10 October 2013 (UTC)

HA

Putting the anchor on the line before the related heading is guaranteed to break links in some articles in the future. Editors will move sections around, and while I can't give an example, it seems highly likely that a "before the heading" anchor will not be moved with the heading in a significant number of cases (and it could be quite hard to work out how to fix the problem a few months after the section was moved). You can always put a tedious html comment on the heading line ("remember to move the anchor if you move this section"), but that is ugly and would only reduce, not eliminate, the problem. The span tag suggested below seems the only workable method to associate an anchor with a section header. Johnuniq (talk) 00:49, 21 January 2010 (UTC)

Use template HA ("heading anchor"), which will generate the anchor and the heading, which means the section and anchor will ALWAYS have to move together. {{HA|4|New third level heading|Old third level heading|Additional ancient headings}} Seven anchors max. Second parameter is heaidng level, and automatically adds one more equal sign (a first level heading in WP is two equals, etc., as per normal WP rules.) Dovid (talk) 19:37, 10 October 2013 (UTC)

great, so now we have more forks, {{Headinganchor}}, and {{HA}} ... why no at least merge {{headinganchor}} and {{HA}}? Frietjes (talk) 19:51, 10 October 2013 (UTC)

Wrong assumption, not a fork. Headingacnhor serves a simpler purpose, it is good for top-level headings, and does not require the heading number as a parameter. HA is more flexible, but more complex, requiring the editor to put in a heading level, and know the syntax. Headinganchor could be re-implemented as a call to HA, but that would be the most you could do to "relate" them instead of leaving them completely independent. Dovid (talk) 01:39, 13 October 2013 (UTC)

okay, I will nominate both for deletion. thank you. Frietjes (talk) 16:42, 13 October 2013 (UTC)

Wow, you really have it in for itm don't you? Personally, I'm sick of seeing the awful edit summaries, so it comes down to choice. Dovid (talk) 19:19, 15 October 2013 (UTC)

As the creator of Headinganchor, I'm happy for it to be deleted as a failed experiment. Clicking on the edit link takes you to entirely the wrong place and is likely to cause havoc wherever it is used.  Stepho  talk  23:44, 13 October 2013 (UTC)

Positioning

If this template is added below the section header, then the header title is above the view window and can't be seen. This is often fixed by putting the anchor above the header, but this disconnects the markup from the applicable section.

I added a relative move to the markup in {{anchor/sandbox}}. This moves the page down enough that the header is visible. If the anchor is above the header, it moves above the anchor, but the header is just down a bit more, thus is it backward compatible.

And if the anchor is near the bottom of the edit window, then there is no apparent move.

I did the same for {{shortcut}} three years ago, but never thought to do {{anchor}}.

Examples:

• Template:Anchor/testcases2#e: uses the current version, section header is above the view window.
• Template:Anchor/testcases2#m: sandbox version, header is visible
• Template:Anchor/testcases2#z: sandbox version, header is near the bottom of the page, so no visible move

--  Gadget850 (Ed) ^talk 20:31, 21 April 2013 (UTC)

Why isn't it working for me? Except for the last case, the screen lands on the first line of Lorem ...

Latest version of Chrome, nor does it work with IE7 (which I never use), but it does seem to work with an older version of Opera 9.50.

Any reason why I shouldn't change the heading names to reflect their letter designation? I think it would be helpful to see that we actually land where we expected to land.

I like this idea, though, 'cause it does sort of suck to have stuff outside the section.

—Trappist the monk (talk) 21:30, 21 April 2013 (UTC)

I was thinking the same thing Trappist about changing the section names to be more identifiable without having to hit edit. That being said, it does seem to work for me with FF20 in Vista. Technical 13 (talk) 21:43, 21 April 2013 (UTC)

Testcases updated. IE fix added. --  Gadget850 (Ed) ^talk 22:38, 21 April 2013 (UTC)

Hmm, still no joy with Chrome.

—Trappist the monk (talk) 00:19, 22 April 2013 (UTC)

Lots of stuff about Webkit (Chrome/Safari) and position:relative. I will keep looking. --  Gadget850 (Ed) ^talk 01:13, 22 April 2013 (UTC)

Thank you for this; works here with FF20 and IE8, and with Chrome 28-dev. -- Michael Bednarek (talk) 05:20, 22 April 2013 (UTC)

Works for me with FF20+Win7 and IE8+Win7. Very happy with the change and can hardly wait to shift all the anchors to just below their section headers.  Stepho  talk  05:59, 22 April 2013 (UTC)

Still not working with Chrome 26, which probably means that Safari has the same issue. This isn't a showstopper, and I will keep looking for a fix. --  Gadget850 (Ed) ^talk 11:10, 22 April 2013 (UTC)

Don't forget to apply what you find to {{Shortcut}} as well as it is likely also suffering the same issues. Technical 13 (talk) 12:14, 22 April 2013 (UTC)

Already considered it. Also considering putting the markup into a common template, as I need this for yet another template. --  Gadget850 (Ed) ^talk 12:48, 22 April 2013 (UTC)

Confirmed that this works with Chrome 28. Does not work with Safari 5.1.7. --  Gadget850 (Ed) ^talk 20:18, 22 April 2013 (UTC)

Immediately below a section header, any of the following is likely to be inserted --without less than usual attention to context, I believe, because they do not display anything between heading and text.

• blank line
• comment
• image

Will the proposed solution survive such insertions (if the image is displayed at left or right margin)?

Anchor position

I have moved Paine's comment below from Module talk:Anchor to keep the discussion together. — Mr. Stradivarius ^{♪ talk ♪} 04:04, 31 December 2013 (UTC)

To Mr. Stradivarius: Much time was spent as shown on the template's talk page to get the template to work properly if installed just below section headers instead of directly within section headers. The code that worked can still be found at Template:Anchor/old, and it works well on the testcases shown on the template's talk page. Not long after all that, {{Anchor}} began to use this module to do its job. There are still the same problems, though, that come from installing an anchor directly within a section header, so I am curious if there is a way to incorporate  Gadget850's handy improvement that automatically lowers the page so that the header is seen even if the anchor is installed below the header? – Paine Ellsworth ^CLIMAX! 02:58, 31 December 2013 (UTC)

@Paine: I can see an immediate problem with using a <div>...</div> tag for this: it splits up text if used in the middle of a paragraph, as you can see in this revision of my sandbox. I'll play around with adding the code directly to the anchor's <span>...</span> tag and see if that does the trick. — Mr. Stradivarius ^{♪ talk ♪} 04:04, 31 December 2013 (UTC)

I've updated Module:Anchor/sandbox to use code like this:

<span style="position: relative; top: -3em;"><span id="anchor1"></span><span id="anchor2"></span></span>

This is working well in Firefox, but as was said earlier on the page, it is not working in Chrome. @Gadget850 and Trappist the monk: Any news on getting this to work for webkit browsers? — Mr. Stradivarius ^{♪ talk ♪} 04:37, 31 December 2013 (UTC)

I haven't revisited the issue so no news from me.

—Trappist the monk (talk) 11:39, 31 December 2013 (UTC)

The sandbox version works with Firefox, but not IE11 or Chrome 31. --  Gadget850 ^talk 13:35, 31 December 2013 (UTC)

I have the image of "peeking Jimbo" on my user page that is preceded by the following code:

<span style="position:absolute;top:-50px;left:-150px;z-index:-1">

Would an "absolute" position work better than a "relative" one? or does "absolute" just indicate that it is from the TOP of the page? – Paine Ellsworth ^CLIMAX! 14:36, 31 December 2013 (UTC)

position:absolute;top is in relation to the top of the page. position: relative; top: -3em; means to move relative to the current position. --  Gadget850 ^talk 14:59, 31 December 2013 (UTC)

Thank you,  Gadget850! Is it possible that the equivalent number of "48px" would work better than "3em" in some browsers? and what does that "z-index:-1" do? Is that what puts ol' Jimbo beyond the margin of the content and into the left frame with the Wikipedia logo? – Paine Ellsworth ^CLIMAX! 16:34, 31 December 2013 (UTC)

z-index specifies the stack order on the z-axis, i.e. front to back. If there are multiple elements with the same positioning, -1 pushes the specified element back one. And yes, px is probably better than em, but it isn't the fix. Monobook uses em positioning and I reused some snippets of markup at the time. --  Gadget850 ^talk 17:03, 31 December 2013 (UTC)

Thank you again, Gadget850! I hope a fix is found soon – I just had a recent run-in where there were numerous broken links that needed fixin'. – Paine Ellsworth ^CLIMAX! 05:20, 1 January 2014 (UTC)

An absolute position is not necessarily calculated from the top of the page; the spec for the position: property shows that it's specified "with respect to the box's containing block". On a Wikipedia page, the containing block for both a section heading and the paragraph(s) that follow it is normally the next <div>...</div> outwards - the one with id="mw-content-text". That div begins below the page heading, the text "From Wikipedia, the free encyclopedia" and the text "Jump to: navigation, search" (if visible). But it's not a good idea to calculate the position of a section heading with respect to the upper left corner of that div, because several factors - not least of which is the user's screen width - conspire to defeat any useful calculation. --Redrose64 (talk) 20:07, 1 January 2014 (UTC)

I was trying to keep this simple. --  Gadget850 ^talk 20:18, 1 January 2014 (UTC)

Thank you, Redrose64! Yes, I found that out with t&e while playing around experimenting with Peeking Jimbo. Gadget850's idea works in most browsers; can't we implement it now and tweak as we go? There are a lot of anchors out there that need to stop breaking things! I just made a revised anchor comment to go with it. Feel free to make it better. – Paine Ellsworth ^CLIMAX! 04:22, 2 January 2014 (UTC)

Nothing is happening here, so I am dropping this and unwatching. Anchors are placed either in or above the section heading and it looks like we aren't going to change it. --  Gadget850 ^talk 13:42, 8 February 2014 (UTC)

To Mr. Stradivarius and to Gadget850: Apparently, at least in some applications, an anchor cannot be placed within the subheader because it will interfere with the various bots used in the project. And as you know, to place it above the section header has its own problems, also. Placing the anchor below the subheader and enabling it to move the page just a bit seems the best way to go. So I don't understand why "nothing is happening here". We seem so close to a solution, and we need to find a way to fix this. – Paine Ellsworth ^CLIMAX! 13:32, 9 February 2014 (UTC)

It appears the issue is that Chrome will optimize out the no-content <span><span></span></span>. When there is some content in the span:

<span style="position: relative; top: -48px;z-index:-1;"><span id="testcase1-below">&nbsp;</span></span>

it does the trick (i.e. adding a   within the span). This does not work with just " " as the content, but &nbsp; does work. Test cases:

• Only current anchor [See table of links below]
• Current anchor and sandbox equivalent
• Current anchor, sandbox, and sandbox with &nbsp;

If at some point they optimize this out, we can try with a one pixel transparent gif. Makyen (talk) 10:38, 12 February 2014 (UTC)

I did not notice it until after my post above, but the   option causes a one character right shift in the text following the anchor. I tried a few ways to get rid of it, but did not find anything acceptable (i.e. short and easy). Thus, I suggest going with a one pixel transparent .gif. [[File:Pix.gif]] appears appropriate. The code is:

<span style="position: relative; top: -48px;"><span id="testcase2-below"></span>[[File:Pix.gif]]</span>

I have updated Module:Anchor/sandbox to use this method.

A variety of test cases:

Go to an anchor

Case	Anchor/text relative to the section heading
Current {{anchor}}	(  in  |  above  |  below  )
Previous {{ Anchor/sandbox }}:	(  in  |  above  |  below  )
Previous {{ Anchor/sandbox }} +  :	(  in  |  above  |  Below—> text same line , new line , \n commented out  )
Previous {{ Anchor/sandbox }} + :   [[File:Pix.gif]]:	(  in  |  above  |  below  )
Current {{Anchor/sandbox}}:	(  in  |  above  |  Below—> text same line , new line , \n commented out  )

This method results in the text on the same line as the {{anchor}} being right shifted 1 pixel. If the {{anchor}} is on a line by itself then the following plain text line is right shifted by a character (there is an actual " " added after the last </span> in the delivered HTML). If the newline after the anchor is commented out, the right shift is only 1 pixel.

If this method is adopted, the 1 pixel transparent .gif file, [[File:Pix.gif]], should probably be copied to a different file and the new file protected to the same level of protection as the anchor template and module (i.e. don't just usurp the current image for this use, make a protected copy for {{anchor}}). Makyen (talk) 07:41, 13 February 2014 (UTC)

I know some lists which use hundreds of anchors; wouldn't the use of an image, however small, add some not negligible processing load for the server and the client? -- Michael Bednarek (talk) 12:29, 13 February 2014 (UTC)

Modern browsers will download the first instance and then use that local copy for the other instances that use the same filename from the same web address. It won't put a drain on the servers.  Stepho  talk  13:08, 13 February 2014 (UTC)

The zero-width space appears to do what is required without the 1px shift: try <span id="anchorname">&#8203;</span> and see if that works. — Mr. Stradivarius ^{♪ talk ♪} 14:17, 13 February 2014 (UTC)

Please don't use a one-pixel gif, that is an outdated hacky method. I've even got a HTML 4 textbook from 1997 (17 years ago!) that advises against. --Redrose64 (talk) 15:02, 13 February 2014 (UTC)

The one pixel gif is hacky, but it generally works (particularly with older IE versions). Even with newer browsers it is a reasonable hack vs. using a text element because you are more likely to be able to know exactly where the gif is located due to it being guaranteed to be only one pixel (prior to any zoom). This is not the case for text elements which could be assigned to other fonts, sizes, etc. by the user. However in this case, we don't need to know exactly where it is, just mostly where it is.

I have changed Anchor/sandbox to use ​. In testing with IE8 I noticed a need for the entity to exist within each of the inner <span> tags. That has been put into the module. While I am aware that IE8 compatibility is not a priority, I don't feel we should toss it out when the cost to be compatible is relatively low.

In testing with Firefox I found that the use of pixels for the relative offset did not position the text as desired when using the "Zoom Text Only" mode. I have changed the module back to using em for specifying the offset. This is compatible with the zoom capabilities of the three browsers I have tested (FF27, Chrome32, IE8).

The single page of test cases was getting a bit unwieldy so I broke it into individual pages The navigation is now:

In testing with IE8 I found that it did not see the first anchor (the in case) on the 8203-B, gif, and current module cases. I did not come up with a quick and easy solution to this, nor even a 100% repeatable diagnostic. Given that it is IE8, I am ignoring this issue, assuming that testing indicates it does not occur on newer IE versions) I may look at this a bit more, but unless I find something reasonably quickly, I will consider this to be cost != low. Obviously, if it is a problem on newer IE versions, then it needs to be solved.

At this location the most recent windows machines are running XP. Thus, I am unable to test with IE(9|10|11) from this location. I would appreciate someone testing the following with newer IE versions:

1. That the newer versions of IE correctly position near the section header for the above three cases. Actually, the "current module case" is the only one of those three that is relevant. (Note: text being visible above the section header is expected.)
2. That the newer versions of IE correctly position the section header to be completely visible in all the "below" cases for the "Current {{Anchor/sandbox}}" set: text same line , new line , \n commented out.
3. That the newer versions of IE have no strange positioning issues of surrounding text in all the "below" cases for the "Current {{Anchor/sandbox}}" set: (same links as #2)
4. Testing the above at a couple of different zoom settings. Should work (it does in Firefox, Chrome, and IE8).
5. I would be interested to know, but it is not a needed test case, if there is any difference in the 8203 "span #A (w/o entity)" (text same line , new line , \n commented out) and "span # B" "below" (text same line , new line , \n commented out) cases. On IE8 there is a difference (the span #A (w/o entity) cases position with the section header not fully visible). This issue, at least for IE8, is already accounted for in the module code, but I am curious. If no one looks, I will try to remember to look when I am elsewhere (not soon).

In Firefox and Chrome, all of the newer cases work correctly for positioning the page with the section header fully visible when the anchor is below the section header. It would be good if other people would verify this just to check a wider variety of system configurations. We only need to test the "Current {{Anchor/sandbox}}" set, but the others should work.

Some test cases with various combinations of multiple anchors using Module:Anchor/sandbox are still needed. I'll see if I can work some up later.

Should test using other skins: I can run through the ones available under preferences on the three browsers I have available here.

Makyen (talk) 00:47, 14 February 2014 (UTC)

I just tested the current {{Anchor/sandbox}} in my IE10. When the anchor is placed below a header, the sandbox still takes me to just below the header. Also, the current sandbox leaves whitespace between the header and its text that the current {{Anchor}} template does not leave. – Paine Ellsworth ^CLIMAX! 03:18, 18 February 2014 (UTC)

Template-protected edit request on 15 December 2013

When there are more than 10 items, it will generate the following code:

<span class="error">[[Template:Anchor]] (or Anchors): too many anchors, maximum is 10.</span>

which will produce:

which does not make any grammatical sense at all.

I, kc_kennylau, request that the code be changed to:

<span class="error">Error: too many [[Template:Anchor|anchors]], maximum number of anchors is 10.</span>

so that it would produce:

This change keeps the link to Template:Anchor and makes more sence.

Moreover, I suggest that a page be categorized if there are too many anchors, that means changing the code to:

<span class="error">Error: too many [[Template:Anchor|anchors]], maximum number of anchors is 10.</span>[[Category:Pages with too many anchors]]

--Kc kennylau (talk) 08:37, 15 December 2013 (UTC)

I think the message is clear enough. This should never happen anyway. I'll shorten it somewhat, as it is ususally embedded in a header. — Edokter (talk) — 11:19, 15 December 2013 (UTC)

is what I personally like. Technical 13 (talk) 13:02, 15 December 2013 (UTC)

How that shows in H2:

Some Header with an anchor

We need to totally rethink this. — Edokter (talk) — 14:22, 15 December 2013 (UTC)

I just implemented {{anchor}} in Lua: see Module:Anchor. No need for any error messages, as Lua can generate an unlimited number of anchors. Would anyone mind me converting the template to use the new module? — Mr. Stradivarius ^{♪ talk ♪} 15:07, 15 December 2013 (UTC)

I see no problem per se, I just can't imagine anyone using more then ten anchors. (I also need to learn LUA really bad.) — Edokter (talk) — 15:26, 15 December 2013 (UTC)

Well, me neither, but I just get the itch to convert stuff to Lua if I ever see errors like this one. :) Also, I made some test cases at Module:Anchor/testcases (run tests). — Mr. Stradivarius ^{♪ talk ♪} 15:31, 15 December 2013 (UTC)

Ok, I've switched to the Lua version. Let me know if you spot any issues at all. — Mr. Stradivarius ^{♪ talk ♪} 06:16, 20 December 2013 (UTC)

Edokter: I can't either. But as I'm sure you know, "I just can't imagine anyone doing X" is near the top of the list of famous last words befor

Thnidu (talk) 06:22, 26 February 2014 (UTC)

Answers to Edit Summary questions...

1. this isn't BibTeX
2. not a "minor formatting change"
3. some got broken
4. what exactly was wrong with it?

per edit summary of Redrose64 (contribs • talk) 16:34, March 29, 2014

• To answer your questions:

1. bibtex is the closest thing to wikitext and is useful for showing formatting of such and is fairly commonly used as such in multiple pages.
2. None of the context was changed, it was all the same visible wording in the resulting page, therefor it was just a formatting change, one I considered minor.
3. I previewed multiple times and did not see anything "broken" could you please expand?
4. There were multiple {{tlx}} in the source code that would have broken any attempted use and the wall of text style code with no formatting or highlighting made it difficult to read.

I hope this answers your questions, Rose and once #3 is figured out, I don't see any reason to not put back the formatting changes so that the section can actually be read. — {{U|Technical 13}} ^{(t • e • c)} 15:50, 29 March 2014 (UTC)

Here's your change. On the very first paragraph, you changed The {{tlx|anchor}} template to The {{Anchor}} template which caused it to not display. There, and in several other cases, you changed "anchor" to "Anchor" - unnecessary changes to first-letter capitalisation has got other people blocked before for disruptive editing. You added three <br /> for no apparent reason. Reformatting the whole section onto more lines than it had previously been on is certainly not a "minor formatting change" - it is major.

I will grant you "There were multiple {{tlx}} in the source code that would have broken any attempted use"; but I have already fixed those. --Redrose64 (talk) 16:06, 29 March 2014 (UTC)

• Rose, I actually did a regex replace to replace all tlx|a with just A using WikEd and then went back and tried to make sure that all of the ones that really should have been tlx were, I apparently missed that one and appreciate you finding it. There is no rule against capitalizing the first letter of a called template (since all page names are capitalized in the database anyways) as long as it is not the only change, since it was part of a larger change, it is acceptable. The <br /> I added were to prevent inappropriate word wrapping and improve readability. minor or major is an ambiguous term (and apparently we disagree on what constitutes either) but the point is that is was still just a formatting change. — {{U|Technical 13}} ^{(t • e • c)} 16:52, 29 March 2014 (UTC)