Letting the author control pagination vs scrolling

[HadrienGardeur]

This is based on my gap analysis between EPUB 3.2 and WP: #176 (comment)

In EPUB, an author can indicate if an entire publication or a given resource:

• should be paginated
• should be scrollable
• should be scrollable continuously (allows the user to move forward/backward in the reading order)

While we're currently hinting at pagination vs scrolling in our current draft, there's no element in our infoset to hint or force a specific behaviour.

This can be very important for specific publications where enabling pagination would pretty much "break" the reading experience (for instance, webtoons in Korea are all scroll-based).

[frivoal]

I think hinting at the preferred handling is all we can do. Forcing one or the other seems to go against the grain of the web platform.

If you "force" scrolling, and the user tries to print it, what happens? The only thing you can do is get pages (or refuse to print at all).

If you "force" paginating, what do you do if you load the content in a UA that does not support on-screen pagination (for example, all current desktop and mobile browsers).

Ultimately, if WP wants to be part of the web, it has to accept the constraints of the web, which is that the user and their environment, not the author, have the ultimate say on how things get rendered.

[llemeurfr]

If the consensus goes in favor of @frivoal for WPs, we'll have to raise the question for EPUB4 and question if such property should be at the level of the document (in the reading order, aka spine item) or the whole publication.

I'd favor a publication-wide property (which works for webtoons / continuous scroll).

[iherman]

@llemeurfr why would an EPUB4 be different than a WP in this respect?

[llemeurfr]

@iherman round tripping btw EPUB 3 and 4 ...

Re the printing issue raised by @frivoal, as web UA's do paginate for printing, what would be the practical impact for UA's of letting authors express a preference for "paginated" vs "scrolled"?

[iherman]

@llemeurfr I am not very good at the details of EPUB3, but do I remember well that in EPUB3 it is possible to set this hint for every resource? Then I understand your issue.

It would be possible to incorporate this into WP by adding a new term to PublicationLink. I am not sure whether it is useful or not, though, my instinctive reaction is like yours, ie, that this is a flag for the publication as a whole...

[dauwhe]

A web publication should use CSS to control its visual rendering.

[llemeurfr]

@iherman, yes in EPUB3 the author can set a mode = paginated / scrolled-doc / scrolled-continuous either at the publication level or at the spine item level.

The spine-item level bothers me (as a reading system developer) but we should acknowledge that authors may have good reasons to propose an optimum rendition at the publication level.

[TzviyaSiegman]

Let's not conflate WP and EPUB 4. Can we add this to the EPUB 4 repo?

[llemeurfr]

@TzviyaSiegman it depends on the consensus around WP vs authors' proposal of an optimum rendition of their content. It seems too early to state that there is a consensus here.

[BigBlueHat]

Web Publications should be for browsers. EPUB4 can be for Reading Systems (in or out of browsers).

Putting Web Publication in the "lineage" between EPUB3 and EPUB4 is tripping us up far too often. We can avoid it by not making EPUB4 a "successor" of Web Publication, but rather a more "modern" EPUB3 implementation (i.e. JSON instead of XML, HTML5 instead of XHTML).

It would clarify so many things.

[GarthConboy]

I predict this issue will be on the agenda for Monday. :-)

[frivoal]

Re the printing issue raised by @frivoal, as web UA's do paginate for printing, what would be the practical impact for UA's of letting authors express a preference for "paginated" vs "scrolled"?

Expressing a preference is fine (and the mechanism for expressing this preference should indeed be CSS, as @dauwhe rightfully pointed out). The question is whether that is merely a preference, or whether we can elevate it to a strict requirement that the user agent has to obey. I believe it cannot be a strict requirement if WPUB is to be a first class entity on the web (as stated in our charter). Rendering on the web is a UA decision. Informed by authored instructions, sure, but ultimately decided by the user and its agent.

Separately from that, I don't understand what it means for EPUB4 to be a profile of WPUB if it has features (such as forcing a particular rendering) that WPUB doesn't have.

[bduga]

I am confused about what we are discussing (what else is new?). It seems there are two issues:

1. Can an author express an intent that a particular resource should be scrollable or paginated?
   1a. Can that be expressed at both the publication and resource levels?
   1b. Can we specify continuous scroll vs resource-at-a-time scroll?

2. Can authors force a resource or publication to only be scrolled or paginated?

