X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/bbf2d13ae325a844d6bda4cb2502c5de2497c5e3..4457c6d570daa85c9c2f663b9a8726d3e78f46b8:/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn?ds=inline

diff --git a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
index 8e539b6af..a172e5ac4 100644
--- a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
+++ b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
@@ -21,6 +21,13 @@ clearer where it goes)
 > Can we assume Ikiwiki generates HTML5 all the time? I thought that was still a 
 > setting off by default... --[[anarcat]]
 
+>> ikiwiki always generates HTML5, since 3.20150107. The `html5` option has
+>> been repurposed to control whether we generate new-in-HTML5 semantic
+>> markup like `<section>` and `<nav>` (`html5` enabled), or HTML4 equivalents
+>> like `<div>` with a class (`html5` disabled). The default is still off,
+>> although I should probably either toggle it to on or remove the option
+>> altogether in the next release. --s
+
 So perhaps we could try this Unicode-aware version of what Pandoc documents:
 
 * Remove footnote links if any (this might have to be heuristic, or we could
@@ -55,6 +62,13 @@ supporting [IRIs](https://tools.ietf.org/html/rfc3987): `<a href="#visiting-北
 > as an example, https://caniuse.com/ doesn't have that feature listed in their 
 > tables. :) -- [[anarcat]]
 
+>> That might well indicate that all major browsers have always supported it so
+>> there is no need to check. I don't see any particular reason why a browser vendor
+>> would not want to accept arbitrary non-whitespace as a valid anchor.
+>>
+>> In practice, minor or old browsers are probably insecure anyway, so I don't care
+>> too much about supporting them perfectly... --s
+
 ----
 
 Documentation says:
@@ -70,6 +84,10 @@ or similar.
 > It's not a bug, it's a limitation. :) But sure, it's a thing. It's an issue in
 > headinganchors as well of course. -- [[anarcat]]
 
+>> No, current/historical headinganchors has a different bug: it ignores headings
+>> that have any attributes, and does not generate anchors for them. That gives it
+>> degraded functionality, but no information loss. I think that's less bad. --s
+
 I think we should try to use an existing ID before generating our own, with the
 generation step as a fallback, just like Pandoc does. If a htmlize layer like
 Text::MultiMarkdown or Pandoc is generating worse IDs than this plugin, the