On 31/05/05, John Prieur john2000@ijsolve.com wrote:
(1) use a hidden anchor (as in HTML <a> tags), or (2) use a construct similar to XPointer, but using notation such as == or * to denote nodes. It would be great if this Wiki construct supported regular expressions and nesting.
As already mentionned, the simplest level of this is already available - every heading automatically has an HTML <a> element next to it, and internal links can be constructed to refer to these in the standard way ([[foo#bar]]).
The main problem with this is that in a wiki document, headings are subject to frequent change, so if the anchor is tied to the precise wording of a heading, links will frequently be invalidated (and become links to the top of the page instead). The XPointer-style approach you suggest just makes this more complicated - the regex might remain valid longer, but is still very dependent on the whims of editors, and creating anchors for points other than headings just multiplies the opportunities for links not behaving as intended.
A way round this would be to create some markup for "insert an anchor here" - giving users direct control over the content being a pretty fundamental concept in wikidom. Of course, there's also a *presentation* issue here - if you're dumped in the middle of a paragraph, you could be forgiven for thinking your browser had gone screwy, so it's probably best to stick to only having anchors on headings. Which, in a rather-long-winded-cos-I'm-tired way, is why I like the suggestion at http://bugzilla.wikimedia.org/show_bug.cgi?id=1521 to allow alternative anchors to be defined manually for a heading - which would allow invisible "sticky" anchors to outlast the wording or even *structure* of sections.