I was assuming this issue was about 1, not 2. For what it is worth, EPUB 3 has no mechanism to force one display method over another, and has been pointed out it is impossible to force this for the web (printed documents will never scroll, not all UAs will support on screen pagination).

Providing hints for 1 seems fairly uncontroversial, except perhaps for having mixed paginated and scrollable content, but if we are talking hints I have a hard time saying it shouldn't be allowed.

[HadrienGardeur]

@bduga thanks for the summary, I think that's useful.

My take on this:

• we should treat such information as a hint, not something that we force on content (at least for WP)
• I think that having this both at a publication level and a resource level makes sense (that's what EPUB 3 has as well)

[llemeurfr]

@frivoal, from the EPUB 3 spec: "Specifies the Author preference for how Reading Systems should handle content overflow." (emphasis mine).
The title of this issue is confusing. It's not about control, it's about preference only.

Just a question for the experts: How can a CSS control the vertical positioning of a set of Web resources (continuous scroll)?

[llemeurfr]

About the complexity of having such indication both at the level of the publication AND individual document: see w3c/epub-specs#823

[HadrienGardeur]

@llemeurfr I think you're mistaking the intent of this issue. I'm not suggesting anything in this issue, just listing the gap with EPUB 3.x. This is part of a longer list of issues, as listed in: #176 (comment)

In EPUB, this is about control not hints.

[llemeurfr]

@HadrienGardeur I'm pretty sure I don't. From the description of a gap analysis, these issues you created (thanks) are about taking positions about solutions for WPs.

And in EPUB, reading the spec, you're wrong: this is about expressing author's preference, not strict control.
See the use of "global preference" and "SHOULD" in http://www.idpf.org/epub/31/spec/epub-packages-20160906.html#layout-property-flow ;
See the use of "preference" in https://idpf.github.io/epub-vocabs/rendition/rendition.html#sec-itemref-property-values.

[HadrienGardeur]

All the issues listed in #176 (comment) are meant to have a better understanding of the current gap between WP and EPUB 3.x.

I'm not saying that we should implement all of them in WP or even EPUB 4. These issues are meant to have discussions and then decide what's best.

[GarthConboy]

Like I said, this topic will be on the Monday agenda... I look forward to discussion then.

[avneeshsingh]

Would like to remind that having strict control of author will be a huge problem for accessibility. It should be author's preference, which can be overridden by accessibility preferences.

[GarthConboy]

Proposed resolution: Allow such a "hint" that would be "publication wide" (e.g., how all the resources should be presented when slamming together all the resources in the default reading order).

[HadrienGardeur]

What do we expect from a WP UA in terms of scroll vs pagination?

If we expect them to paginate a publication (even if the authored CSS does not contain pagination), then a hint makes sense.

If we expect WP UAs to keep content as-is, this can probably be pushed to EPUB4 instead of WP.

[ghost]

I would expect UA to paginate instead of authors, so that when UA sees pagination/scrolling hint it is expected to try do so. In terms of pagination/scrolling we also need to respect reader's choice I believe that's is also the reason why many of current RS can let reader switching between pagination and scrolling

[HadrienGardeur]

There's a real tension between what the author wants and what the user wants.

Paginating the content without "nuking styles" might be difficult, if not impossible (that's the "reader mode" scenario).

[jccr]

Let's say I'm a WP author and I want a basic document. I like the idea of pagination instead of scrolling. My WP will use the hint "pagination". I expect that the UA will then handle this for me, or if it can't that's probably fine since I want something basic.

On the other hand let's say I'm an author of a rich media publication with a complex pagination scheme I created using what works right now in the web platform. I prefer that the UA keeps my content as-is. Do I use no hint here or do I want a hint value that says don't do either, or it's pre-paginated (treading carefully with this term)

...If I did a good job with my WP & content by having a well defined structure with semantics, then the UA could pick apart my complex paginated WP and re-interpret the pagination but I want some level of satisfaction when my pagination is not used (styles are nuked?).

[ghost]

Yes good point. In this pre-paginated content case should creator specify "scrolled-doc" base on what we have currently in epub3 spec (so that UA/RS would do nothing but respect content itself)?

@HadrienGardeur I think edge is a good example for pagination. Without creator setup anything it just paginate xhtml. My naive idea is ideally content pagination is just as when user print a web page through UA (automatically paginated). So far since UA cannot support paginate layout well all CSS injection (multi-column, overflow etc) are just different solutions that RS trying to adopt UA. And to paginate without "nuking style" might be considered as very difficult. But thinking about once UA could support paginated layout well it should be simultaneously same as printing html out.

[ghost]

yes no matter currently multi-column/overflow way or in the future ideally paged layout way I think they are all in css scope.

[GarthConboy]

I think this feature would be very valuable, but I have extremely strong reservations about this hint being specified using something else than CSS. This is a question of styling, and styling is CSS's scope.

There is no away to apply publication-wide CSS -- desires about how default-reading-order resources are stitched together. This is that; a hint to the UA/RS about author-desired stitching. Perhaps in the future CSS will have an answer for pagination, but that could be a long time.

[jccr]

In a parallel world, where the entry document provides the structure of the publication in HTML:
Define sections of content in seamless iframes. Stitch them visually with CSS declared in the entry document which makes the publication

[llemeurfr]

@frivoal, @dauwhe, @rdeltour do you mean that we should nuke the pagination use case https://www.w3.org/TR/pwp-ucr/#pagination or do you mean that the author should be able to indicate, on a resource base, his preference by using his preferred CSS pagination trick (CSS multi-column, CSS paged media, CSS regions), a choice that could be overridden by the UA's CSS?

[murata2makoto]

My two cents:

EPUB3 uses several features doubtful in the context of OWP. Rather than sticking to such backhanded features of EPUB3, WP/PWP/EPUB4 should enhance OWP. Specifically, WP/PWP/EPUB4 should not use itemref elements for representing a page in a fixed-layout publication, and should not use rendition properties attached to itemref or spine elements. We should rather request extensions of HTML and CSS, when such extensions are required.

[frivoal]

@llemeurfr we should not nuke the pagination use case at all.

Pagination vs scrolling is a design choice, and design on the OWP is done is with CSS. CSS today does not have a way to chose between paginated or scrolling rendering, so that feature should be added. But it should be added to CSS, not to WP/PWP/EPUB4.

WP/PWP/EPUB4 authors should merely use that CSS feature once it exists. Until then, WP/PWP/EPUB4 reading systems can just pick a default, and offer a user setting if they want to.

However, we should not introduce new features to something else than CSS to cope with the fact that CSS lacks certain features.

[murata2makoto]

@GarthConboy wrote:

There is no away to apply publication-wide CSS -- desires about how default-reading-order resources are stitched together.

That's why I am wondering if we should drop spine and itemref from WP/PWP/EPUB4.

[HadrienGardeur]

There's no spine and itemref in WP, we don't use an id/idref system at all. Le dim. 12 août 2018 à 16:52, MURATA Makoto <notifications@github.com> a écrit :

…

@GarthConboy <https://github.com/GarthConboy> wrote: There is no away to apply publication-wide CSS -- desires about how default-reading-order resources are stitched together. That's why I am wondering if we should drop spine and itemref from WP/PWP/EPUB4. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#207 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFjbYYVLe-5RcSKsGfOeckrvZT4eXTuks5uQEEegaJpZM4UZYM4> .

[murata2makoto]

@HadrienGardeur

But WP has a default reading order, which is a sequence of Web Publication resources. To me, it is nothing but a spine.

[llemeurfr]

@frivoal, I agree that having the author's design preference expressed as CSS is the best way to go.

So, let's setup a pow-wow with the CSS WG in order to create such a functionality... Something that will allow the author to express his preference for a paginated or scrolled view (default behavior), and will allows the UA CSS (e.g. Readium CSS) to easily override this choice, as expressed in the pagination Use Case.

[dauwhe]

So, let's setup a pow-wow with the CSS WG in order to create such a functionality... Something that will allow the author to express his preference for a paginated or scrolled view (default behavior)

See CSS Overflow Level 4 for the current state of CSS in this area. There is still lots of foundational work to be done. But eventually pagination should just be defined by quite simple CSS:

:root {
    continue: paginate;
  }

[frivoal]

@dauwhe : yes, continue:paginate is the most likely candidate out of the things that have a draft. Something around @viewport (or a similar at-rule) also sounds plausible. Either way, it needs to be worked out.

@GarthConboy:

There is no away to apply publication-wide CSS [...] "resources stitched together"

True. I think this will not be solved until some group (presumably this one, in cooperation with the WebPlatWG and/or WHATWG, CSSWG, etc) defines in a way that is acceptable to the whole OWP a concept of "resources stitched together". Once we know what that means in terms of URL, single origin, DOM (and other ***OM), CSS can work with that object and define things that apply to the whole. But for now, as far as the OWP is concerned, resources stitched together isn't a thing, so we need to crack that first.

[llemeurfr]

So far so good. If we have to wait until CSS has been moved to level 4 in all browsers (2020+?), what will happen before with all these publications (e.g. japanese mangas) transformed to WP from FXL EPUB? How will we avoid them to be displayed in a weird mode?

[ghost]

Hmm, continue: paginate sounds much more complicated than what we need since continue: paginate is supposed can be applied to any block/flex/grid containers. Maybe something additional to media query?
Either way, how about as WP we just go slightly "extremely" by removing this hint? At least not any content will be broken (such as webtoon). Meanwhile we can work with other WG to provide a CSS way to provide this hint. During this time UA might still have to nuke style to provide a way to paginate but I think it's better than we add this hint temporarily for now then deprecate it in later version.
I don't worry much about Japanese Manga which is FXL EPUB since usually each chapter is either a jpeg or a xhtml/html with only one image so they will be easily "paginated" default when transformed to WP.

[murata2makoto]

@llemeurfr

Migration from EPUB3 to WP is a very tough sell. I do not see any problems even if publishers have to continue to use EPUB3 FXL until 2025. Even if WP is equally good, there is no hope. If very good alignment with the OWP provides some business values, there might be some chances.

[llemeurfr]

@rakutenjeff, ok for manga, their structure is simple (one html includes one image), and the viewport information should be sufficient for FXL content to be constrained to the screen .

[ghost]

@murata2makoto I think it's a good point but we really don't know unless we push WP to market.

[frivoal]

So far so good. If we have to wait until CSS has been moved to level 4 in all browsers (2020+?) [...]

Yes, it will take time, but no, we don't have to wait for anything: we have to work at it. The CSSWG is not a "them" that we need to wait for, it is a forum within W3C to work on a particular topic, and W3C is us. So if we want to add a new feature to the web platform, we should do it, and the correct technology for that problem on the OWP is CSS.

Quoting the introduction of our charter:

The mission of the Publishing Working Group is to enable all Web Publications (see below) — with all their specificities and traditions — to become first-class entities on the Web. The WG will provide the necessary technologies on the Open Web Platform to make the combination of traditional publishing and the Web complete in terms of accessibility, usability, portability, distribution, archiving, offline access, and reliable cross referencing.

Also

New CSS features may be needed to support web publications. Such features would be specified in the CSS Working Group, with the Publishing Working Group providing use cases, requirements, and examples. The Publishing Working Group would also help the CSS WG with the development and testing of new and existing CSS functionality that is of interest to the publishing community. The group will designate liaisons to work with the CSS WG on issues as needed. Liaisons will ideally be part of both groups.

So, if we are trying to add features such as pagination-on-demand to the web platform, then we need to do it in—or together with—the CSSWG. If we're not trying to solve the needs of the publishing industry on the web platform, what are we doing?

continue: paginate sounds much more complicated [...]

It is, especially since it can paginate something else than the top level element of the document. I suspect that an at-rule is much more practical for what we're trying to do. Either way, this is a CSS topic, and as per our charter, we should be "providing use cases, requirements, and examples", and "help the CSS WG with the development and testing of new and existing CSS functionality that is of interest to the publishing community".

[ghost]

Yes agree. I think after get consensus here we can move on to work with CSS WG as next step.

[llemeurfr]

@frivoal it's good to see optimistic views. But I can't believe that the outcome of the CSS WG work ("us") will be immediately implemented in all browser engines (not "us" AFAIK). Nevertheless, as I said before, let's make a pow wow and work on that with the CSS WG.

[frivoal]

Adding features to the web platform = convincing browser engine implementers. Yes, it can be an uphill battle if the request is a bit outside of their core interests, but that's all the more reason to start early.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Letting the author control pagination vs scrolling
Wendy Reid: #207
Wendy Reid: #207: Letting the author control pagination vs scrolling
… CSS can do? Not for WP?
Luc Audrain: issue with FL
Brady Duga: If done in CSS that’s at doc level, not publication level. Likely needs to be at the top level.
… Should this be under author “control” (maybe better “intent”); browsers aren’t gonna do it.
Ivan Herman: Might want to come back to UA hints. Maybe want those in the manifest.
… we shouldn’t deal with this in bits and pieces.
… EPUB hints (if any), should they move in?
Brady Duga: We were vaguely successful in EPUB land (e.g., page progression direction, FL stuff).
… Should close this one, and open one that (hint) direction.
Ivan Herman: Should note what worked in EPUB.
Luc Audrain: +1
Wendy Reid: close this one, open a new one. Brady will make new issue.
Ivan Herman: those that work in EPUB.
Luc Audrain: Hadrien’s manifest comparison can help.
Wendy Reid: close this one (#207), and create a specific one for all hints of this sort

[frivoal]

Please link to the new issue from here when it is created, otherwise you risk losing existing participants to this discussion along the way. Until then, as I'm seeing the same arguments come up again, I'd like to reemphasize my point, because I think it the tension we're seeing here is fundamental to the way this community has approached solving problems of the web platform so far.

We have two similar issues here:

• Styling on the web should be done in CSS. If we want CSS to solve styling problems that it currently does not solve, we need to work on solving them, and we need to do so by joining and participating in the CSSWG. The CSSWG is not a group of people we need to wait for, it is a place specifically set up for W3C members (that includes us) to discuss that sort of issue. For all the talk about pagination being an important feature for publications, how many of the members of the publishing community have even raised an issue or commented on an existing one in the CSS-WG? Waiting a while for "them web people" to solve our issues, and then rolling our own, separately from the web platform, when “they” don't, is a strong anti-pattern, and we're never going to make anything that is a “first-class entities on the Web” with that approach.

• One of the big difficulty that would get in the way of solving this problem in CSS is that CSS does not have a concept of a publication made of multiple documents stitched together. This is very much not a limitation of CSS that we should work around, it is a limitation of the web platform itself: It's not just CSS that doesn't know how to cope with collections of documents. Neither does the DOM and all other JS APIs; neither does the Single Origin Policy and all other security features; neither does the URL… Fundamentally, this is the same problem as the previous one: waiting a while for "them web people" to solve our issues, and then rolling our own, separately from the web platform, when “they” don't. There's no they; we are W3C members. If we want the web platform to improve, we have to work at it together with the other stakeholders of the web platform, in the various WG chartered to cope with the various parts of the technology stack. I think there are 3 possible ways forward:

  1. We engage with the relevant CGs/WGs that are or could be working on that problem, and try to develop solutions that work for the whole web platform (maybe as part of Web Package, or maybe as a mechanism in HTML). Then we use that as the basis for Web Publications being made of multiple documents.

  2. We give up on the aspiration of making Web Publications a “first-class entities on the Web“. In that case I believe we need to recharter the Working Group, because doing the following sentences form the charter wouldn't be followed (emphasis mine):

     The mission of the Publishing Working Group is to enable all Web Publications [...] to become first-class entities on the Web

     It is the goal [...] to provide, in concert with other W3C Groups as outlined in Section 4.1, the necessary technologies on the Open Web Platform [...]

  3. We give up on the concept of a publication being composed of multiple documents stitched together (aka. “the spine“ or “the reading order“). This probably requires a group recharter too, since that concept is explicitly mentioned as a goal. (edit: Drop the default reading order from WP #302 is about that).

[murata2makoto]

#302 was also closed.

[therealglazou]

Commenting on Florian's last message. Yes, styling should be done through CSS and CSS only, and what we've been saying for a decade now still applies: if you want something added to CSS, don't wait for CSS non-publishing members to do it for you. Go there, contribute, design, author, edit.

That said, multi-document instances do not exist on the Web right now. They could. It's only a matter of standardization. One could see the transition between the end of one document and the beginning of the next one in the same flow for instance just as a special "page transition" (that's one of the several possibilities) or a multi-document instance could use instance inclusion mechanism (à la Overlays) to generate a single paginatable document from all individual instances. It's doable, but not without Publishing's direct contribution to HTML and CSS.

[bduga]

I will look at opening the new bug today. For what it is worth, I do not disagree with Florian.

[bduga]

Opened #413 to track all rendering hints that we may want to consider.