[UI/UX] Page numbers (`epub:type="pagebreak"`)

[JayPanoz]

We’re collecting feedback for Readium CSS and some requests may exceed the project’s scope (designing a CSS baseline).

Managing page numbers is a critical issue, especially in education. Users may search for page numbers, check which page they are scanning/reading/referring to (so page number should be displayed), etc.

Something as simple as having the page number displayed inline would already be judged some kind of progress, extra points if displayed in the margin. I guess it shouldn’t reflow with font-size but I may be wrong.

The streamer is already taking care of the pagelist/navdoc so this is probably more of an UI/UX-focused issue that a dev issue. Correct me if I’m wrong.

[llemeurfr]

In Readium-2 in general and Readium Desktop in particular, there will be three positioning mechanisms:

1. one is authored via page breaks and the associated page list (https://idpf.github.io/a11y-guidelines/content/nav/pagelist.html)
2. another is implicit from the pagination mechanism in reflow mode, where CSS columns fragment each spine item as N "screens". Screen content and screen numbers are highly dependent of the size of the screen, font size, margins etc. therefore is not a proper indication for sharing positions in the publication (the famous "go to page X").
3. the third is an internal positioning mechanism, which aims at being independent of the screen size. The whole publication is "cut" in P parts, each part begins at a given location, a locator has a position indicator (a number), a progression indicator (%) and a CFI.

This discussion is about point 1. How will page breaks be displayed? an horizontal line (

---

) with a central page number? a page number in the left or right margin ?

[danielweck]

Well, option number 1 implies that the epub:type="page-break" CSS styling (typically, on span elements) is author-defined. So the visual representation of a "page break" is totally up to content creators.

For option number 3, the arbitrary "break" (character-level location) between the computed "fragments" of content may occur anywhere on a line of text. Consequently, it makes sense to display a numbered location in the margin using a slightly dimmed font colour.

[JayPanoz]

option number 1 implies that the epub:type="page-break" CSS styling (typically, on span elements) is author-defined.

Agree.

From what I can hear though, it seems that some authors are afraid to set styles for this, for ≠ reasons e.g. cross-RS compat, it’s been historically RS territory, what if the RS displays page numbers already?

Consequently, it makes sense to display a numbered location in the margin using a slightly dimmed font color.

Question is, will the current margins implementation help or hurt this? It’s done entirely in CSS at the moment for the iOS proto, but we’ll probably have to constrain the size the container (webview/iframe) for bigger screens.

[danielweck]

Related: https://github.com/edrlab/readium-desktop/issues/82

[llemeurfr]

So, page-lists are now displayed, thanks to the readium/r2-testapp-swift#82 fix.

The question is now:

• If the author has not styled a span declared as page-break via epub:type, how do we style it?
• Can we display a page number "near" the styled break? in the margin? if yes the page number should be the title attribute value of the span element, as per the spec and usage (links below). Should we consider other types of html elements possibly supporting epub:type:'pagebreak'?

It seems to be a pure Readium CSS issue -> @JayPanoz? But Jiminy's latest comment seems to question the use of pure CSS if we want the page number in the margin...

http://epubsecrets.com/page-list-all-the-cool-ebook-developers-are-doing-it.php.
http://sketchytech.blogspot.fr/2017/01/when-is-page-break-not-page-break-epub.html

[JayPanoz]

Out of curiosity, I did a quick search about epub:type="pagebreak" and two markups seem to coexist in the real world 😞

Markup 1:

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

and Markup 2:

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

With the second one even being handled in a plugin to automate ncx pagelist. We may want to take that into account, I guess.

So now, pure CSS solution for markup 1:

I can’t use anything else than and ::after pseudo element and as you can see, it isn’t displayed after the empty span but at the very end of the paragraph (consistent between browsers). And when you start trying to put it into margins, you obviously get extra issues:

Overlapped page numbers.

Inconsistent positioning (see page number 3 and 4).

In other words, the positioning (offset) of the page number in the text node is simply lost in that case – I don’t necessarily know why yet, I must research the spec because it doesn’t work like that for non-empty elements (e.g. abbr for which you display the title using the same declaration…).

On a related note, authors have been very wary of styling page numbers, because they deem displaying the responsibility of the Reading System, considering their viable options (e.g. inline, disrupting the reading flow).

[JayPanoz]

OK so found why pseudo elements were appended at the end of the paragraph, <span /> + HTML. My bad.

Switched to XHTML and we still have the inconsistent positioning issue:

I’m using a float: left there, with a negative margin-left but that’s the best I can do. There is no way I can use the position:relative prop since I can’t retrieve the left offset of the ::after pseudo element in CSS, and do the following, that’s JS territory:

left = - left-offset - arbitrary-margin-value 

[llemeurfr]

On iBooks, the link (with the number) appears as-is, without even a specific RS style (I tested Moby Dick). But they implemented pop-up notes, which makes it a bit more comfortable.

As it appears that displaying the reference in the margin is not a "good" option, thanks to Jiminy's tests, can we decide to style the reference (letting some priority to an author's style) and develop a JS that opens a pop-up, or is it too complex for the short term?

[danielweck]

Laurent, are you talking about epub:type="noteref" and the associated epub:type="footnote"? (hidden HTML aside, typically) Here we are discussing rendering of epub:type="page-break" (typically, HTML spans with or without inline/block text), which have no interaction, right?

[JayPanoz]

Wait, are we talking about page numbers – as in epub:type="pagebreak" – or footnotes – as in epub:type="noteref"? Cos’ my test were about pagebreak.

[llemeurfr]

Oups sorry I mixed our discussion on page breaks with one parallel I have with other people.

[JayPanoz]

Note that floating the page number right (instead of left) can fix the alignment issue:

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

[llemeurfr]

Isn't the page-break visualization a good candidate for a place in the (advanced?) user settings? To answer to your concern about double numbering (one in the footer), we could decide that if "original page numbers" ("page-breaks" is sooo misleading) are displayed, synthetic page numbers are not. Re. the complexity of dealing with 2 methods of inclusion of page-breaks in the content, IMO this is something we should standardize in EPUB 3.2 and then we could "forget" the other way (or transform the content on the fly in the streamer via XSLT, it would be technically easy). This larger question should be discussed in another issue (I'll open it). For your other concerns, I don't know if we can overcome these issues. But it seems important in schools to have cross reference between print and ebooks, so solving this question would be very useful.

[JayPanoz]

Oh yeah definitely, and it’s one of eprdctn’s popular requests as well.

To sum things up, my major concern there would be whether this is the job of CSS or something else, given the possible impacts and cascading issues. And I objectively can’t tell right now. 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.

More generally, I guess we could probably discuss (Advanced) User Settings + experimental features, UX-wise, during the next R2 call. A few issues have been popping up across apps e.g. page margins in the Swift app so it sounds like the good time to discuss how we’ll proceed and get everyone on the same line.

[JayPanoz]

Re handling both markups: see https://github.com/readium/readium-css/issues/45#issuecomment-385670761

I may be able to handle that using CSS selectors.

[danielweck]

There is a lot of interesting reading in this comment thread, but this is not an actionable issue. I propose we close this. Also, water has been running under the bridge in the ReadiumWebPubManifest discussions about locators, etc.