participedia / frontend

DEPRECATED - see https://github.com/participedia/api/ instead
MIT License
2 stars 2 forks source link

Internal Links/Anchors Transport to Top of Page #815

Open scottofletcher opened 6 years ago

scottofletcher commented 6 years ago

This is from Robert:

"My specific need for the HTML editor concerns internal links and anchors. In this methods page for "Community Score Card" ( https://participedia.xyz/method/4983 ), all of the footnotes use internal links, but none of them works now. When I click on any internal link on that page, the system just takes me to the top of the page, rather than to the anchor for the internal link.

It's possible that this is now a problem on multiple Participedia pages that use internal links. So I need access to an HTML editor within the Participedia.xyz editing interface so that I can edit those internal links or their anchors, so that they work properly. I expect that other Participedia contributors who have internal links in their pages will also need access to an HTML editor so that they can fix those internal links."

Scott's two-cents: a foot/endnoting tool/hotkey would fix the anchor problem. As far as the internal links directing you to the top of the page, I'm not sure if Robert is referring only to linked notes (ie. the link btwn citations at the foot/end of the page & the in-text note) or links to other PPedia entries (I think this is similar to the problem with content transferred from .net - ie. links to other PPedia content to go .net instead of the XYZ version).

scottofletcher commented 6 years ago

UPDATE FROM ROBERT: "Regarding internal links transporting to the top of the page, it's easiest if you try it yourself. If you go to https://participedia.xyz/method/4983 and go to the end of the first paragraph, and click on footnote one in brackets (it's highlighted in yellow in the attached screenshot), the browser sends you to the top of the page. If the internal link and anchor were working correctly, clicking on footnote one would send you to the anchor, which is the first "Endnote" near the bottom of the page (which reads: "[1] CARE (2013); Gullo et al. (2016)."). The same problem occurs when you click on any footnote on that page.

That problem also occurs when you click on the number of any note in the "Endnote" section. Each of those links is supposed to take you to the corresponding footnote in the text of the article, but none of those links seems to be working properly now."

Scott's 2 cents: I think we knew about this bug already. Anyways, whatever foot/endnote tool we come up with will presumably fix this.

scottofletcher commented 6 years ago

@jesicarson RE your comment on the now closed #816 "unfortunately, the fact that existing anchors don't carry over to xyz is a problem that may take many hours of manual editing (even if we do add a footnote tool or allow html access)... not sure if there's any way to mitigate this. maybe @dethe has an idea? I'm wondering what will take longer - a coded/ automated solution or manual editing of many cases? OR... does it really matter if the footnotes don't link to the reference list? The number is there, and the list is numbered..."

If we can't link them (or if it's going to take hours of manual labour) I think that's fine - a lot of them don't work on .net anyways and I've told a lot of authors to just make sure the in-text numbers correspond to the reference numbers. I've updated all the guidelines to say that as well.

jesicarson commented 6 years ago

Cool thanks Scott. I do think, however that the fact that anchor links currently jump to the top of the page on xyz should be addressed, since that could be annoying for users. @dethe I'm guessing there's no easy way to break all these links, since they're treated basically as hyperlinks on xyz, and breaking all of them may wipe out actually useful hyperlinked content. Not sure if theres an easy fix for this or a way to avoid lots of manual edits?

dethe commented 6 years ago

I can look at what it would take to at least strip non-functional hashtags (the part that goes to a specific part of the page), that might not be a lot of work. I don't think our current body text has anchors around links to jump to.

I have identified an editing widget which should support hyperlinks, need to get a feel for how much time it will take to integrate.

jesicarson commented 6 years ago

thanks dethe.