Provide styles for epub:type="pagebreak" about readium-css HOT 11 CLOSED

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

from readium-css.

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

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

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.

from readium-css.

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

from readium-css.

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

from readium-css.

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.

from readium-css.

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

from readium-css.

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

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

from readium-css.

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.

from readium-css.

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 ( w3c/publ-cg#43 (comment) ) ; 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.

from readium-css.

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

from readium-css.

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.

from readium-css.