-Isn't this functionality a part of what [[plugins/toc]] needs and does? Then probably the [[plugins/toc]] plugin's code could be split into the part that implements the [[plugins/contrib/headinganchors]]'s functionality and the TOC generation itself. That will bring more order into the code and the set of available plugins. --Ivan Z.
+Isn't this functionality a part of what [[plugins/toc]] needs and does? Then probably the [[plugins/toc]] plugin's code could be split into the part that implements the [[plugins/headinganchors]]'s functionality and the TOC generation itself. That will bring more order into the code and the set of available plugins. --Ivan Z.
+
+> Indeed it is. Except [[plugins/toc]] generates headings differently - and independently of this. *Even* if [[toc]]'s functionality would be split, you'd probably want to retain backwards compatibility there, so it's unlikely that this will happen... Also see [[todo/toc-with-human-readable-anchors]]. --[[anarcat]]
---
</pre>
--Changaco
+
+> This was applied in 3.20110608 --[[smcv]]
+
+----
+
+I think using this below would let the source html clear for the browser
+without changing the render:
+
+ #use URI::Escape
+ .
+ .
+
+ #$str = uri_escape_utf8($str);
+ $str = Encode::decode_utf8($str);
+ #$str =~ s/%/./g;
+
+Don't you think ?
+[[mathdesc]]
+
+> Older HTML and URI specifications didn't allow Unicode in IDs or fragments,
+> but HTML5 and IRIs do. See also [[plugins/contrib/i18nheadinganchors]]
+> and its [[plugins/contrib/i18nheadinganchors/discussion]] page.
+>
+> I think we should probably try to make these autogenerated IDs
+> punctuation-independent by stripping most non-word characters, like
+> Pandoc does: I would not expect changing
+> `## Headings, maybe with punctuation` to
+> `## Headings (maybe with punctuation)` to have any effect on the
+> generated "slug" `headings-maybe-with-punctuation`. --[[smcv]]