Prevent Kobo from using a popup
outsideMyBox opened this issue · comments
Hi,
I have hyperlinks in my epub that reference another page (they don't have any epub:type attribute). The problem is that they fulfill Kobo's 4 criteria to display the linked content in a popup and I don't want that!
Amongst the reasons:
- the css in the popup is stripped out,
- link in the content doesn't work anymore,
- some of the content may not fulfill the 4 criteria and I want an homogeneous way to display it.
- it's a non standard behavior, especially as there is no epub:type attribute.
Is there a way to disable it?
Thanks.
Keep in mind that our clients work the way they currently do because
- The majority of the time we've deemed that the pop-up is a preferred experience for our users and
- the "footnote" and "endnote" attribute types are not used commonly so applying the pop-ups to a greater set of links was the only way to create the desired functionality.
That said we can offer a workaround that should serve your needs:
to “disable” the footnote popup (when the content otherwise fulfills Kobo’s 4 criteria), simply link to an empty div that is placed just before the element that needs to be linked to. Give this empty div the unique ID that the link goes to.
Given that paragraphs are usually 9+ characters (one of the conditions required for the footnote popup to appear), rather than giving the paragraph the unique ID, create an empty div to link to.
Notes:
This workaround only works if the empty div is outside the paragraph element. If it is placed inside the paragraph, Kobo counts all the characters in the paragraph, rather than in the div.
- If div is inside the paragraph (even with fewer than 9 characters in the div), the popup will still appear (on EPD and iOS).
Tested with spans as well, but it doesn’t work as well: - If span is inside the paragraph (with fewer than 9 characters in the span), the popup will appear on EPD (but not on iOS)
- If an empty span is used before the paragraph, the popup will appear on EPD (but not on iOS)
Seriously though, if you can’t make it opt-in, maybe try to make it opt-out? especially because of
the "footnote" and "endnote" attribute types are not used commonly so applying the pop-ups to a greater set of links was the only way to create the desired functionality.
Which means you’ll have false positives. Without any doubt.
Custom data attributes exist for a reason. It would be a lot easier to add data-kobo-popup="disabled" than implementing this workaround, which honestly feels like “Link your CSS on a tuesday, add your styles the next full moon & invoke Pikachu. If you’re wearing one green and one gray sock it’s done, else you’ll need to spin around four times in your chair.” at first sight.
If you care about user experience, opt-outs should be a must, because having an icon or anything else not footnote being displayed in a pop-up is bad user experience. Please help authors help you achieve good user experience.
I know this is sounding a bit harsh but I’m not willing to drop freaking empty divs in a doc or go the JavaScript nuclear way to get around a half baked feature, because it will very likely have side effects in some other Reading System(s).
This is a horrible behaviour! And I'm glad, that Kobo does not have a big market share in Germany yet. But wait, this is about to change when they take over tolino...
We're making eBooks for 15 major german publishers with an automated production toolchain and cross-links are among the most popular structures in every book.
I could not imagine, how a 1500 word index should be useable when every cross reference is opened in a popup 😳
In the meantime professional publishers adopted EPUB 3 very well and I think the official epub:type attributes are widely known and used in production. Reading systems should respect them and treat them correctly!
@JayPanoz wrote:
I know this is sounding a bit harsh but I’m not willing to drop freaking empty divs in a doc or go the JavaScript nuclear way to get around a half baked feature, because it will very likely have side effects in some other Reading System(s).
+1 for that statement.
While changing the data structure in an automated workflow is quite easy, we won't change to placing empty divs somewhere to work around a bad reading system decision.
Also for what it’s worth, it basically ruins the concept of “Choose your own adventure” books—of course this a niche but well, hyperlinks were almost born for such content.
And here is the type of issue I had to deal with a few months ago.
To sum up:
- “Note de bas de page” implies it is a footnote while it isn’t at all, it’s a bonus section for the digital edition;
- you access the bonus section by clicking/tapping on a floated icon (SVG), the screenshot is what you get with the backlink and oh well it is unstyled in the popup because whatever (so it’s full-width, the user doesn’t understand what’s going on, etc.);
- since there is non opt-out available, I had to hack things in a terrible way, especially as you don’t support
navigator.epubReadingSystemyet or else the publisher’s brand would have suffered.
I don’t know why you Reading System’s guys love to automate things so crudely, it’s not like we had actual shitstorms like CloudBleed or ISPs blocking jQuery for a day, proving you must be super cautious because of dev errors and false positives.
P.S.: I’m obviously pissed but I’m not judging the people, just how this was implemented. To err is human but please take into account it’s been years authors trying to do things well have felt like victims of collateral damage i.e. being punished because others do things badly. Maybe “prevent collateral damage” could be one of your software design guidelines in the future.
We can't commit to any timelines at present but these are all valid criticisms and are looking into this. This was originally implemented several (3?) years ago and a fair bit has changed since then. We'll update here as soon as we have something concrete to share.
@JayPanoz @tofi86 we now have this story logged with our iOS and eInk/Desktop teams. Two questions:
- How would you have these platforms handle a) links (I assume do nothing and b) links that use the ePub attribute "footnote" (I assume pop-ups are acceptable).
- Any issue with the way links are currently handled on Android where no such pop-up functionality exists?
Thanks.
As far as I’m concerned:
-
wanted at least an opt-out mechanism since I understand why you did that in the first place, but if you’re going this way, it’ll probably be better in the long term. I’m personally a huge believer in smart interactions in exchange for good markup e.g. using epub and/or aria-doc attributes but could also apply to using
figure+figcaptionfor instance (where the RS tries to keep the figure with the figcaption).
From experience, I know people will do things because they get those interactions in return i.e. have had trainees doing EPUB 3 only to get pop-up footnotes for instance—and if you're making up for them, they won’t try to improve anything at their level because it works, even if it builds a huge technical debt on your side. -
Must take a look at Android to be sure but as far as I can remember, there wasn't any issue about that. Would be dope if it behaved like @tofi86 described.
If you are going to trigger pop-ups for endnotes: While rearnote has been deprecated in favor of endnote, it will be a while before files using endnote start flowing into the kobo system. It is worth including rearnote in the list of epub:types that trigger a pop up.
Possibly. I'll pass the note on to our Android and iOS teams. Thanks for bringing rearnote to our attention.