Alternate background colors for lines about readium-css HOT 11 CLOSED

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?

from readium-css.

Oops... I didn't see your request for help before :-/
I'm going to dig.

from readium-css.

Thanks @garconvacher 🙏

from readium-css.

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.

from readium-css.

(Found this tweet from the developer of the DysAide extension. I send him a PM on Twitter with a link to this thread :) )

from readium-css.

@JayPanoz

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.

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 the lining.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.

from readium-css.

So, DysAide extension is now Aidodys Free due to a partnership with the Aidodys company.

from readium-css.

This has been resolved during today’s engineering call.

Here are the notes:

• Pushed by associations for dyslexic / dyspraxic people
• Difficult with CSS (because of columns).
• With some time, JS and CSS, we could get something. With the code blocks used for highlighting. - Complexity is when there are images or other complex structures.
• Probably done by others already. Maybe contact Learning Ally, Mobidys.
• Here’s a proof-of-concept: http://jsfiddle.net/Fptq2/4/
• MS Immersive Reader SDK is an interesting solution, but not free. https://www.onenote.com/learningtools

So this is out of scope for Readium CSS, and should be handled programmatically.

from readium-css.

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.

from readium-css.

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.

from readium-css.

Issue moved to readium/architecture #114 via ZenHub

from readium-css.