Template talk:Anchor

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)

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,

|- id="Foo"

becomes

<tr id="Foo">

The {{anchor}} template emits one or more empty <span>...</span> elements, so

{{anchor|Foo|Bar}}

yields

<span id="Foo"></span><span id="Bar"></span>

What you're suggesting is doing it like this

|- {{anchor|Foo|Bar}}

but that becomes

<tr <span id="Foo"></span><span id="Bar"></span>>

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>...</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)

Template-protected edit request on 24 September 2020

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)

 Done * Pppery * _{it has begun...} 22:33, 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)