X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/ab793c1db08d250b920e16552a4fdf247d66a661..2f765597defb81816ee1f6a6ed041d6c47dd8f7e:/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn diff --git a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn index 699f05500..8e539b6af 100644 --- a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn +++ b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn @@ -1,5 +1,5 @@ I would not be comfortable with merging this into headinganchors and enabling it by -default for two reasons: +default for two main reasons: * it adds a new dependency on [[!cpan Text::Unidecode]] * Text::Unidecode specifically documents its transliteration as not being stable @@ -18,6 +18,9 @@ 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) +> Can we assume Ikiwiki generates HTML5 all the time? I thought that was still a +> setting off by default... --[[anarcat]] + 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 @@ -36,16 +39,51 @@ So perhaps we could try this Unicode-aware version of what Pandoc documents: an unused identifier (Or to provide better uniqueness, we could parse the document looking for any existing -ID, then generate IDs avoiding collisions with any of them.) +ID, then append `-1`, `-2` to each generated ID until there is no collision.) This would give us, for example, `## Visiting 北京` → `id="visiting-北京"` -(where Text::Unidecode would instead transliterate, resulting in `id="visiting-bei-jing"`). +(whereas Text::Unidecode would instead transliterate, resulting in +`id="visiting-bei-jing"`). To use these IDs in fragments, I would be inclined to rely on browsers supporting [IRIs](https://tools.ietf.org/html/rfc3987): ``. --[[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]] + +---- + +Documentation says: + +> _Also note that all heading attributes are overriden with the ID tag. If this +> is not desirable, we'd need to fire up a full HTML::Parser or do some more +> regex magic to preserve the attributes other than id= which we want to keep._ + +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. + +> 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]] + +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 +the right solution to that is to send a bug report / feature request to +make its IDs as good as this plugin's, or turn off ID generation in the +htmlize layer, or stop using Text::MultiMarkdown. + +--[[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]] + ---- 
Some long scrollable text
@@ -90,3 +128,5 @@ supporting [IRIs](https://tools.ietf.org/html/rfc3987): `