Opera doesn't like url-encoding in <a name>

[claus]

It seems that relative Urls like

file:///C:/ghc/ghc-6.9.20080514/doc/libraries/base/Data-List.html#v%3Ahead

don't work with Opera (9.51, windows). Or, rather, the urls do work if the corresponding 'name' is not url-encoded but not if it is. I don't know whether that is an Opera issue - for Internet Explorer, the situation seems reversed (the url works if the 'name' is url-encoded but not if it isn't).

I'm surprised by this incompatibility, but haven't yet found any relevant info. If there is no other workaround, haddock could perhaps generate both encoded and un-encoded names?

[claus]

my reading of (the second note in)

http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.1

is that this is an opera issue. I've reported it as a bug (bug-354488), but the opera bug tracker seems to be a closed system (visible to employees and collaborators only), so I have no idea what they are doing about it, if anything.

Since haddock relies intensively on these relative URLs for cross-referencing, it is rather annoying not to have this working. I'm reasonably sure it used to work in earlier opera versions, as my haskellmode plugins for vim use this for documentation lookup.

So, is it wait-for-opera or workaround-and-see? Is anyone reading this bug tracker, btw?-)

[claus]

issue still present in opera 9.52, Build 10108 (windows).

[olsner@…]

The name attribute of an anchor is specified as CDATA, not as %Uri; in HTML 4.01, so the "correct" way to write the HTML is by not uri-encoding in name, but uri-encoding in the href (which definitely is a URI). If characters in the name need (HTML) escaping, they should be escaped like this:

<a NAME="v&#x3A;id">id</a>

(if that works in all the other browsers haddock needs to work in...)

It is also possible that "everyone-else-does-it" will require Opera to change back to the previous behaviour (apparently Opera 9.27 had the same behaviour as the other browsers).

[claus]

Replying to olsner@gmail.com:

Yes, the name attribute is CDATA, but the spec for CDATA has this odd opt-out:

For some HTML 4 attributes with CDATA attribute values, the specification imposes further constraints on the set of legal values for the attribute that may not be expressed by the DTD.

Combined with the appendix B.2.1 refered to above, which has this note:

Note. The same conversion based on UTF-8 should be applied to values of the name attribute for the A element.

It seems clear that URI en/decoding (which is only recommended anyway) is to be applied to the name attribute value as well. However, that recommendation is only for non-ascii characters. In particular, the CDATA spec stipulates:

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").

So, it does seem as if the new opera behaviour is right, at least for ":", technically, and haddock should should follow suit. Unfortunately, the "everyone-else-interprets-this-differently" is an issue in practice.

<a NAME="v&#x3A;id">id</a>

This doesn't seem to work in opera (and shouldn't be necessary?).

It seems that the options are

• generate both encoded and unencoded names

• do not encode ascii characters like ":" in hrefs (but that would break existing cross-references..)

[claus]

Replying to claus:

- do not encode ascii characters like ":" in hrefs (but that would break existing cross-references..)

That may not actually be a good idea, with ":" being reserved.

[waern]

This has been fixed by generating two anchors for each name, one where the name is escaped and one where it isn't.

[anonymous]

Milestone 2.4.2 deleted