Copyright © 2017 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
This specification defines a collection of information that describes the structure of Web Publications, so that user agents or developers may create user experiences well-suited to reading publications, such as sequential navigation and offline reading. This information includes the default reading order, a list of resources, and publication-wide metadata.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This first public working draft provides a preliminary outline of a Web Publication. Many details are under active consideration within the Publishing Working Group and are subject to change. The most prominent known issues have been identified in this document and links provided to comment on them.
In particular, the Working Group seeks feedback on the following issues:
This document was published by the Publishing Working Group as an Editor's Draft. Comments regarding this document are welcome. Please send them to public-publ-wg@w3.org (subscribe, archives).
Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 March 2017 W3C Process Document.
This section is non-normative.
For millenia now, the written word has been the primary means of encoding and sharing ideas and information. The publication as a bounded edition, made public, has been used to carry intellectual and artistic works of innumerable form: novels, plays, poetry, journals, magazines, newspapers, articles, laws, treatises, pamphlets, atlases, comics, manga, notebooks, memos, manuals, and albums of all sorts.
More recently, with the advent of the information age, print has been ceding ground to digital, and the Web has become a major forum for the public dissemination of ideas. But the Web is unbounded: information and resources are only loosely connected through hyperlinks. While this model has helped the Web thrive in many areas, it has proven problematic for traditional information publishing—users often cannot access works in their entirety, especially when offline, and have not been able to easily access, compile and download content for curation and personal use. That, in turn, has fed the continuing development of non-Web document formats to redress these problems, and made it necessary to create both Web-ready content and alternative offline renditions to ensure publications are fully available.
This specification aims to reduce these barriers and reinvigorate publishing by combining the best aspects of both models—the persistent availability and portability of bounded publications with the pervasive accessibility, addressability, and interconnectedness of the Open Web Platform.
This section is non-normative.
This specification only defines requirements for the production and rendering of valid Web Publications. As much as possible, it leverages existing Open Web Platform technologies to achieve its goal—that being to allow for a measure of boundedness on the Web without changing the way that the Web itself operates.
Moreover, the specification is designed to adapt automatically to updates to Open Web Platform technologies in order to ensure that Web Publications continue to interoperate seamlessly as the Web evolves (e.g., by referencing the latest published versions instead of specific versions).
Further, this specification does not attempt to constrain the nature of a Web Publication: any type of work that can be represented on the Web constitutes a potential Web Publication.
Wherever appropriate, this document relies on terminology defined by the note on "Publishing and Linking on the Web" [publishing-linking], including, in particular, user, user agent, browser, and address.
An identifier is metadata that can be used to refer to Web Content in a persistent and unambiguous manner. URLs, URNs, DOIs, ISBNs, or PURLs are all examples of persistent identifiers frequently used in publishing.
A manifest represents structured information about a Web Publication, such as informative metadata, a list of all resources, and a default reading order.
For the purposes of this specification, non-empty is used to refer to an element, attribute or property whose text content or value consists of one or more characters after whitespace normalization, where whitespace normalization rules are defined per the host format.
In this specification, the general term URL is used as in other W3C specifications like HTML [ html], and is defined by URL Standard of the WhatWG [url]. In particular, such a URL allows for the usage of characters from Unicode following [rfc3987]. See the note in the HTML5 document for further details.
A Web Publication is a collection of one or more resources, organized together through a manifest into a single logical work with a default reading order. The Web Publication is uniquely identifiable and presentable using Open Web Platform technologies.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, SHOULD, and SHOULD NOT are to be interpreted as described in [RFC2119].
This specification defines two conformance classes: one for Web Publications and one for user agents that process them.
A Web Publication is conformant to this specification if it meets the following criteria:
A user agent is conformant to this specification if it meets the following criteria:
The name "infoset" may change depending on feedback. Although this term has a different meaning for individuals familiar with XML, alternatives such as "properties" and "metadata" do not fully capture the nature or purpose. See issue #63 for discussion.
A Web Publication is defined by a set of properties known as its information set (infoset). The infoset is both abstract and concrete. It is abstract in the sense that it represents a set of information that a user agent has to be able to compile about the Web Publication, but it also becomes concrete when the user agent creates an internal representation of the information.
The infoset does not require a specific serialization. It is primarily compiled from a Web Publication's manifest, whose serialization requirements are defined in 4.4 Serialization. It is therefore possible to express the same infoset via different manifests, although a Web Publication will only have one manifest.
Although the manifest is the primary source of the infoset, some information may be obtained independent of it. For example, fallback rules for properties defined in the following subsections allow a user agent to compile information that the author has not provided in the manifest, whether as an intentional optimization or by accidental omission.
The Web Publication infoset MUST include the following information:
In addition, the infoset SHOULD include the following information:
These requirements reflect the current minimum consensus, though a number of issues remain open that could change whether an item is required or recommended. See the following sections for more information.
Whether the minimum manifest must include any metadata, or a specific slot to handle metadata. (Note: this is now more specifically related to the infoset.)
The title provides the human-readable name of the Web Publication.
When specified in the manifest, the title MUST be non-empty.
If a user agent requires a title and one is not available in the infoset, it MAY create one. This specification does not mandate how such a title is created. The user agent might:
title element found in the default reading order;A user agent is not expected to produce a meaningful title [WCAG20] for a Web Publication when one is not specified.
The language specified in the Web Publication's infoset identifies the natural language(s) of its content.
This language is not used in the processing or rendering of the Web Publication (including the manifest), and is not a replacement for identifying the language of each resource as defined by its format. It instead allows a user agent to ability to provide supplementary enhancements, such as the ability to download a custom dictionary or the preload a language-specific text-to-speech module.
When specified, the language MUST be a tag that conforms to [BCP47].
If a user agent requires the language and one is not available in the infoset, it MAY attempt to determine the language. This specification does not mandate how such a language tag is created. The user agent might:
If a language tag cannot be determined, the value "und" (undetermined) MUST be used.
The question is whether the language declared for the manifest content is the same as the language of the publication, and how to deal with multilingual publications.
A Web Publication's canonical identifier is a unique identifier that resolves to the preferred version of the Web Publication. The canonical identifier SHOULD be an address, but, if not, it MUST be possible to make a one-to-one mapping to an address (e.g., a DOI can be resolved to a URL via a DOI resolver).
If a Web Publication is hosted at more than one address, this identifier allows a user agent to identify the shared relationship between the versions and to determine which of the available addresses is primary.
The canonical identifier is also intended to provide a measure of permanence above and beyond the Web Publication's address. Even if a Web Publication is permanently relocated to a new address, for example, the canonical identifier will provide a way of locating the new location (e.g., a DOI registry could be updated with the new URL, or a redirect could be added to the URL of the canonical identifier).
When assigned, the canonical identifier needs to be unique to one and only one Web Publication, independent of its address(es). Ensuring uniqueness is outside the scope of this specification, however. The actual uniqueness achievable depends on such factors as the conventions of the identifier scheme used and the degree of control over assignment of identifiers.
If the canonical identifier is a URL, it can be used as the target of a "canonical" link [
rfc6596] (e.g., a [html] link element whose rel attribute has the value canonical or
a Link HTTP header field [rfc5988] similarly identified).
The question is whether a canonical identifier is necessary to call out explicitly in the infoset, or whether it is/can be handled by other metadata.
A Web Publication's address is a URL that refers to a Web Publication and enables the retrieval of a representation of the manifest of the Web Publication.
The availability of this address does not preclude the creation and use of other identifiers and/or addresses to retrieve a representation of a Web Publication in whole or part.
The infoset MUST include a list of the Web Publication's resources, although the list is not required to be exhaustive. Resources in the default reading order MUST be included in this list.
The discussion led to the question whether the manifest/infoset MUST list all resources or not. In this sense, this became a duplicate of issue #23 ended up at the same question.
The question is whether the manifest/infoset MUST list all resources or not.
The question is whether the manifest MUST list resources in the default reading order or whether this can be inferred.
The default reading order is a specific progression through a set of Web Publication resources.
A user might follow alternative pathways through the content, but in the absence of such interaction the default reading order defines the expected progression from one resource to the next.
The default reading order MUST include at least one resource.
The default reading order is either specified directly in the manifest or a link is provided to an [
html] nav element whose list of links are processed to create one.
The process for extracting a default reading order from a nav element are as follows:
href attribute of all
a elements;If a user agent requires a default reading order and one is not provided in the infoset, it MAY attempt to construct one. This specification does not mandate how such a default reading order is created. The user agent might:
nav element to use;Define the default reading order of a Web Publication to be the files referenced in the first
There is a consensus that a Web Publication must have a reading order and must/should have a table of contents (the main navigation entry point).
The table of contents provides access to major sections of the Web Publication. There are no requirements on the completeness of the table of contents, except that, when specified, it MUST link to at least one resource in the default reading order.
The table of contents is either specified directly in the manifest or a link is provided to an [html]
nav element containing one.
If a user agent requires a table of contents and one is not specified, it MAY construct one. This specification does not mandate how such a table of contents is created. The user agent might:
nav element that has the role attribute value
doc-toc);This question arises only if this mechanism is accepted: the question is whether a table of contents navigation element can refer, via links, to any resource that is not listed in the default reading order.
The issue of using the HTML nav element as a possible encoding of the table of contents is mentioned or explicitly addressed in a number of issues listed below.
Define the resources in the default reading order of a Web Publication to be the files referenced in the first
There is a consensus that a Web Publication must have a reading order and must/should have a table of contents (the main navigation entry point).
In addition the stated requirements the Web Publication Infoset SHOULD also provide the following publication metadata:
Section 3.10 of the current draft lists a number of additional metadata items as "should"-s. These may have to be considered as core and listed among the core infoset requirements.
Identifiers and modification dates are an important aid in the distribution and storage of portable formats (past, current, and present) so authors are urged to include this information whenever they can.
The infoset MAY also provide:
These items apply to the Web publication in its entirety. Metadata for individual content documents should be embedded in or linked from the content documents themselves.
The Web Publication Infoset SHOULD NOT include complex, specialised, and industry-specific metadata and authors should limit the metadata included in the manifest to the items above.
If the information set does not cover the publication's needs, authors should link to external metadata files in whichever formats and schema are most commonly accepted as the authoritative metadata format for their intended audiences. They can include multiple metadata links in multiple formats, one for each intended audience, if needed.
User Agents MAY decide to support metadata extensions, other metadata schemes, or additional metadata properties if they so choose. User Agents must ignore metadata properties that they do not recognise.
This section is non-normative.
A manifest is a specific serialization of a Web Publication's infoset.
The requirements for a conforming Web Publication manifest are as follows:
Should the manifest be in an external file, embedded in a specified manner, or should either option be allowed?
Should the table of contents be a separate HTML file or is the listing of resources in the default reading order an implicit table of contents?
In case the (concrete) manifest is expressed in JSON (see issue #7), should it be defined “on top” (i.e., as some form of an extension) of the Web Application Manifest specification, or should it be a fully separate specification?
If we have a collection of information about a web publication as a whole ("manifest") that exists separately from most of the publication's resources, we need to find a way to associate the manifest with the other publication resources.
The manifest serialization MUST provide a general linking mechanism for defining a relationship between the Web Publication and other resources on the Web as well as the type of those relationships.
This mechanism is used in to express many parts of the Web Publication's infoset, including but not limited to:
rel='canonical' link relation. [rfc6596]There are some overlaps between this list and, e.g., the separate section on canonical identifiers.
This linking mechanism may also be used to express other common link structures on the open Web. For example:
Some of these link structures, such as dynamic search links, may require support for URI templates [rfc6570] to be meaningfully useful in the context of a Web Publications. User agents should(?) support URI templates in order to make it easier for publishers to integrate dynamic server-side features into their publications with minimal coding and effort.
Need to determine intersection between web pubs and the lifecycle of a web app.
Placeholder for UA discovering and obtaining a manifest.
Placeholder for UA processing of manifest and creation of infoset.
Placeholder for UA initiating an enhanced reading experience.
Placeholder for UA updating manifest and/or WP content.
This section contains placholders for possible reading enhancements the UA may/should/must provide. The list is subject to addition, modification and removal as the enhancements get discussed in more detail.
Placeholder for offline reading of a publication.
Placeholder for inter-publication search.
This section needs thorough review not only from the publishing community to ensure that the proposed behavior is desirable, but also from Web Browser vendors and other implementors of layout engines to ensure that is it implementable.
The layout and rendering of Web Publications is governed by the usual rules that apply to all web content. [ HTML] (including XHTML) documents are styled and laid out according to the rules of CSS, [ SVG] files are rendered as normally expected of that format, and so on. 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 refrains from introducing any new layout feature. 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 recognizes that the features offered by CSS specifications have limitations, and that in some cases implementations may be incomplete. However, attempts to address these shortcomings for the exclusive purpose of Web Publications would at best have no effect, and at worst lead to a divergence between “ordinary” web content and Web Publications, instead of the convergence this specification aims to achieve.
This working group will work with other relevant groups of the W3C to address platform wide limitations that negatively impacts Web Publications, and invites readers to do the same.
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: For instance, CSS floats or Absolutely positioned elements from one resource may not intrude or overlap with content from an other resource.
Users must therefore rely on the UI features of the User Agent to navigate from one resource to another, rather than expect a collection of resources to be readable as if it were a single one.
This does not imply that User Agents are forbidden from juxtaposing the rendering of the various resources. Scrolling User Agents may for instance place renderings of the resources beneath each other in the default reading order, so that users may seamlessly scroll past the end of one and into the next one, as long as the layout of resources is processed independent. Similarly, paginating Users Agents can let users flip pages from one resource to the next, but must not display content from two or more separate resources on the same page.
Should this "UAs may juxtapose" phrasing be replaced with normative prose defining precisely how such juxtaposition work? On the one hand, interoperability is always good, on the other hand, this is an area with lots of subtleties and room for UI innovation. It may be wiser to let a first generation of UAs experiment freely, and standardize on the winning behavior in a future revision of this specification
This requirement of laying out each resource separately puts some constrains on authors’ abilities to arbitrarily style a Web Publication, and may appear to go against the principle of the separation of concerns. However, the alternative is not practical: CSS is not defined to work over a collection of documents, and numerous sections of the specifications would need rewriting to define the behavior of selectors, counters, floats, positioned elements…
An alternative approach would be to leave CSS work on a single document, but have that document be the Web Publication as a whole rather than its individual HTML constituents. This is however merely moving the problem around rather than solving it, as this specification would then need to define semantics for this unified document format separately from [HTML] including a DOM and assorted APIs, what to do with redundant or conflicting meta data from each each of the constituent part, not to mention a sensible way to merge resources of unrelated types, such as an HTML resource followed in the default reading order by an SVG resource, itself followed by a PNG image…
However, nothing forces authors to use separate resources for separate chapters of a book or similar semantic subdivisions of their publications, so this constraint on styling is easily worked around when subdivisions of a publication need to be blended together.
Despite this general requirement that each resource should be treated as a separate document for the purpose of layout, there are probably a handful of 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 one would be to allow counters to accumulate across multiple resources of a single Web Publication, for instance so that figures in multiple sections may be numbered in a single sequance.
This section is non-normative.
Web content, and a fortiori Web Publications, may be rendered on various media, each with differing characteristics, either due to the physical media itself or to the design of the User Agent. Web Publications are not constrained to any specific medium; User Agents are expected to render them as they would render other web content on the same medium. Authors can adjust the way they style their documents using the features specified in [MEDIAQ] or its successor [MEDIAQUERIES-4], as supported by the User Agent.
It is however worth calling out a major subdivision within media types: scrolling and paginating.
In scrolling media, when content overflows the initial containing block (See [CSS-DISPLAY-3]) it is exposed by allowing users to scroll to it. This behavior is typical of most desktop or mobile web browsers.
In paginating media, content is broken up into discrete pages, and content that overflows one page is displayed on subsequent pages. This behavior is typical of web content printed on paper, of the output of web-to-PDF renderers, and of many e-book reading systems.
Some User Agents may support both scrolling and pagination. As the preferences of individual readers vary, and as different types of publications may be better suited for one or the other, this specification encourages User Agents to support both, and to offer a choice to their users.
Authors or Publishers occasionally have strong preferences between scrolling and paginating for particular types of content, and may wish to require a publication to always be rendered in one or the other mode. This wish is not, however, something that Web Publication User Agents can effectively enforce. Since Web Publications are composed of backwards-compatible ordinary web content, legacy User Agents unaware of this specification will be able to open them, and will render them as they render any other content. Even Web Publication aware User Agents may only support for one of the two layout modes, and cannot be expected to honor requests to use the other one.
However, within the limits of the layout features supported by the user Agent used to render a publication, it is possible for authors to provide a page-like experience on scrolling media, using css features such as those defined in [CSS-MULTICOL-1] or [CSS-SCROLL-SNAP-1], or the viewport units defined in [CSS-VALUES-3].
It may nonetheless 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).
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 having unstyleable blank pages in the middle of the document, if the preceding resource ended 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 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 that supposed to work when subsequent resources have opposite page progression (See [CSS-PAGE-3]) direction, for instance 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 we've switched from English to Hebrew, this is going to be horribly confusing.
Should any of the above be normative, or should we leave this 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.
Pagination, like any other aspect of layout, is governed by the various CSS specifications, and is an integrated part of supporting CSS, rather than an isolated standalone feature. Nonetheless, a few specification are especially relevant for User Agents that wish to provide high quality support for paginated media:
This section is non-normative.
The following people contributed to the development of this specification:
The Working Group would also like to thank the members of the Digital Publishing Interest Group for all the hard work they did paving the road for this specification.