Bug: Headings containing ALLCAPS words rendered with broken anchors

Headings that contain any words in ALLCAPS will have their "name" anchor incorrectly rendered. This appears to affect all heading levels

Test case

Correct

BROKEN

Also (BROKEN)

Will be rendered as:

<h4><a name="BROKEN"> </a> BROKEN </h4>

instead of:

<h4><a name="BROKEN"> BROKEN </a></h4>

Environment

-- MattPounsett - 27 Aug 2003

Follow up

This is done by design: The named anchor is opened and closed (empty tag) if the heading contains a WikiWord or an acronym. If TWiki wouldn't do that, you would get nested anchor tags, which is not legal XHTML. Example if the acronym topic exists:

<h4><a name="BROKEN"> </a> <a href="BROKEN">BROKEN</a> </h4>

Empty named anchor tags are legal XHTML but is not recommented because not all browsers might support it. What kind of issues do you have?

-- PeterThoeny - 29 Aug 2003

In my case, it's causing aesthetic issues, where the CSS controlling the appearance of named anchors is effectively ignored, since the heading is outside the anchor.

I understand now why this would be done for WikiWords, but why also for acronyms?

If it's also necessary for acronyms, would it make sense to close the anchor part way though the heading? I'm wondering if this would make sense:

<h4><a name="Topic_Containing_ALLCAPS_"> Topic Containing </a> (ALLCAPS) </h4>

-- MattPounsett - 02 Sep 2003

Acronyms can also auto-generate links, e.g. RCS in the Codev web.

-- RichardDonkin - 02 Sep 2003

Perhaps it would be better to check if a link will be auto-generated then, before deciding whether to close the named anchor early?

-- MattPounsett - 02 Sep 2003

The problem seems to me that the CSS is incorrectly specified. Try this instead:

A[href]                 { color: #0080CC; text-decoration: none;}
A[href]:active          { color: #0080CC; text-decoration: none;}
A[href]:hover           { color: #0080FF; text-decoration: underline;}
A[href]:visited         { color: #663399; text-decoration: none;}
A[href]:visited:hover   { color: #993399; text-decoration: underline;}

This tells the CSS renderer to only change the colour of links, not named anchors. If the A tag has both href and name attributes, it will get rendered as specified. Of course, the rendering will be broken for A[name]... but that's life.

Edit: but I would suggest using an "id" attribute in the header instead of using a named anchor, specifically to avoid situations like this. In TWiki.pm, modify makeAnchorHeading as follows:

--- TWiki.pm.old        2004-07-09 18:03:37.000000000 +1000
+++ TWiki.pm    2004-07-09 18:05:05.000000000 +1000
@@ -2279,30 +2279,14 @@
 {
     my( $theText, $theLevel ) = @_;
 
-    # - Need to build '<nop><h1><a name="atext"> text </a></h1>'
-    #   type markup.
+    # - Use id attribute of h[1-6] element
     # - Initial '<nop>' is needed to prevent subsequent matches.
-    # - Need to make sure that <a> tags are not nested, i.e. in
-    #   case heading has a WikiName or ABBREV that gets linked
     # - filter out $headerPatternNoTOC ( '!!' and '%NOTOC%' )
 
     my $text = $theText;
     my $anchorName = &makeAnchorName( $text );
     $text =~ s/$headerPatternNoTOC//o; # filter '!!', '%NOTOC%'
-    my $hasAnchor = 0;  # text contains potential anchor
-    $hasAnchor = 1 if( $text =~ m/<a /i );
-    $hasAnchor = 1 if( $text =~ m/\[\[/ );
-
-    $hasAnchor = 1 if( $text =~ m/(^|[\s\(])($abbrevRegex)/ );
-    $hasAnchor = 1 if( $text =~ m/(^|[\s\(])($webNameRegex)\.($wikiWordRegex)/ );
-    $hasAnchor = 1 if( $text =~ m/(^|[\s\(])($wikiWordRegex)/ );
-    if( $hasAnchor ) {
-        # FIXME: '<h1><a name="atext"></a></h1> WikiName' has an
-        #        empty <a> tag, which is not HTML conform
-        $text = "<nop><h$theLevel><a name=\"$anchorName\"> </a> $text <\/h$theLevel>";
-    } else {
-        $text = "<nop><h$theLevel><a name=\"$anchorName\"> $text <\/a><\/h$theLevel>";
-    }
+    $text = "<nop><h$theLevel id=\"$anchorName\"> $text <\/h$theLevel>";
 
     return $text;
 }

... which is much more compact and much more standards compliant, but won't work on some really ancient browsers (the ones that either don't recognise the id attribute, or won't let you use it as an anchor). But at some point in time, you have to draw the line and say, "your browser must be HTML 4.1 compliant". It's already been out for a five years. Catch up with the 21st Century already

-- AlexSatrapa - 09 Jul 2004

Fix record

The proposed <h1 id="foo"> does not work for Netscape 4.7, <h1><a name="foo"> works in all browsers.

Above mentioned bug has been fixed earlier. TWiki generates now all headings consistently with empty anchor tags. Skin authors should use CSS accordingly.

Example heading with empty anchor tag:

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

Here is the relevant code in twiki/lib/TWiki/Render.pm :

sub makeAnchorHeading
{
    my( $theHeading, $theLevel ) = @_;

    # - Build '<nop><h1><a name="atext"></a> heading </h1>' markup
    # - Initial '<nop>' is needed to prevent subsequent matches.
    # - filter out $regex{headerPatternNoTOC} ( '!!' and '%NOTOC%' )
    # CODE_SMELL: Empty anchor tags seem not to be allowed, but validators and browsers tolerate them

    my $anchorName =       makeAnchorName( $theHeading, 0 );
    my $compatAnchorName = makeAnchorName( $theHeading, 1 );
    $theHeading =~ s/$regex{headerPatternNoTOC}//o; # filter '!!', '%NOTOC%'
    my $text = "<nop><h$theLevel>";
    $text .= "<a name=\"$anchorName\"> </a>";
    $text .= "<a name=\"$compatAnchorName\"> </a>" if( $compatAnchorName ne $anchorName );
    $text .= " $theHeading </h$theLevel>";

    return $text;
}

-- PeterThoeny - 11 Jul 2004