Using self-links for the reiteration of an article title, guarantees, by dint of the configuration of Wikipedia, that the article will conform to Wikipedia's style convention, even if that convention changes - which is reason enough in itself for this self-link usage.

There can be no doubt from any general reading[1] nor from W3.org's advocation as a general principle the paradigm of Separate structure and presentation that statements such as "if you want bold then mark it up as bold", goes against this universally accepted paradigm.

Wiki markup is a structural markup language, much like HTML. It would seem common sense to follow such a reliable source as the W3.org in it's recommendation of this paradigm which includes giving markup semantic properties allowing user agents to decide how to actually display those tags; the obvious examples being the strong tag displaying as bold and the emphasis tag dispalying as italic, unless you have a visual impairment, when a screen reader gives that text a strong emphasis or just an emphasis.

Naive word processor users will often create headings by manipulating the low level functions of font size and bold effects to make a heading in their document, instead of using the structural markers of heading levels.

They don't realize the advantages of computer systems handling of text documents can be enhanced by structuring them. Using heading levels gives a document structure, so that an automatic table of contents can be generated, as can be seen in Wikipeadia articles where heading levels are used for this purpose; it also happens that these heading levels are conveyed to humans by bold and bigger fonts, but the sole purpose is to give the document structure.

As naive word processor users will manually apply font effects for headings because they fail to realise that what they really want is document structure, so it has been Wikpeadias practice to signify an article title's first mention by applying font effects, instead of with some sort of markup which signifies the meaning: "first mention".

A markup specific to first mention could be included in the syntax for a wiki, but this seems a little extravagant! An efficient method is already built into MediaWiki, when the software encounters a wikilink (a link defined in wikimarkup) which points to it's own page it becomes not a HTML hypertext link, but HTML plain text given a semantic mark by the use of the CSS class attribute - I happen to think this is both good error catching, and a pleasingly elegant touch to turn this user "error" into a useful feature. This method was widely used until ill-informed (I strongly suspect!) debate and the pressure from admins who do a lot of page-moves "outlawed" the practice, and then bots where employed to scour out this use of wikimarkup.

Mark the first mention by a structural/semantic markup, not by a display format markup. In fact do anything but markup with display formatting! To markup with display format tags is the antithesis of the paradigm, it is anathema.

Disadvantages

edit
For editors
  1. It is inefficient for editors who move a page; they have to re-jig the wiki-code.
  2. If the article name is not exactly the same as the bold text, then it means more typing when creating an article, due to the need to create a piped link.
  3. Novice users will be confused by this means of making things bold.

But how much inefficiency is there really? These are really quite thin.

  • Page-moves are not so common that cognisance should be given to them at an articles inception. Wiki-code usage for the whole of Wikipedia should not be determined because of a page-move some articles might make at one time.
  • If you really can't be arsed making a piped link, then don't bother, let someone else do it - it's not compulsory!
  • If you know how to link then you know how to self-link, but don't worry if you're confused, just mark it as bold, let someone else do it - it's not compulsory!
For users
  1. If the page-mover doesn't tidy up, it is inefficient for the user; they're left with a link which loops back.

Assuming a page-move takes place on an article with a self-link - and who knows just how often that is likely to be - and the editor leaves the self-link as is - a typical surfer isn't going to be put off by a funny link, they'll have seen and got around much worse, and the vast majority will take it in their stride. Even if an editor makes a mistake, another comes along and fixes it.

edit

User changes to nav-box display have been cited as a reason for not using self-links, these users have already created their own CSS file with a minimum of;
strong.selflink { css display commands }

Which will display all "self-links", anywhere in the page, as they desire them to look in the nav-box (table). There is an easy CSS way to make sure that the display change only happens within tables, and not anywhere in the page.

Nav-boxes are served as tables, so nav-box users need only use either the CSS descendant selector: " ", or the CSS child selector: ">". So that strong.selflink { css display commands } within a table are displayed as desired.

For the child selector the syntax is;

  • within table data cells;
  • td > strong.selflink { css display commands }
  • within table headers;
  • th > strong.selflink { css display commands }
  • anywhere in a table;
  • table > strong.selflink { css display commands }
  • within both table cells and table headers
  • td > strong.selflink, th > strong.selflink { css display commands }

Replace the ">" with whitespace, and it will catch any descendant, child, grandchild or more. These commands can be used to overcome any so called "side-effects" of using self-links.

Advantages

edit

It guarantees, by dint of the configuration of Wikipedia, that the article will conform to Wikipedia's style convention, for first mention, even if that convention changes - which is reason enough in itself for self-link usage.

It makes it easier for editors who copy part of the lead (as wikicode)

  1. Into a summary article
  2. To explain first mention of a term in another article
  3. To a talk page to support a view

And for each of these situations, the following advantages are gained

  1. They don't have to edit the code to get rid of the bold-face; more efficient.
  2. They don't have to edit the code to link back to the original; more efficient.
  3. It automatically has a link back to the original article; more efficient.
  4. It eliminates errors when linking back; more efficient.

That's 4 efficiency savings multiplied by 3 situations. That's one huge reason, plus a count of 12 efficiency reasons, versus 2 very thin ones. Comparatively arithmetically using self-links wins out.

But how much efficiency saving is there really? How often do editors copy that bit of the lead? Common sense would say that it has to be more often than page moves - which means the 3 to 2 efficiency count in favour of self-links wins out, even if the point-weight on each side is equal. I think the point-weight of each is greater on the 3 side, which would multiply the 3 to a larger number.

Besides my thought that page moves are rare, what gives rise to my suspicion that editors copy that part of the lead more often than an article undergoes a page move?

  1. Summary articles would make a good start that way.
  2. Other articles may quote a portion of the lead when explaining the first use of a term in it's own body text.
  3. In a talk page recently I brought up the definite article, Set (mathematics), & intensional definition to describe my view. I quoted exactly the first sentence of two of those articles, but had to re-jig the wiki-code to provide a link.

If we can make article talk pages more efficient in coming to conclusions, then this will help the efficiency of the whole Wikipedia project - I think this in itself is reason enough for the self-link usage.

edit

The wikimarkup for self-links should be [[page name]], which would be rendered as page name.

A piped link is needed when the page name doesn't match the article title like [[Set (mathematics)|Set]] Set, a piped link is also handy during a page move, only the page name part of the link need be changed.

Do not use [[ {{FULLPAGENAME}} |self-links]] which would work for this page, giving; self-links, but the code couldn't be copied to another page and work as a link back to this page.