CSS Generated Content for Paged Media Module Level 4

Abstract

Status of this document

Table of Contents

Introduction

There have been many proposals for using CSS to move document content, often motivated by the desire for magazine- or book-style layout of footnotes, running heads, pull quotes, sidebars, and so on. [CSS3GCPM] used float: footnote and position: running(). The now-abandoned [CSS3GENCON] Working Draft used content: footnote. PrinceXML (and older GCPM drafts) has content: flow() and flow: static(). WHATWG CSS Books has flow: area().

This module proposes a unified approach to paginated layout based on [CSS3-REGIONS] and [CSS3-PAGE-TEMPLATE]. Additional properties will be introduced as necessary.

1 Running headers and footers

[CSS3GCPM] provides for copying the string values of elements into the existing page margin boxes.

The existing mechanisms do not cover many use cases.

1.1 Copying a flow: the flow-policy property

Headers often contain document content, and it is desirable to both display that content normally (for example, as an h1) and to use the content in a running head. [CSS3-REGIONS] only allows for an element to be moved to a named flow, so we add the flow-policy property to allow the same element to serve two roles.

Use cases for running heads can be found in [[LATINREQ] http://w3c.github.io/dpub-pagination/#content

extract

the element is taken out of its parent’s flow and placed into the named flow set by the value of the flow-into property.

copy

the element remains into it’s normal parent’s flow but a copy of the element is also extracted from there and placed into the named flow set by the value of the flow-into property.

h1 { 
  flow-into: chapter-title element; 
  flow-policy: copy;
  font-size: 1.5em;
}

@page {
  @top-center {
    flow-from: chapter-title;
    font-size: .9em;
    font-variant: small-caps;
    }
}

1.2 Making “sticky” headers: the flow-persist property

An element flowed into a running head should appear on every page until the value of the element changes, at which point the new value should be used. We define the flow-persist property to control how content is rendered in region chains (????).

We also need to specify which element is used in a running head, when there are multiple possibilities. [CSS3GCPM] defines start, first, last, and first-except values.

normal

Content from the named flow is rendered as described in [CSS3-REGIONS].

persist

Eligible content from the named flow is placed into the first box of the region chain as usual. If there is no eligible content on subsequent pages, the last-used content is used in the region box until new eligible content appears.

“That is not what I meant at all; That is not it, at all.” —T.S. Eliot

static

The first instance of the element is used in every region associated with the region chain (this is the equivalent of flow-options: static in [PGT]).

Above definitions need work

first

The value of the first assignment on the page is used. If there is no assignment on the page, the entry value is used. first is the default value.

start

If the element is the first element on the page, the value of the first assignment is used. Otherwise the entry value is used. The entry value may be empty if the element hasn’t yet appeared.

last

The exit value is used.

first-except

This is identical to first, except that the empty string is used on the page where the value is assigned.

h1 { 
  flow-into: chapter-title element; 
  flow-policy: copy;
}

@page {
  @top-center {
    flow-from: chapter-title;
    flow-persist: persist start;
    }
}

2 Creating Page Areas

[CSS3-PAGE-TEMPLATE] introduces @template and @slot rules. We propose to allow the use of @slot in the @page context, to allow greater flexibility than the page margin boxes in [CSS3PAGE]. These slots can also be used for sidenotes, pull quotes, footnotes, and many other document features.

@page body {
  @slot center-header {
    top: 0px;
    left: 1em;
    right: 1em;
    height: 2em;
    flow-from: header;
    flow-persist: persist;
    wrap-flow: clear;
  }
}

Is there a need for both @page and @template?

3 Footnotes

3.1 Terminology

Footnotes are complex objects, so it will be helpful to define some terms before proceeding.

footnote element

The element containing the content of the footnote, which will be removed from the flow and displayed as a footnote.

footnote marker (also known as footnote number)

A number or symbol adjacent to the footnote body, identifying the particular footnote. The footnote marker should use the same number or symbol as the corresponding footnote call, although the marker may contain additional punctuation.

footnote body

The footnote marker is placed before the footnote element, and together they represent the footnote body, which will be placed in the footnote area.

footnote call (also known as footnote reference)

A number or symbol, found in the main text, which points to the footnote body.

footnote area

The page area used to display footnotes.

footnote rule (also known as footnote separator)

A horizontal rule is often used to separate the footnote area from the rest of the page. The separator (and the entire footnote area) cannot be rendered on a page with no footnotes.

3.2 Footnotes as Regions

<p>Though the body was erect, the head was thrown back so that the closed eyes were pointed towards the needle of the tell-tale that swung from a beam in the ceiling..<span class="reference"><span class="footnote">The cabin-compass is called the tell-tale, because without going to the compass at the helm, the Captain, while below, can inform himself of the course of the ship.</span></span></p>

span.footnote {
  flow-into: footnote;
  flow-policy: copy;
  display: block;
}

span.footnote::before {
  content: counter(footnote) '. ';
}

span.reference::before {
  content: counter(footnote);
  font-variant-position: super;
}

@page {
  @slot footnote {
    flow-from: footnote;
    required-flow: footnote;
    position: absolute;
    left: 54pt;
    bottom: 0pt;
    width: 352pt;
    height: auto;
    border-top: .25pt solid black;
    vertical-align: bottom; 
    wrap-flow: clear;
  }
}

The above HTML contains two nested spans for the footnote, as CSS has no mechanism to leave a reference object where something was removed from the flow.

Would it be possible to specify flow-into: none on span.footnote::after? [CSS3-REGIONS] forbids the flow-into property on pseudo-elements, but should that be changed?

span.footnote {
  flow-into: footnote;
  display: inline;
}

Acknowledgments

Tab Atkins, Jr., Håkon Wium Lie, Liam Quin, Peter Sorotokin, Alan Stearns

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words "for example" or are set apart from the normative text with class="example", like this:

Informative notes begin with the word "Note" and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Advisements are normative sections styled to evoke special attention and are set apart from other normative text with <strong class="advisement">, like this: UAs MUST provide an accessible alternative.

Conformance classes

Conformance to this specification is defined for three conformance classes:

style sheet

A CSS style sheet.

renderer

A UA that interprets the semantics of a style sheet and renders documents that use them.

authoring tool

A UA that writes a style sheet.

A style sheet is conformant to this specification if all of its statements that use syntax defined in this module are valid according to the generic CSS grammar and the individual grammars of each feature defined in this module.

A renderer is conformant to this specification if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by this specification by parsing them correctly and rendering the document accordingly. However, the inability of a UA to correctly render a document due to limitations of the device does not make the UA non-conformant. (For example, a UA is not required to render color on a monochrome monitor.)

An authoring tool is conformant to this specification if it writes style sheets that are syntactically correct according to the generic CSS grammar and the individual grammars of each feature in this module, and meet all other conformance requirements of style sheets as described in this module.

Partial implementations

So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported component values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.

Experimental implementations

To avoid clashes with future CSS features, the CSS2.1 specification reserves a prefixed syntax for proprietary and experimental extensions to CSS.

Prior to a specification reaching the Candidate Recommendation stage in the W3C process, all implementations of a CSS feature are considered experimental. The CSS Working Group recommends that implementations use a vendor-prefixed syntax for such features, including those in W3C Working Drafts. This avoids incompatibilities with future changes in the draft.

Non-experimental implementations

Once a specification reaches the Candidate Recommendation stage, non-experimental implementations are possible, and implementors should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec.

To establish and maintain the interoperability of CSS across implementations, the CSS Working Group requests that non-experimental CSS renderers submit an implementation report (and, if necessary, the testcases used for that implementation report) to the W3C before releasing an unprefixed implementation of any CSS features. Testcases submitted to W3C are subject to review and correction by the CSS Working Group.

Further information on submitting testcases and implementation reports can be found from on the CSS Working Group’s website at http://www.w3.org/Style/CSS/Test/. Questions should be directed to the public-css-testsuite@w3.org mailing list.

References

Normative References

Informative References

Index

Property index

Issues Index