Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternate background colors for lines #39

Closed
JayPanoz opened this issue Apr 30, 2018 · 11 comments
Closed

Alternate background colors for lines #39

JayPanoz opened this issue Apr 30, 2018 · 11 comments
Labels
a11y Accessibility-related issues and feature requests Experimental feature Issues about features meant to be experimental at first

Comments

@JayPanoz
Copy link
Collaborator

This will be part of the experimental features we may ship in the beta release.

38626521-112515bc-3dad-11e8-9808-75829c6fb25f

A pure CSS solution has some drawbacks, as demonstrated in issue 18:

  1. it will only work reasonably well in the scrolled view;
  2. we have to claim responsibility for at least the line-height (paragraphs);
  3. you can end up with the same background color at the end of one paragraph and the beginning of another;
  4. I’m unable to tell how much memory and CPU this will consume since 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 JayPanoz added a11y Accessibility-related issues and feature requests Experimental feature Issues about features meant to be experimental at first labels Apr 30, 2018
@JayPanoz JayPanoz added this to the beta release milestone Apr 30, 2018
@JayPanoz
Copy link
Collaborator Author

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
Copy link

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

@JayPanoz
Copy link
Collaborator Author

Thanks @garconvacher 🙏

@JayPanoz
Copy link
Collaborator Author

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.

capture d ecran 2018-05-31 a 10 09 43

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
Copy link

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

@danielweck
Copy link
Member

danielweck commented Jun 11, 2018

@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.

@garconvacher
Copy link

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

@JayPanoz
Copy link
Collaborator Author

JayPanoz commented Feb 5, 2020

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.

@JayPanoz JayPanoz closed this as completed Feb 5, 2020
@HadrienGardeur
Copy link

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 JayPanoz reopened this Feb 6, 2020
@JayPanoz
Copy link
Collaborator Author

JayPanoz commented Feb 6, 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.

@HadrienGardeur
Copy link

Issue moved to readium/architecture #114 via ZenHub

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y Accessibility-related issues and feature requests Experimental feature Issues about features meant to be experimental at first
Projects
None yet
Development

No branches or pull requests

4 participants