Question

I am getting following strange behaviour with some of our new pages: I am using the standard header construct to a H1 header:

---+ Test

<h1><a name="Test"> Test</a></h1>

I don't understand why this is happening?

Environment

-- PatrickVanDerVeken - 31 Jul 2003

Answer

This is a feature not a bug, and is legal HTML - the idea is that you can write SomePage#Test to link directly to that header within the page, or #Test from the page itself.

-- RichardDonkin - 31 Jul 2003

Hi Richard,

I know it is legal HTML but not desired in my case. At least I should have the option to choose whether the A tags are inserted or not. I am forced to use a site wide CSS stylesheet that redefines A tags. With Twiki auto-inserting A tags all my titles look absolutely horrible. I don't like to see Twiki twisting people's arms to have/get something they didn't ask for.

-- PatrickVanDerVeken - 05 Aug 2003

Sorry that it messes up the formatting - it would have been good to mention that in your initial query... An HTML example attached here would help. In any case, this is implemented in CVS:lib/TWiki.pm but removing it or making it configurable would not be that simple - a CSS stylesheet is the easiest solution. Nobody is twisting your arm here, it's just some markup that you don't happen to like and has an easy workaround - many people find these anchors rather useful for tables of contents.

-- RichardDonkin - 05 Aug 2003

Well, this seems a bug in the browser since the HTML spec says: Usually, the contents of A are not rendered in any special way when A defines an anchor only.

The logical way should be for you to insert some supplementary CSS code inside the TWiki skin you use (gratuitous plug: KoalaSkin allows to add site and web-specific CSS), to explicitely tell that A inside headers should have the normal formatting of headers.

But the real solution should be to have null-sized A tag, such as:

<h1><a name="Test"></a> Test</h1>

Note that the HTML spec says: http://web3.w3.org/TR/html4/struct/links.html#h-12.2

Note. User agents should be able to find anchors created by empty A elements, but some fail to do so. For example, some user agents may not find the "empty-anchor" in the following HTML fragment:

The code is inside makeAnchorHeading in lib/TWiki.pm, and it may warrant a patch request in Codev...

-- ColasNahaboo - 05 Aug 2003

To avoid the problem of anchored header elements being rendered as links use a:link,  a:visited, a:active, a:hover in your stylesheets instead of just a bare a rule. Example:

/* anchors  must be defined in order (link,visited,active,hover) 
   to avoid unpredictable results */
a:link {color:blue; text-decoration:none;}
a:visited {color:purple; text-decoration:none;}
a:active {color:red }
a:hover{color:yellow; background-color:blue; text-decoration:underline;}

-- MattWilkie - 05 Aug 2003

Thanks for the answers. We decided to hack the CSS stylesheet and it looks OK now. However, I agree that an empty A container would be more suitable.

-- PatrickVanDerVeken - 06 Aug 2003

If people can test the empty A container on various browsers (see BrowserIssues for a list) it would be quite easy to change the code to use an empty container. Patches welcome, see PatchGuidelines

-- RichardDonkin - 06 Aug 2003

I've noticed a greater bug with this. If there is an all-uppercase acronym present in the header, it is renedered such that the anchor tag is empty, otherwise the anchor tag wraps the header. This should at the very least be consistently handled.

The problem becomes even worse when using the Gnu Skin because the style sheet causes many browsers render these two cases differently (IE and Safari for example). The headers wrapped with the anchor are rendered with the link color, and other tags are rendered with the default black color.

example:

This:
---++ blah blah ABCD blah
---++ Blah blah abcd blah

Generates this code:
<h2><a name="blah_blah_ABCD_blah"> </a> blah blah ABCD blah </h2>
<h2><a name="Blah_blah_abcd_blah"> Blah blah abcd blah </a></h2>

blah blah ABCD blah

Blah blah abcd blah

-- Lee Taylor - 19 Aug 2003