Description: ------------ Because XHTML tag IDs must be valid XML IDs, they are a restricted subset of normal tag parameters. Text- or URI-encoding does *not* generate valid XML IDs. I suggest that the render object have a method (similar to textEncode and urlEncode methods) for encoding XML IDs. Here is a simple valid-tag-generator: /** * Default method to render ID names * NOTICE: This does not generate a unique mapping, simply a valid ID * * @access public * @param string $s the text to render * @return rendered text * */ function idEncode($s) { $s = preg_replace('/[^A-Za-z0-9\.\-_:]+/', '_', $s); // All invalid characters replaced in groups $s = preg_replace('/^([^A-Za-z_:])/', '_\1', $s); // First char must be subset of valid return $s; } Test script: --------------- IDs: 9test .what -this:5 does% Expected result: ---------------- _9test _what _this:5 does_ Actual result: -------------- 9test .what -this:5 does%

Sorry, that's not a useful/valid test script and results. Could you give some wiki code which causes some incorrect behavior?

If I have an anchor (created possibly by a heading name) created from the string "9anchor", and I create a link, using the mediawiki parser syntax, such as [[Name#9anchor]] that is intended to link to that heading, then both the heading generator and the anchor-link generator MUST both come to the same conclusion about what the name of the XHTML id should be. As of now, the XHTML renderer for headers and wikilinks just takes whatever anchor ID is given it and either puts it in the ID field (as in Header) or tries to URL-encode it (as in Wikilink). URL encoding will *not* generate a valid XML ID required by XHTML documents. XML IDs are a separate subset of text than URIs.