Samana Johann wroteNot sure about XHTML and dots in anchor or id.
Yes, the same occurred to me. Now I found some info. Reading in the
XHTML 1.0 standard under the heading "C.8. Fragment Identifiers":
, since the set of legal values for attributes of type ID is much smaller than for those of type CDATA, the type of the name attribute has been changed to
NMTOKEN (link inserted by me: referring to a website in German language). This attribute is constrained such that it can only have the same values as type ID, or as the Name production in XML 1.0 Section 2.3, production 5.
/.../
Note that the collection of legal values in XML 1.0 Section 2.3, production 5 is much larger than that permitted to be used in the ID and NAME types defined in HTML 4. When defining fragment identifiers to be backward-compatible,
only strings matching the pattern [A-Za-z][A-Za-z0-9:_.-]* should be used.
Looking at the definition of
NMTOKEN:
Der lexikalische und der Werteraum von xs:NMTOKEN sind die Mengen von »Namenstoken« nach XML 1.0, d.h. Token, die aus Buchstaben, Ziffern, ».«, »:«, »-« und den von Unicode definierten Zeichen wie zum Beispiel »combining« oder »extender« zusammengesetzt sind.
So the dot '.' (and also colon ':') are both explicitly allowed here in XHTML (and even backwards compatible to HTML 4).
The only problem I could imagine might be in JavaScript, especially jQuery code that could be confused by the dots and colons in 'id' query selectors, because dots normally indicate the beginning of 'class' query selectors. (But in standard JavaScript methods at least there is a workaround to simply escape such dots in id selectors with '\\.' - see
https://stackoverflow.com/a/17563341/7048200)
So I guess this was maybe just a measure of extra caution in regards to possible problems with jQuery, maybe without an actual existing case where such might be really necessary.
Samana Johann wroteHow ever, as a dot might be common in headers (1. ..., 2. ...), and as far as perceived before (that there was no "problem" before hidden-plugin), it seems that there must be two renderings, one for the created link and one for the created ID of headers. Not sure if the possible change by the plugin did not left something in the part of rendering the ID of the title behind.
As far as I have seen through the code, the same function "sectionID" is used before rendering anchor links and section ids, making the same kind of transformation removing the dots. And the hidden-plugin also does not change this (This is the complete code:
https://github.com/zioth/dokuwiki_hiddenheader/blob/master/action.php).
The problem already exists without the hidden plugin in the test DokuWiki that I have installed on my computer. It is simply in the "sectionID" function of DokuWiki.
Samana Johann wrote(the solution might be overwritten when upgrade is made, wouldn't it)
Yes, with upgrade of DokuWiki, but not upgrade of Hidden-Plugin, because the problem is in DokuWiki.
I will try to open an issue in
DokuWiki GitHub later and ask why this "sectionID" function removes dots and colons, and if that is really necessary for something. Maybe they come to the conclusion that it is not really needed and change it.
_/\_