diff --git a/dot_travis.yml b/.travis.yml similarity index 100% rename from dot_travis.yml rename to .travis.yml diff --git a/index.html b/index.html index 3ac426b..5b2488f 100644 --- a/index.html +++ b/index.html @@ -61,6 +61,12 @@ "company": "Hachette Livre", "companyURL": "https://hachette.com/", "w3cid": 65283 + }, + { + "name": "Hadrien Gardeur", + "company": "Feedbooks", + "companyURL": "http://www.feedbooks.com/", + "w3cid": 97094 }, { "name": "Florian Rivoal", @@ -314,7 +320,7 @@

Terminology

URL

The general term URL is defined by the URL - Standard [[!url]]. It is used as in other W3C + Standard [[!URL]]. It is used as in other W3C specifications, like HTML [[!html]]. In particular, a URL allows for the usage of characters from Unicode following [[!rfc3987]]. See Web Publication Lifecycle viable and what solutions can be standardized. Input on the feasibility and challenges of these approaches is welcome at any time.

+ +
+

Obtaining a manifest

+
+

Discovery of a manifest is currently tied to the publication value for the rel attribute in an HTTP Link header or an HTML link element.

+

This could change in the future if our work aligns with [[appmanifest]] or another manifest format.

+
+

The steps for obtaining a manifest are given by the following algorithm. + The algorithm, if successful, returns a processed manifest and the manifest URL; otherwise, it terminates prematurely and returns nothing. In the case of nothing being returned, the user agent MUST ignore the manifest declaration.

+
    +
  1. + From the Document of the top-level browsing context, let origin be the Document's origin, and manifest link be the first link element in tree order whose rel attribute contains the token publication. +
    2. +
  2. + If origin is an [[!html]] opaque origin, terminate this algorithm. +
    3. +
  3. + If manifest link is null, terminate this algorithm. +
    4. +
  4. + If manifest link's href attribute's value is the empty string, then abort these steps. +
    5. +
  5. + Let manifest URL be the result of parsing the value of the href attribute, relative to the element's base URL. If parsing fails, then abort these steps. +
    6. +
  6. + Let request be a new [[!FETCH]] request, whose URL is manifest URL, and whose context is "publication". +
    7. +
  7. + If the manifest link's crossOrigin attribute's value is 'use-credentials', then set request's credentials to 'include'. +
    8. +
  8. + Await the result of performing a [[!FETCH]] with request, letting response be the result. +
    9. +
  9. + If response is a network error, terminate this algorithm. +
    10. +
  10. + Let text be the result of UTF-8 decoding response's body. +
    11. +
  11. + Let manifest be the result of running processing a manifest given text, manifest URL, and the URL that represents the address of the top-level browsing context. +
    12. +
  12. + Return manifest and manifest URL. +
    13. +
+
The publication value for context doesn't exist yet. We'll need to define and register this context value properly.
+
+
+

Processing the manifest

+
+

The manifest could be processed differently if we align with [[appmanifest]] or another format in the future.

+

Instead of using our own algorithm, processing would have to be defined as an extension point for another algorithm.

+
+

+ The steps for processing a manifest are given by the following algorithm.The algorithm takes a text string as an argument, which represents a manifest, and a [[!URL]] manifest URL, which represents the location of the manifest, and a [[!URL]] document URL. The output from inputting an JSON document into this algorithm is a processed manifest. +

+
    +
  1. + Let json be the result of parsing text. If parsing throws an error: +
      +
    1. + Issue a developer warning with any details pertaining to the JSON parsing error. +
      2. +
    2. + Set json to be the result of parsing the string "{}". +
      3. +
    +
    2. +
  2. + If Type(json) is not Object: +
      +
    1. + Issue a developer warning that the manifest needs to be an object. +
      2. +
    2. + Set json to be the result of parsing the string "{}". +
      3. +
    +
    3. +
  3. + Extension point: process any proprietary and/or other supported members at this point in the algorithm. +
    4. +
  4. + Let manifest be the result of converting json to a WebPublicationManifest dictionary. +
    5. +
  5. + Set manifest["reading_order"] to the result of processing the default reading order given manifest["reading_order"], manifest["resources"], manifest URL, and document URL. +
    6. +
  6. + Return manifest. +
    7. +
+
+ +
+

Processing the default reading order

+

+ The steps for processing the default reading order are given by the following algorithm. +

+
    +
  1. + If manifest["reading_order"] is not empty, return it and terminate this algorithm. +
    2. +
  2. + If manifest["resources"] is not empty, let navigation document link be the first PublicationLink whose rel member contains the token contents. +
    3. +
  3. + If navigation document link is not null and its href member is not empty, let navigation document URL be the result of parsing the value of the href attribute, relative to the manifest URL. +
    4. +
  4. + If navigation document URL is empty, set navigation document URL to document URL. +
    5. +
  5. + Let request be a new [[!FETCH]] request, whose URL is navigation document URL, and whose context is "publication". +
    6. +
  6. + Await the result of performing a [[!FETCH]] with request, letting response be the result. +
    7. +
  7. + If response is a network error, terminate this algorithm. +
    8. +
  8. + Let document be the result of UTF-8 decoding response's body. +
    9. +
  9. + If document is not an [[!html]] document, terminate this algorithm. +
    10. +
  10. + Let default reading order be the result of processing document: +
      +
    1. + If document contains a nav element: +
        +
      1. Extract a list of resource paths referenced from the href attribute of all a elements.
        2. +
      2. Strip any fragment identifiers from the references.
        3. +
      3. Resolve all relative paths to full URLs.
        4. +
      4. Remove all consecutive references to the same resource, leaving only the first.
        5. +
      +
      2. +
    2. + Otherwise terminate this algorithm. +
      3. +
    +
    11. +
  11. Return default reading order.
    12. +
+
+ -
-

Reading Enhancements

- -

This section contains placeholders for possible reading enhancements/affordances the user agent - may/should/must provide. The list is subject to addition, modification and removal as the enhancements get - discussed in more detail.

- -
-

Layout

- -

The layout and rendering of Web Publications is governed by the same rules that apply to all Web - content: [[!html]] documents are styled and laid out according to the rules of CSS, [[!svg]] - documents are rendered as expected of that format, etc. This specification requires no particular profile - or subset of CSS, HTML, or SVG to be supported, other than the - expectations set for these technologies by their respective specifications.

- - -
-

This specification intentionally avoids introducing any new layout features. Any shortcoming of the - Web platform in terms of layout needs to be addressed for the whole Web platform, which means via - CSS.

- -

This working group will work with other relevant groups of the W3C to address platform-wide limitations that negatively impact Web - Publications.

-
- -

For the purposes of layout, each resource of a Web Publication is treated as a separate document. User - agents MUST NOT mix content from multiple resources in the same rendering (e.g., CSS floats or absolutely positioned - elements from one resource cannot intrude or overlap with content from an other resource).

- -
-

Despite this general requirement that each resource should be treated as a separate document for the - purpose of layout, there are some places where CSS - specifications should be amended to be able to deal more intelligently with collections of resources - like Web Publications.

- -

One instance is the definition of cross-references, which are currently restricted to work only within a single document. This - restriction should be relaxed to allow for cross-references between separate resources of a single - Web Publication.

- -

Another related would be to allow counters to accumulate across multiple resources of a single Web Publication (e.g., so that - figures in multiple sections may be numbered in a single sequence).

-
- -
-

Scrolling or Paginating

- -

Publications have historically been presented via paged media, whereas Web pages almost always scroll. - As the preferences of individual readers vary, and as different types of publications are better - suited for one or the other, this specification encourages user agents to support both, and to offer - a choice to their users.

- -
-

It may be useful for authors to be able to specify a preference between scrolling and pagination, - even if a strict requirement is not possible. This should most likely be addressed through an - extension of @viewport or of the viewport meta tag(see - [[css-device-adapt]]), or possibly through an extension of @page (See - [[css-page-3]]). This should be discussed with the relevant working groups (CSSWG, WebPlatformWG, WHATWG).

-
-
-
-

Paginated Layout

- -

When a user agent renders a Web Publication in a paginated layout, it MUST lay out each - document in the default reading order sequentially, with the last page of a resource being - followed by the first page of the subsequent one.

- -
-

To avoid blank pages, if a resource ends on a left page (resp. right page), the subsequent one - should start on a right page (resp. left page) even if the page progression (see - [[!css-page-3]]) would otherwise lead to it starting on the opposite page. It should also be - possible to use the break-before property (see [[!css-break-3]]) to force the content to resume on the - opposite side if that was desired by the author.

- -

[[css-page-3]] needs to be amended to describe this exception to the general behavior when dealing - with collections of documents instead of individual documents.

-
- -
-

How is pagination supposed to work when subsequent resources have opposite page progression directions (see - [[css-page-3]]). For example, due to different a different writing mode? This is not necessarily - a problem from a layout point of view, as each page is independent, but from an UI point of view. - If swiping left means next page until the end of one chapter, and starts meaning previous page in - the next chapter because the language is switched from English to Hebrew, this is going to be - confusing.

-
- -
-

Should any of the above be normative, or should this be up to user agents to explore, and only - standardize if and when a clear winning approach emerges?

-
- -
-

[[css-page-3]] needs to be amended so that page counters are not - automatically reset to at the beginning of each new resource belonging to the same Web - Publication.

-
- -
-
- -
+
+

Affordances

+ +

This section contains placeholders for possible reading enhancements/affordances the user agent may/should/must provide. The list is subject to addition, modification and removal as the enhancements get discussed in more detail.

+ +
+

Switch to publication mode

+

When a User Agent obtains a manifest it SHOULD display an affordance for switching the display to publication mode.

+

This affordance has the following requirements:

+
    +
  1. it MUST inform the user that the current resource is part of a Web Publication
    2. +
  2. it SHOULD display the title of the Web Publication
    3. +
  3. it MAY display additional metadata from the infoset
    4. +
+

Publication mode is a display mode implemented by the User Agent that follows the conventions listed in presentation and navigation.

+
+ +
+

Add to the list of publications

+

User Agents SHOULD provide a list of publications where the User can browse, search, add and remove their publications.

+

When a User Agent obtains a manifest for a Web Publication that's not currently listed in the list of publications, it MAY provide an affordance to add it to the list.

+

This affordance has the following requirements:

+
    +
  1. it SHOULD display the title of the Web Publication
    2. +
  2. it MAY display additional metadata from the infoset
    3. +
+
+ +
+

Presentation

+
+

Layout

+ +

The layout and rendering of Web Publications is governed by the same rules that apply to all Web content: [[html]] documents are styled and laid out according to the rules of CSS, [[!SVG]] documents are rendered as expected of that format, etc. This specification requires no particular profile or subset of CSS, HTML, or SVG to be supported, other than the expectations set for these technologies by their respective specifications.

+ +
+

This specification intentionally avoids introducing any new layout features. Any shortcoming of the + Web platform in terms of layout needs to be addressed for the whole Web platform, which means via + CSS.

+ +

This working group will work with other relevant groups of the W3C to address platform-wide limitations that negatively impact Web + Publications.

+
+ +

For the purposes of layout, each resource of a Web Publication is treated as a separate document. User + agents MUST NOT mix content from multiple resources in the same rendering (e.g., CSS floats or absolutely positioned + elements from one resource cannot intrude or overlap with content from an other resource).

+ +
+

Despite this general requirement that each resource should be treated as a separate document for the + purpose of layout, there are some places where CSS + specifications should be amended to be able to deal more intelligently with collections of resources + like Web Publications.

+ +

One instance is the definition of cross-references, which are currently restricted to work only within a single document. This + restriction should be relaxed to allow for cross-references between separate resources of a single + Web Publication.

+ +

Another related would be to allow counters to accumulate across multiple resources of a single Web Publication (e.g., so that + figures in multiple sections may be numbered in a single sequence).

+
+ +
+ +
+

User Settings

+ +

When a user agent renders a Web Publication, it SHOULD provide user settings to customize the experience.

+

User settings may include:

+
    +
  • text size
    • +
  • font family
    • +
  • display mode (night, high contrast...)
    • +
  • playback speed (for audio and video resources)
    • +
+

This specification does not cover how the user agent may override author styles to offer user settings.

+ +
+

To provide user settings in their reader mode, browsers usually get rid of most of the author styles.

+

There's always a tension in reading environments between author styles and the user's preference, which is very hard to balance.

+
+ + +
+ +
+

Scrolling or Paginating

+ +

Publications have historically been presented via paged media, whereas Web pages almost always scroll. + As the preferences of individual readers vary, and as different types of publications are better suited for one or the other, this specification encourages user agents to support both, and to offer a choice to their users.

+ +
+

It may be useful for authors to be able to specify a preference between scrolling and pagination, even if a strict requirement is not possible. This should most likely be addressed through an extension of @viewport or of the viewport meta tag(see [[css-device-adapt]]), or possibly through an extension of @page (See [[css-page-3]]). This should be discussed with the relevant working groups (CSSWG, WebPlatformWG, WHATWG).

+
+
+
+

Paginated Layout

+ +

When a user agent renders a Web Publication in a paginated layout, it MUST lay out each document in the default reading order sequentially, with the last page of a resource being followed by the first page of the subsequent one.

+ +
+

To avoid blank pages, if a resource ends on a left page (resp. right page), the subsequent one should start on a right page (resp. left page) even if the page progression (see [[!css-page-3]]) would otherwise lead to it starting on the opposite page. It should also be possible to use the break-before property (see [[!css-break-3]]) to force the content to resume on the opposite side if that was desired by the author.

+ +

[[css-page-3]] needs to be amended to describe this exception to the general behavior when dealing with collections of documents instead of individual documents.

+
+ +
+

How is pagination supposed to work when subsequent resources have opposite page progression directions (see [[css-page-3]]). For example, due to different a different writing mode? This is not necessarily a problem from a layout point of view, as each page is independent, but from an UI point of view. + If swiping left means next page until the end of one chapter, and starts meaning previous page in the next chapter because the language is switched from English to Hebrew, this is going to be confusing.

+
+ +
+

Should any of the above be normative, or should this be up to user agents to explore, and only standardize if and when a clear winning approach emerges?

+
+ +
+

[[css-page-3]] needs to be amended so that page counters are not automatically reset to at the beginning of each new resource belonging to the same Web Publication.

+
+ +
+
+ +

Navigation

-
+

Reading Order

-

Hyperlinks are the means by which multiple resources are linked together on the Web. When users reach - the end of one resource, they have to activate a hyperlink to move to the next resource in the - sequence. While this model of navigation is effective, it is also disruptive for immersive reading - — it forces users to disengage from the content and perform the actions necessary to activate - the links. It is also limited to media types that support hyperlinks.

+

Hyperlinks are the means by which multiple resources are linked together on the Web. When users reach the end of one resource, they have to activate a hyperlink to move to the next resource in the sequence. While this model of navigation is effective, it is also disruptive for immersive reading — it forces users to disengage from the content and perform the actions necessary to activate the links. It is also limited to media types that support hyperlinks.

-

The default reading order provides an enhancement to the hyperlink model, allowing the user - agent to automatically move the user to the next resource when a more natural action occurs, like a - general swipe across the screen. It is similar conceptually and functionally to the [[!html]] - link element's next and prev relationships.

+

The default reading order provides an enhancement to the hyperlink model, allowing the user agent to automatically move the user to the next resource when a more natural action occurs, like a general swipe across the screen. It is similar conceptually and functionally to the [[!html]] link element's next and prev relationships.

+ +

User agents MUST provide an affordance for moving forward and backward in the default reading order of a Web Publication.

What is the interface for reading order navigation.

+ +
+

Progression

+ +

While reading a Web Publication, the user follows a natural progression within a resource as well as between resources (following the default reading order).

+ +

User agents SHOULD provide an affordance that saves this progression in the publication and return the user to their current location the next time that they open the publication again.

+ +

When the user agent obtains a manifest for the first time, it MAY also prompt the user whether they'd like to:

+
    +
  • continue reading the publication from their current location
    • +
  • or start reading the publication from the first resource in the default reading order
    • +
+
-
+

Table of Contents

-

The table of contents is one of the key aids to navigating a publication, as it enables users to - quickly move to the start of major sections. It is also a useful aid in understanding the overall - structure and purpose of a publication (e.g., what topics are covered, where the user currently is in - relation to the overall structure). Users often want quick access the table contents for these - reasons.

+

The table of contents is one of the key aids to navigating a publication, as it enables users to quickly move to the start of major sections. It is also a useful aid in understanding the overall structure and purpose of a publication (e.g., what topics are covered, where the user currently is in relation to the overall structure). Users often want quick access the table contents for these reasons.

-

User agents can use table of contents defined in the infoset to present an interface that allows users to review and activate the links - without leaving the resource they are currently viewing.

+

User agents SHOULD provide an affordance for accessing this table of contents without leaving the resource they are currently viewing.

-

Issue 9: Does the user agent need to - provide access to the table of contents, or do such mechanisms belong in the content.

+

Issue 9: Does the user agent need to provide access to the table of contents, or do such mechanisms belong in the content.

-
-

Offline Reading

+
+

Offline Access

Detail on offline caching and reading will be included in a future draft.

-