Bug: Heading isn't included within <a name...> </a> HTML tags if text contains 3 or more successive caps

A bizarre bug this, but one that is annoying in the context in which I am using TWiki. It is best illustrated by the test case shown below.

The reason why it is annoying is:

• We are using bold blue for links within TWiki docs changing to red-underline on hover. This is the corporate style.

• This bug variously renders the text either in blue, if enclosed within the <a name...> tag, or black if it isn't. So, the end-user sees a mixture of blue and black headings in topics: blue so long as a heading contains fewer than 3 consecutive capital letters, and black if it contains more than 3!

Ideally, we'd like the style of the text at each heading level to be defined purely by the corresponding <h1>, <h2>, <h3>, etc, tags. Instead, it is arbitrarily being defined by the <a name...> tag or by the <h?> tag.

Test case

(The colour has been added manually to represent how the text appears on our TWiki site)

The following heading is included fully within the <a name...> </a> tags and hence takes its formatting from the <a> tag:

This is an included heading

The corresponding HTML code generated by TWiki is:

    <h3><a name="This_is_an_included_heading"> This is an included heading </a></h3>

This next heading is excluded from the <a name...> </a> tags and hence takes its formatting from the <h3> tag.

This is an EXCluded heading

The corresponding HTML code generated by TWiki is:

    <h3><a name="This_is_an_EXCluded_heading"> </a> This is an EXCluded heading </h3>

Environment

TWiki version:	Athens (Dec 2001)
TWiki plugins:	Default, Smilies, Interwiki
Server OS:	SuSE Linux 8
Web server:	Apache
Perl version:	5.6.1
Client OS:	Win2k
Web Browser:	IE5.5

-- RichardLewis - 01 Oct 2002

Follow up

This topic would be better named "InconsistentHandlingOfHeadings".

Having delved into TWiki.pm I've found the following in sub makeAnchorHeading :

    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\(])([A-Z]{3,})/ );
    $hasAnchor = 1 if( $text =~ m/(^|[\s\(])([A-Z]+[a-z0-9]*)\.([A-Z]+[a-z]+[A-Z]+[a-zA-Z0-9]*)/ );
    $hasAnchor = 1 if( $text =~ m/(^|[\s\(])([A-Z]+[a-z]+[A-Z]+[a-zA-Z0-9]*)/ );
    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> $theText <\/h$theLevel>";
    } else {
        $text = "<nop><h$theLevel><a name =\"$anchorName\"> $theText <\/a><\/h$theLevel>";
    }

    return $text;

The purpose of this code is to ensure that the subroutine doesn't accidentally create illegal nested <a> statements. However, it also introduces the heading handling inconsistency described in this bug report.

The simple solution I have adopted is to set $hasAnchor = 1 at all times, ensuring that headings always sit outside of the <a> </a> tags and therefore take their formatting from the appropriate <h> tag.

Incidentally, although the comment in the subroutine says that an empty <a> tag is non-HTML conformant this doesn't seem to be true in HTML4 - at least not according to w3.org (see http://www.w3.org/TR/REC-html40/struct/links.html) which merely states:

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:

<A name="empty-anchor"></A>
<EM>...some HTML...</EM>
<A href="#empty-anchor">Link to empty anchor</A>

-- RichardLewis - 08 Oct 2002

---

I ran into the same problem when I installed the GnuSkin skin (the version compatible with BeijingRelease), since that skin uses a style sheet setting that colors all links. The result is just as described above--very disconcerting.

-- MarkBearden - 17 Mar 2003

---

Fix record