Open VijayShankar1 opened 5 months ago
hello, it looks like your footnote content is a backlink, which is now excluded by design / intentionally. Could you please share the HTML code of your note content? (or ideally the EPUB to test)
Hi Daniel Weck,
Please find the HTML coding as given below for your reference. Thanks!
The idea of this book originated from reflection about translating the term “public history” into the Polish language. A literal translation (“historia publiczna”) did not ring well in contemporary mainstream Polish, potentially carrying distorting connotations. Because of the way the adjective “public” (“publiczna”) had historically functioned in Polish, “historia publiczna” could connote: lacking intellectual value; aimed solely at mass entertainment; associated with prostitution. The use in Polish academic discourse of the English term “public history” (or other foreign-language borrowings) is barred under the provisions of the Polish Language Act, which also governed the launching of the Masters program at the University of Wrocław in 2014. Moreover, using only the English term would pose the risk of highjacking and/or alienation: people might reject it, without grasping its actual meaning. This is what happened with the word “gender”: when first introduced in its English version, it was publicly reviled, mis-cast, and politized, as something borrowed, alien, strange, and incomprehensible.1 …
Regards, Vijayashankar S
From: Daniel Weck @.> Sent: 01 July 2024 19:08 To: edrlab/thorium-reader @.> Cc: Vijayashankar S @.>; Author @.> Subject: Re: [edrlab/thorium-reader] Endnotes Pop-up (Issue #2478)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
hello, it looks like your footnote content is a backlink, which is now excluded by design / intentionally. Could you please share the HTML code of your note content? (or ideally the EPUB to test)
— Reply to this email directly, view it on GitHubhttps://github.com/edrlab/thorium-reader/issues/2478#issuecomment-2200185210, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZB3JILGTRUEROKSRYAYJ7TZKFLS7AVCNFSM6AAAAABKFM44XGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBQGE4DKMRRGA. You are receiving this because you authored the thread.Message ID: @.***>
Disclaimer: This e-mail and/or attachments are confidential and may also be legally privileged. If you are not the intended recipient, any disclosure, copying, distribution or action taken relying on the contents is strictly prohibited and may be unlawful. If you have received this communication in error, please notify the sender immediately by responding to this e-mail and deleting the contents of the e-mail & related attachments from your system. Though MPS Limited has taken reasonable steps to ensure no viruses are present in this e-mail, it cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments. No contracts may be concluded with MPS through e-mail communication. Please consider the environment before printing this e-mail.
just as I suspected: the HTML link tag ('a' XML element) that carries the 'role' and 'epub:type' attributes with value "backlink" should only contain the hyperlink text, not the actual content of the endnote / footnote. By design, Thorium now intentionally excludes backlinks from popup footnote content. This was a feature request which made a lot of sense, as by its very definition the popup GUI affordance integrates its own backlink behaviour (i.e. returning to the link's originating callsite)
Interesting interpretation, but the use of 'noteref' which creates the footnote behaviour is used for all notes, both endnotes and footnotes. While footnotes tend, but not always, have a leading character in the main element, endnotes should use the automatic numbering feature which only leaves content available for backlinks. Perhaps this is a failing in the structural semantics specification, perhaps there should be an effort to separate footnotes and endnotes.
cc @gregoriopellegrino re. backlink exclusion in popup footnotes GUI affordance
The markup shown looks like an export from InDesign of some past version where the software placed all the note text inside a link. This does not look like good practice to me.
That said a possible solution for @danielweck is to check if there is only the link in the note (in which case don't hide it), or if there is link + text, in which case you can hide it.
backlink links inside popup footnotes are currently hidden with CSS display:none triggered by a simple CSS selector rule. In order to add smart link vs. content heuristics we would need to introduce yet more JavaScript, which frankly seems like over-engineering a solution to a problem that shouldn't exist in the first place :) That being said, I wonder if we could write a CSS selector that ensures that is at least one sibling element next to the backlink (which we could infer as the notes contents )
Would it be easier to only populate the popup when the destination is an @epub:type='footnote'? Then treat other 'noteref' links as regular links?
do you mean to exclude epub:type=endnote, for example?
In effect, yes.
isn't the backlink role allowed on links inside targeted footnote destinations though? (in which case the selective rendering isn't helping solve the problem)
Good question, the short answer is yes, the structural semantics even cites returning from a footnote in the use of a backlink. If all reading systems did footnotes as popups, the backlink we could petition to have backlink dropped in favor of the reader handling the navigation, but that is a way off I fear.
To complicate things, a creative author could have multiple links leading to a given footnote, which could require multiple backlinks exiting the footnote, but I have not seen this in general practice so very much and edge case.
I think backlinks are useful, for example if a person unzips an EPUB and reads it in a browser or in the case of very simple reading solutions.
That said it seems to me that the problem with this issue is not so much the reading solution, but the endnotes exported "badly" by InDesign with all the text rendered as links, which creates problems when there is an external link in the endnote. Fortunately in the latest version of InDesign the export of endnotes has improved.
Endnotes with backlinks give easy navigation back to the main point in text. Selection of parts, or the complete, endnote is common especially when the
in Thorium the content of endnotes / footnotes / rearnotes is hidden by the reading system when they are inside 'aside' elements, IIRC (and only when the popup footnote feature is active) otherwise, when other note HTML containers are used, the content remains visible / reachable in the document reading order.
...and for the avoidance of doubt, the feature named "popup footnotes" should really be called "modal popup contents viewport for notes that are references by hyperlinks with role=noteref" ;)
In the meantime, I am working on a CSS selector that will solve the situation
Came here to see if this issue had been flagged. In our books, endnote links look like this:
<span class="sup"><a role="doc-noteref" href="21_Notes.xhtml#fn2-1" id="rfn2-1">1</a></span>
and the note looks like this:
<li class="note1"><a id="fn2-1" role="doc-backlink" href="09_Chapter02.xhtml#rfn2-1">1</a><span class="spacep"/>Whitehouse, Harvey, <i>Inside the Cult: Religious Innovation and Transmission in Papua New Guinea</i>, Oxford University Press (1995).</li>
There's no
The pop-up functionality is controlled by the epub:type attribute. Your code should be
<span class="sup"><a epub:type="noteref" role="doc-noteref" href="21_Notes.xhtml#fn2-1" id="rfn2-1">1</a></span>
Okay, but your code should still honor the link if the epub:type is not declared, and go to the endnotes. Displaying a blank popup makes it look like there's nothing there, or that something is broken. I mean, this works on every other system. Implementing a functional enhancement with epub:type shouldn't break the function if it isn't there.
there seems to be some confusion in this discussion thread (...but thank you for sharing your thoughts / feedback, much appreciated!)
epub:type="noteref" and role="doc-noteref" are equivalent.
your problem is the backlink role which should be located only on a hyperlink inside the footnote/endnote/rearnote content, the semantics of "backlink" should not be attached to the markup container of the content targeted by the note reference.
PS: could you please share an EPUB that demonstrates the bug, so I can investigate? Thank you.
PS: could you please share an EPUB that demonstrates the bug, so I can investigate? Thank you.
ah, looking closely at your code snippet, your note reference points to the hyperlink, not to the container
href="21_Notes.xhtml#fn2-1"
===>
<li class="note1">
<a id="fn2-1" role="doc-backlink" href="09_Chapter02.xhtml#rfn2-1">1</a>
Hello, for our part we noticed a display problem in the pop-up notes: the note number is not displayed in the new version of Thorium 3.0.0.
Thank you !
Hello, could you please share the HTML markup (and if possible, authored CSS) of the footnote contents?
Hello, here is the HTML code for the note call: 1
Here is the HTML code for the note:
Here is the CSS: .ntb { margin : 3em 0% 1% 0%; font-size : 0.85em; line-height : 130%; font-style : normal; font-weight : normal; text-align : justify; text-indent : 0%; text-rendering : optimizeSpeed; } .texte_note { margin-left : 60px; text-rendering : optimizeSpeed; } .numero { float : left; text-align : right; width : 50px; clear : both; padding : 0px; margin : 0px; text-rendering : optimizeSpeed; } .txt_ssalinea { text-align : justify; text-indent : 0%; text-rendering : optimizeSpeed; }
Thank you
@danielweck thinking about this problem again, I realized that the approach of hiding the backlinks is not the best.
The best solution for notes in popups would be to leave the content of the backlinks (text), but remove the interactivity ( tag).
This thing however cannot be handled with CSS, but should be implemented in the JavaScript that retrieves the content of the note and inserts it in the popup.
What are your thoughts on this?
I realized that the approach of hiding the backlinks is not the best
Can you please explain why this is your pragmatic thinking now? Is it because there exists "broken" markup that place actual note content inside the backlink semantics? If so, the source / authored material is incorrect and it should be fixed.
If Thorium removes the markup that powers the interactive hyperlink (e.g. replace a
with span
, or modify / remove the href
) then the correctly-authored backlinks will look confusing because the text (e.g. footnote superscript number) will just appear before the note content.
I agree that if a content is done badly it is not the reading solution that has to remedy it, at the same time I realized that some times in the backlinks there are significant contents, for example the number of note... Hiding them altogether could deprive the user of some information.
I think the text inside footnote pop-ups is not displayed with the CSS of the epub. I need to emphase some words in footnotes in a specific color ; the only way I have founded to have the result I expect is to specify the color directly in the HTML code ; in the code below the first occurence of 'gouvernail" is with the color directly in the HTML code, the second is in a CSS linked to the HTML file. If this text is not in pop-up (I delete the role and epub attributes ; the HTML code is in the salme context) , the two occurences are green ; inside the footnote popup only the first one is green.
relient l’un à l’autre constitue le gouvernail du navire,gouvernail du navire ou
We are captured the Endnotes in correct coding structure only. However in the new version of Thorium 3.0.0 shows blanks pop-up boxes. It looks like a bug in Thorium reader v3.0.0 but the previous version 2.4.1 the pop-up is working fine. We have placed the Thorium v3.0.0 and Thorium v2.4.1 screenshot for your reference. Thanks!
Screenshot v3.0.0
Screenshot v2.4.1