![[Home]](http://meatballwiki.org/meatball.gif)
BracketedLink
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesBracketed links are enabled on Meatball. See TextFormattingRules.
Both of these work:
[http://www.gnu.org/] and [http://www.gnu.org/ Test] result in [1] and [Test].
Notice that [1] and [1(faked)] link to different places. Perhaps it would be marginally safer if the [1] format could not be faked, so that there is a kind of referential transparency to it. Otherwise someone might check the first two occurances and then be mislead by a later one.
- YAGNI. Don't put effort in something that won't turn up in reality. PeerReview.
WxWikiServer implementation
In WxWikiServer, usemod-style bracketed links are mostly supported.[http://www.gnu.org/ gotognu] works, but [http://www.gnu.org/] doesn't. The latter wasn't implemented because since WxWikiServer transforms all valid urls into links, there's not too much point to it.
The rest of this page holds some of the old discussion on the topic:
My initial objection to such links was that they could be maliciously used to point to bad sites (which could do bad things to your system if your browser has security holes). This could happen without any indication (other than the status bar on some browsers) that the link was not an ordinary one. (Consider if someone replaced DaveHarris's signature with such a bad link.)
If the brackets are displayed in the rendered link, most of my objections go away. While someone could still point to a bad site, there is at least a reasonable chance to notice that the link is different from other links. I expect that normal PeerReview would check out each bracketed link carefully, and quickly remove misleading links. --CliffordAdams
In a similar vein, MoinMoin explicitly prefixes external links with the icon 
with ALT="[WWW] which emits as
<img src="/~jh/moinmoin/img/moin-www.gif" width="11" height="11" border="0" hspace="4" alt="[WWW]">
it also does something similar for InterWiki links.
A few small negatives for BracketLink?""s on local pages. It's common syntax in English/WikiGrammar? to use CamelCase inside a bracketed link ala [DeleteMe: I too like eggs.] or Wireless providers [DoCoMo for instance --jqh].... This causes a bit of confusion for the novice author. It's always better to make the WikiSyntax as close to plaintext as possible.
Second, some people I've talked to really like the ability of bracketed links to get around twisting their sentences ala WikiGrammar?. However, this weakens one part of the way wiki works: readers don't necessarily visit every link, but they certainly read every link. If the link text is a page name, the reader comes to know what pages exist in the PageDatabase. Thus, when later she needs to talk about NTT DoCoMo?, she knows that there is a page called DoCoMo? she can link to.
That is, over time, repeat visitors memorize the various pages on the site. Masking the page names with free text makes this harder.
Third, allowing people the escape of free text to get around the pains of WikiGrammar? may encourage bad page names. After all, you can always just use a BracketedLink to cover up a warty name. (I heard this argument today.)
But, it's not a huge concern. Really, it's way easier to just SmashWordsTogetherLikeSo then it is to use a BracketedLink to get around the WikiGrammar?, so this case won't happen too frequently. (I hope.) -- SunirShah
- The current development code [February 1, 2001] has the local-BracketedLink feature disabled. It will be a default-off option in the 0.92 release. The biggest reason is for consistency with the non-described bracketed links: [BracketedLink] isn't special, so it's hard to see why [BracketedLink some text] should be special. Any sites that disagree can simply change the option. --CliffordAdams