proposed reworking; requesting smcv take another look

[git.ikiwiki.info.git] / doc / plugins / contrib / i18nheadinganchors / discussion.mdwn

diff --git a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
index 716fc090280f12aabb80b0e70a2d80b67b41a265..a172e5ac46a2a6e8151fb6271997ec78afc22c3c 100644 (file)
--- a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
+++ b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
@@ -18,6 +18,16 @@ anchor name](#пример) (the output of putting "example" into English-to-Rus
 Google Translate) hopefully works? (Use a small browser window to make it
 clearer where it goes)
 
 Google Translate) hopefully works? (Use a small browser window to make it
 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
 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


@@ -47,6 +57,17 @@ supporting [IRIs](https://tools.ietf.org/html/rfc3987): `<a href="#visiting-北
 
 --[[smcv]]
 
 
 --[[smcv]]
 

+> I guess this makes sense. I just wonder how well this is actually supported in all
+> browsers.. I looked around and suspect this will work in more recent browsers, but,
+> 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

 
 ----
 
 
 ----
 


@@ -60,6 +81,13 @@ I think this is a bug, particularly if you are using Pandoc's
 [header attributes](http://pandoc.org/MANUAL.html#extension-header_attributes)
 or similar.
 
 [header attributes](http://pandoc.org/MANUAL.html#extension-header_attributes)
 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
 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


@@ -69,6 +97,11 @@ htmlize layer, or stop using Text::MultiMarkdown.
 
 --[[smcv]]
 
 
 --[[smcv]]
 

+> Agreed. However, the situation I was in was that multimarkdown *and* the 
+> headinganchors plugins had issues I had to fix. So it was better and easier
+> for me to just override whatever attributes were there for testing and 
+> fixing this in the short term... -- [[anarcat]]
+

 ----
 
 <pre>Some long scrollable text
 ----
 
 <pre>Some long scrollable text


@@ -113,3 +146,5 @@ htmlize layer, or stop using Text::MultiMarkdown.
 .
 .
 .</pre>
 .
 .
 .</pre>

+
+> This works for me on ` Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0` on Debian stretch, FWIW. --[[anarcat]]