Alternate background colors for lines #152
HadrienGardeur
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
@JayPanoz commented on Mon Apr 30 2018
This will be part of the experimental features we may ship in the beta release.
A pure CSS solution has some drawbacks, as demonstrated in issue 18:
line-height
(paragraphs);linear-gradient
is quite heavy, CSS-wise.Possible alternative is something like lining.js, which might bring support to the paged view – right now, I can’t tell.
@JayPanoz commented on Sat May 12 2018
Related: https://twitter.com/Bunker_D_/status/994921740039008256 (sorry, tweet in French)
But you can test the Chrome or Firefox extension.
Unfortunately, I could neither find a repo nor an account so it’s difficult to get insights about this particular feature and its implementation.
Help from @garconvacher to contact the creator of this extension, maybe?
@garconvacher commented on Thu May 31 2018
Oops... I didn't see your request for help before :-/
I'm going to dig.
@JayPanoz commented on Thu May 31 2018
Thanks @garconvacher 🙏
@JayPanoz commented on Thu May 31 2018
Did a super quick test with lining.js and results are obviously a lot better since each line is wrapped in a
<text-line>
element.As you can see, works with pagination.
The main caveat though is that you have to modify the DOM and this can possibly screw the CSS cascade + it takes some time to update when resizing the window – it’s pretty visible, I’d say it’s feeling like 1 second or so.
@garconvacher commented on Thu May 31 2018
(Found this tweet from the developer of the DysAide extension. I send him a PM on Twitter with a link to this thread :) )
@danielweck commented on Mon Jun 11 2018
@JayPanoz
Also, modifying the DOM potentially breaks existing CFI references that are used internally to record bookmarks / annotations.
In Readium "1" there is a mechanism / API to blacklist DOM fragments during CFI "processing" (i.e. when a CFI expression is generated from a DOM location / range, and when a DOM location / range is resolved from a CFI expression). If I remember correctly, blacklisted DOM fragments are effectively ignored from the root down (in their entirety), in other words it is not possible to "skip" intermediary wrapping elements such as
<text-lines>
added by thelining.js
utility library.PS: blacklisted elements are defined via their ID or CSS Selector, and this typically includes well-known items such as the additional HTML markup that can potentially be injected by MathJax.
In Readium2 there is currently no such mechanism at all, ... but then there is no real support for CFI either, yet ;) That being said,
readium-desktop
currently uses a pseudo-canonical CSS Selector (i.e. not just an ID reference) to record the reading location (DOM element), so modifying the DOM in order to implement special reading system features (such as line-by-line highlighting, page-break formatting, etc.) still has a disruptive ; if not destructive ; effect.@garconvacher commented on Wed Sep 05 2018
So, DysAide extension is now Aidodys Free due to a partnership with the Aidodys company.
@JayPanoz commented on Wed Feb 05 2020
This has been resolved during today’s engineering call.
Here are the notes:
So this is out of scope for Readium CSS, and should be handled programmatically.
@HadrienGardeur commented on Thu Feb 06 2020
Instead of closing this issue, could we move it to the architecture repo? I think that all of these discussions are still relevant to our project.
@JayPanoz commented on Thu Feb 06 2020
Ah so I can reopen the issue but not transfer it via the built-in feature.
But someone being an admin in both the ReadiumCSS and Architecture repos should be able to do so.
Beta Was this translation helpful? Give feedback.
All reactions