Provide styles for epub:type="pagebreak"

JayPanoz commented 6 years ago

See https://github.com/edrlab/readium-desktop/issues/20

Not sure this can be the job of CSS though as it is kinda simplistic (a 5-minute implementation) and I’m unable to list all the possible issues it could create… but here we go. Off the top of my head:

the CSS for the two methods would have to be different so it can’t live as a pure static representation in ReadiumCSS, it would have to be handled depending on the pagebreak markup (empty + title VS. number in a span);
- ~~either via a flag/class/attribute;~~
- ~~or injected dynamically as a link or style in the <head>.~~
in the spread view (two columns), as a user, I’d probably expect numbers to be displayed in the outside margin (so left for the left column and right for the right column) but that’s only my preference and can’t tell what others would expect, obviously;
high page numbers → there is a possibility the margin could not be large enough to accommodate 3+ numbers very well:
- we have a page margin setting to take into account;
- should the font-size increase with the content’s?
that would be part of content, not UI:
- users will get two different paginations: the pagebreak one in margins and the UI one in the page’s footer – I can remember that iBooks supported pagebreak at some point, and they decided to replace the footer’s pagination with the pagebreak one at the time, then removed support for some reason;
- cascading issues with screen readers?
- cascading issues with selection/highlight?
- cascading issues with CFI/Search?
kind of an edge case but we should also probably take into account that numbers in margins can also be used to number lines or paragraphs in some publications (plays, STEM, etc.). I’ve seen ebooks numbering lines with a number on the left/right (not in margins because it’s not possible for authors) so in this case, the user would have two different sets of numbers.

This could be a good candidate for the “experimental features” we’ve been discussing two weeks ago though – and would allow us to test in real conditions.

Am also wondering if experimental features should maybe be plugins (and not modules per se)?

JayPanoz commented 6 years ago

I may have found a way to handle both

<span id="page001" title="1" epub:type="pagebreak"/>

and

<span epub:type="pagebreak" id="page001" class="whatever">1</span>

using some weird selectors e.g. [epub|type="pagebreak"]:not(:empty) and [epub|type="pagebreak"][title]:empty. If there is whitespace though, :empty won’t work..

JayPanoz commented 6 years ago

high page numbers → there is a possibility the margin could not be large enough to accommodate 3+ numbers very well

capture d ecran 2018-05-01 a 16 50 02

One possibility there, as 2+ digits can already be an issue on small and narrow screens, and 3+ digits on desktop would be to lay out page numbers with a writing-mode of vertical-lr (or a rotate transform).

capture d ecran 2018-05-01 a 16 49 38

That could also solve

kind of an edge case but we should also probably take into account that numbers in margins can also be used to number lines or paragraphs in some publications (plays, STEM, etc.).

Now,

should the font-size increase with the content’s?

Probably not, given the issue illustrated above.

llemeurfr commented 6 years ago

I must say I like this vertical solution, as it also avoid confusion with synthetic page numbers in the footer and may accomodate other (longer) strings included as "page-breaks".

danielweck commented 6 years ago

In reply to @JayPanoz :

If there is whitespace though, :empty won’t work.

Yes, until perhaps when CSS text-space-collapse: discard is supported? https://drafts.csswg.org/css-text-4/#white-space-collapsing

JayPanoz commented 6 years ago

To be honest, I was more focused on the :blank pseudo class, which builds upon :empty (cf. css-tricks), longer-term, but that could be another option.

JayPanoz commented 6 years ago

Quick question though: wouldn’t this (using pseudo elements) mess with the DOM Range?

JayPanoz commented 6 years ago

For further reference, here is the whitespace we get @ 1 and 0.5 (page margin setting) on a smartphone…

screenshot_20180516-100224

screenshot_20180516-100252

A factor of 1 (default) will already be quite difficult to deal with, 0.5 seems quite frankly impossible.

JayPanoz commented 6 years ago

From page numbering best practices

go to page functionality is a must, but announcement of page numbers while reading is optional.

This will at the very least require we alter the DOM at runtime depending on the user pref, e.g. announcement on:

<span epub:type="pagebreak" id="page001" class="whatever">1</span>

Announcement off:

<span epub:type="pagebreak" id="page001" class="whatever" aria-hidden="true">1</span>

There’s no way we can manage that using speak: none in CSS given its support.

Please note we shouldn’t even try using aria-label on the other markup, as it generally won’t work across all browser/assistive technology combinations with a span…

Of course if we feed the speech API via JS for TTS, we can ignore/include epub:type="pagebreak" but for app developers willing to rely entirely on the native TTS, we need a solution.

danielweck commented 6 years ago

Note that the notion of "skipping" elements during linear reading order / audio playback progression is documented in EPUB3 Media Overlays: http://www.idpf.org/epub/31/spec/epub-mediaoverlays.html#sec-skippability This concept ; as Avneesh Singh alluded to in the aforementioned discussion thread ( https://github.com/w3c/publ-cg/issues/43#issuecomment-388829373 ) ; actually originates from the DAISY specification for Digital Talking Books, which in fact provides content creators finer "skippability" control, compared with EPUB3 MO (in other words, the EPUB3 "read aloud" functionality is slightly less capable, due to simplification necessities).

As @JayPanoz said, a general-purpose screen reader (e.g. NVDA, Jaws, Narrator, etc.) will usually not be capable of inferring the "skippable" nature of DOM elements, unlike the dedicated TTS sub-system of a reading app which would typically associate epub:type="pagebreak" with skippability semantics ... thus why aria-hidden + CSS display: none might well be the only true "portable" solution.

garconvacher commented 6 years ago

(Off topic about aria-label in span with screen readers) We needed to use this technique for a particular case a year ago and we adopted it after some positive tests:

NVDA / Readium Chrome's extension (fresh test: Readium Desktop is fine too)
VoiceOver / Lisa Reader (iBooks is buggy, read the 'alt' span sometimes but didn't most of time)
Talkback / several readers.

JayPanoz commented 4 years ago

As discussed during the Readium Engineering Call on June 3rd, we think it’s better to let Reading Systems handle these styles as implementations may vary. Daniel summed the situation up in his comment above, so we’re closing this issue.

readium / readium-css

Provide styles for epub:type="pagebreak" #45