Sorry, the double square bracket are messed up when posting here. But I think you get the idea.
Hello Martin,
I think it should be merged, sure. Next release should arrive in october and will bring your change with!
Thank you!
@martinneumannat
Thank you for pointing this issue and for the code!
That was done for v2.0.0 because I considered the lack of actual URL fragment identifiers as a design flaw, but the way I did it backfired, and it needed to be reverted for v2.0.4. See https://ww.wp.xz.cn/support/topic/hyperlinked-footnotes-creating-excessive-back-history/
I made two mistakes:
- I disrupted user experience: Readers were accustomed to click on backlinks because there had been no other way to get back to the referrer they left off at. Suddenly added hard links started overcrowding the browsing history and made the back button unusable. The correct process to avoid UX disruption would have involved three steps:
- Make the hard links optional.
- Add a note at the top of the changelog.
- Optional tooltips on the backlinks suggesting to use the back button instead.
- I kept the lengthy internal IDs and made them show up in the address bar. Basically clicking a footnote appended a bunch of English words (
footnote_plugin_reference_) to any—even localized—URL. I think that normally websites don’t do that. E.g. Wikipedia: cite_note- — shorter, although surprisingly that isn’t localized either. Anyway I was worried but didn’t notice that I myself had made internal IDs public.
Even after correcting those mistakes by adding the ID slugs to the settings and providing a comprehensive guidance both to site owners and visitors, there is still a problem with the lack of scroll offset, causing footnote items and referrers to hide behind fixed headers, and also behind the WordPress admin bar, in case of the JavaScript outage and ban against click (and hover) events required by AMP.
It is possible to solve the offset problem, but the solution seems to be so unstraightforward it is almost never implemented.
Unless we get all these problems solved, the plugins’ quality in AMP mode would be insufficient.
Thank you also for your response in the related, recent topic https://ww.wp.xz.cn/support/topic/footnotes-is-not-amp-compatible/
I’ve marked the topic as unresolved again, until hopefully the feature is supported.
-
This reply was modified 5 years, 5 months ago by
pewgeuges.
-
This reply was modified 5 years, 5 months ago by
pewgeuges.
-
This reply was modified 5 years, 5 months ago by
pewgeuges.
-
This reply was modified 5 years, 5 months ago by
pewgeuges.
-
This reply was modified 5 years, 5 months ago by
pewgeuges.
-
This reply was modified 5 years, 5 months ago by
pewgeuges.
-
This reply was modified 5 years, 5 months ago by
pewgeuges.
@martinneumannat
The overdue optional hard links for AMP compatibility are now released. Current 2.3.0 has an option, that needs to be enabled for the hard links to become actually present in the pages, so nothing changes; yet i missed out on the changelog special message, an unusual first-time i’m not familiar with. Also the rush was really overdue and needed to get out the door ahead of 2021 after thorough testing.
Thank you for your request and code samples, again!
Edit: I’ve just posted in the related recent thread, addressing your advice for tooltips: https://ww.wp.xz.cn/support/topic/footnotes-is-not-amp-compatible/#post-13851995
-
This reply was modified 5 years, 4 months ago by
pewgeuges.