Abstract

This module describes features often used in printed publications. In
particular, this specification describes how CSS style sheets can express
named strings, leaders, cross-references, footnotes, endnotes, running
headers and footers, named flows, ad hoc counter styles, paged-based
floats, hyphenation, change bars, named page lists, and generated lists.
Along with two other CSS3 modules — multicolumn layout and paged
media — this module offer a way of presenting structured documents
on paged media.

Status of this document

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 http://www.w3.org/TR/.

Publication as a Working 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.

The (archived) public
mailing list www-style@w3.org (see
instructions) is preferred
for discussion of this specification. When sending e-mail, please put the
text “css3-gcpm” in the subject, preferably like this:
“[css3-gcpm] …summary of
comment…”

This WD describes functionality at various levels of maturity. Some
features have been part of other WDs in the past and have already been
implemented. Other features are merely at the brainstorming stage. In
general, features presented earlier in this draft are more mature that
those presented later in the draft.

1. Dependencies on other
modules

2. Introduction

(This section is not normative.)

This specification describes various functionality which is commonly
used in paper-based publishing. Some of the proposed functionality (e.g.,
hyphenation and ad hoc counter styles) can also be used with other media
types.

This is a very early and preliminary proposal that still needs a lot of
work and we would especially welcome feedback from the community that
works on document specifications.

3. Named strings

To aid navigation in printed material, headers and footers are often
printed in the page margins. [CSS3PAGE] describes how to place
headers and footers on a page, but not how to fetch headers and footers
from elements in the document. This specification offers two ways to
achieve this. The first mechanism is named strings which copies
the text (and not style, structure, or replaced content) from one element
for later reuse. Named strings are described in this section. Later, a
mechanism for moving elements (including its style and structure) into a
running headers/footer is described.

Named strings can be thought of as variables that can hold one string of
text. Named strings are created with the 'string-set' property which copies a string of text
into the named string. Only text is copied; not style, structure, or
replaced content. The only reason for creating a named string is to
display the string later by using the 'content' property.

There should be a more specific description of how to get to
the text. For example, should all white space be preserved?

The 'string-set' property
accepts a comma-separated list of named strings. Each named string is
followed by a content list that specifies which text to copy into the
named string. Whenever an element with value of 'string-set' different from 'none' is encountered, the named strings are assigned
their respective value.

For the 'string-set' property,
<content-list> expands to one or more of these, in any order:

<string>: e.g. "foo"

<counter>: counter() or counters()

<content>: can be one or more of these, in any order:

'content()' returns the textual content of the element, not
including the content of its ::before and ::after pseudo-element. The
content of the element's descendants, including their respective
::before and ::after pseudo-elements, are included in the returned
content.

'before()' returns the content of the element's ::before
pseudo-element

'after()' returns the content of the element's ::after
pseudo-element

'first-letter()' returns the first letter of the textual content of
the element, not including the content of its ::before and ::after
pseudo-element. The definition of a letter is the same as for
:first-letter pseudo-elements. The expected use for this function is to
create one-letter headers in, e.g., dictionaries.

The parenthesis are there for two reasons; they give a sense
of something being returned, and they allow parameters to be added in the
future. Still, should the parenthesis be optional?

If the value of the named string is changed by an element on a certain
page, the named string may have several values. In order to specify which
of these values should be used, an optional argument is accepted on the
'string()' value. This argument can have one of
three keywords:

'start': the named string's entry value for
that page is used. This is the default value.

'first': the value of the first assignment is
used. If there is no assignment on the page, the start value is used.

4. Leaders

A leader is a visual pattern that guides the eye. Typically, leaders are
used to visually connect an entry in a list with a corresponding code. For
example, there are often leaders between titles and page numbers in a
table of contents (toc). Another example is the phone book where there are
leaders between a name and a telephone number.

In CSS3, a leader is composed of series of glyph through the 'leader()' value on the 'content'
property. The functional notation accepts one value which describe the
glyph pattern that make up the leaders. These values are allowed:

leader(dotted)

leader(solid)

leader(space)

leader(<string>)

Using the keyword values are identical to setting a string value. The
table below shows the equivalents:

Keyword

String

Comment

leader(dotted)

leader('. ')

Note the space character inside the string

leader(solid)

leader('_')

leader(space)

leader(' ')

The string consists of one space character

Some fonts may not have suitable glyphs for all patterns.
For example, in some Eastern languages, the alignment of the shape within
the glyph may not be optimal for creating leaders. Perhaps the keywords
should refer for an abstract form rather than a string?

The string inside the parenthesis is called the leader string.

In its simplest form, the 'content' property
only takes one 'leader()' value:

heading::after { content: leader(dotted) }

The leader string must be shown in full at least once. To fill the
available space, the leader string is repeated as many times as possible.
At the end of the leader, a partial string pattern may be shown. Or, partial strings be avoided? White space in leaders
must not be collapsed. However, if the leaders contains any
non-white-space characters, white space characters at the beginning and
end of a leader must be removed.

Perhaps white space should be preserved?

Note that white space is only removed at the end of the leader, not the
leader string. Consider these two rules.

If the leaders are only displayed once, the two rules above yield the
same result because the space character at the end of the first leader
string is removed. If the leaders are repeated, the second rule yields an
uneven leader pattern due to no space character in the joint between two
leader strings.

These properties influence the appearance of leaders: all font
properties, text properties, 'letter-spacing',
'background', and 'color'. The 'leader()' value
accepts an optional second argument to determine from which element
property values are borrowed from. The argument can be one of these:

'current': Property values are borrowed from
the (pseudo-)element where the 'leader()' value is
used. This is the default value.

'root': Property values are borrowed from the
root element.

Is there a better element to use than the root element?
Perhaps the initial value of the various properties?

The leaders generated by h1 and h2 elements will have
the same appearance as they both reference the root element. Leaders
generated by h3 and h4 will borrow property values from
their respective pseudo-elements.

Should other properties influence the appearance of leaders?

Should we prescribe leader alignment so that, in horizontal
scripts, leaders are aligned horizontally?

In a more complex example, the 'leader'
value is combined with other values on the 'content' property:

If the name and number end up on different lines (e.g., in a narrow
column), it may be formatted like this:

John Doe....
...123456789

To determine the length of the leaders, user agents must do the
following for each line:

Lay out the content with minimum leaders

Determine the empty space left on the line.

Distribute the empty space between the leaders on the line. Glyphs
must not be shown partially. All leaders on the line should, to the
extent possible, have the same length. This may not always be possible as
leader strings must be displayed in full at least once.

5. Cross-references

It is common to refer to other parts of a document by way of a section
number (e.g,, "See section 3.4.1"), a page number (e.g,, "See discussion
on page 72"), or a string (e.g., "See the chapter on Europe"). Being able
to resolve these cross-references automatically saves time and errors.

Cross-reference are generated by styling the source anchor of a link in
a special way. Instead of styling the source anchor by (say) showing it
underlined in blue, the style sheet can (say) specify that the source
anchor should be presented with a page number. For example, the string "
(see page 72)" could be added to the link.

Numerical cross-references are generated by 'target-counter' which fetches the value of a counter at
the target end of the link. It has two required arguments: the url of the
link, and the name of a counter. An optional third argument indicates
which list style type to use when presenting the resulting number; 'decimal' being the default.

Textual cross-references are generated by 'target-string' which fetches the textual content from
the target end of the link. Only text is copied; not style, structure, or
replaced content. 'target-string' has one required
argument: the url of the link. An optional second argument specifies
exactly which content is generated. There are four possible values:

''content()'' returns the textual content of the element, not
including the content of its ::before and ::after pseudo-element. The
content of the element's descendants, including their respective ::before
and ::after pseudo-elements, are included in the returned content.

''before()'' returns the content of the element's ::before
pseudo-element

''after()'' returns the content of the element's ::after
pseudo-element

''first-letter()'' returns the first letter of the textual content of
the element, not including the content of its ::before and ::after
pseudo-element.

6. Footnotes

Footnotes is another device used in traditional printing. A footnote is
a note placed at the bottom of a page that comments on or cites a
reference for a designated part of the text. References to footnotes are
marked with a footnote call in the main text.

In order to support footnotes in CSS, the following functionality is
added:

one new value on the 'position' property:
'footnote'

one new page area: '@footnote'

two new pseudo-elements: '::note-call' and
'::marker'

one predefined counter called 'footnote'

There has been a number of proposals for these names.
Instead of the 'position' property, these
properties have been proposed: 'flow', 'float', 'display'.

An element with 'position: footnote' (called the
footnote element) is moved to the @footnote area and a marker is
put in its original place.

span.footnote {
position: footnote;
}

6.1. Note calls

When an element is moved to the footnote area, a footnote call
is left behind. In order to use terminology that is also suitable for
endnotes (described below), they are referred to as note-calls in
this specification.

Any white space characters between the note-call and and the preceding
content is removed.

The goal is to achieve this result:

... some notion¹

rather than this:

... some notion ¹

The content and style of the note-call is set on the 'note-call' pseudo-element.

Is there a better name than "note-call"? It gives
associations to music and telephones rather than footnotes.

6.2. Markers

The ::marker pseudo-element is placed before the footnote element. It
typically contains the same numbers/symbols as the note-call
pseudo-element to link the two together.

.footnote::marker {
content: counter(footnote, super-decimal);
}

The position of ::marker elements is determined by the value of the
'list-style-position' on the footnote element.
If the value is 'inside', the ::marker
pseudo-element is positioned similar to ::before pseudo-elements. If the
footnote element also has a ::before pseudo-element, ::marker comes before
it.

This may be overloading the 'list-style-position' property. If we want to have
more markers per elements (e.g., for continuation markers) we need the
'list-style-position' property for other
purposes. Perhaps we could use 'list-style-position' on the ::marker element
itself?

If the value of 'list-style-position' is 'outside', the margin, border and padding properties are
used to determine the exact position of the marker. Exactly how?

.footnote {
list-style-position: outside;
}

6.3. The 'super-decimal' value

A new list-style-type, 'super-decimal' is used
above. Small, superscripted footnote calls are common; the first three
numbers have code points in Latin-1 and some font families have even more
glyphs. The 'super-decimal' keyword allow these
font resources to be used and replaces 'font-size' and 'vertical-align' (which prohibit the use of
special-purpose glyphs).

6.4. The footnote area

All elements with 'position: footnote' are moved
to boxes with 'content: pending(footnote)'.
Typically, this is the case for the @footnote area.

@footnote { content: pending(footnote) }

The footnote area is found at the bottom of the page area. Potentially,
every page has a footnote area. If there are no footnotes on the page, the
footnote area will not take up any space. If there are footnotes on a
page, the layout of the footnote area will be determined by the
properties/values set on it, and by the footnote elements elements inside
it.

In published books, it is customary for the footnote area to be limited
to less than half the height of the page area. Long footnotes may need
more space, and the customary solution is for footnotes to span several
pages. To achieve this, the 'max-height'
property should be used. However, footnotes spanning several pages is an
advanced feature which is not a conformance requirement for this
specification.

Should there also be a footnote border style to
achieve that solid line that partially extends across the top from the
left? This kind of border would possibly also be useful for other
elements. Here are some ideas:

There should also be a way to define the footnote area so
that it appears inside a column, rather than across the whole page.

6.5. The footnote counter

Footnotes are counted with a predefined 'footnote' counter. When an element with 'position: footnote' is encountered, the 'footnote' counter is automatically incremented. An
element with 'position: footnote' inherits from its
parent, not from @footnote.

The reason for having a predefined "footnote" counter is to
avoid having to set "counter-increment: footnote" every time one sets
"position: footnote". However, is this a good enough reason?

The footnote counter can be reset on a page basis.

@page { reset-counter: footnote }

7. Endnotes

Endnotes are similar to footnotes, except that they are placed at the
end of a section rather than at the bottom of a page. Some documents use
both footnotes and endnotes.

To support endnotes, a new value on 'position' is proposed.

span.footnote {
position: endnote;
}

Elements with 'position: endnote' are moved to
where 'content: pending(endnote)' is set.

div.chapter::after {
content: pending(endnote);
display: block;
}

If 'content: pending(endnote)' is not set,
elements are moved to the end of the document.

Like for footnotes, a ::note-call pseudo element is left at the place of
origin.

Like for footnotes, a predefined 'endnote'
counter is incremented for every element with 'position:
endnote'.

Like for footnotes, a ::marker pseudo-element is generated at the place
of presentation.

Like for footnotes, the content of ::note-call and ::marker
pseudo-elements must be set with the 'content'
property.

8. Running headers and footers

Headers and footers can be achieved through named strings, as described
above. However, named strings only hold textual content; any style,
structure or replaced content associated with the element is ignored. To
overcome this limitation, a way of producing running headers and footers
by way of moving elements is introduced.

Unlike footnotes and endnotes, elements that are moved into headers and
footers are repeated on several pages; they are said to be
running. To support this, a new value — running() —
is introduced on the 'position' property. It
has one required argument: the name of the running flow which it creates.
The content of the running flow can be fetched by way of the 'pending(<flow>)' value.

The header is "Not now" from the outset, due to the "div" element. The
first "span" element changes it to "NOW!"on the page where the
"span" element would have appeared (due to the 'this-page' keyword). The second "span" element, which
would have appeared on the same page as the first, changes the header back
to "Not now". However, the change only takes affect on the next page due
to the 'next-page' keyword.

The differences and similarities between named string and
running headers/footer (RHF) deserve more thinking. Currently, named
strings are driven from the margins, while RHF are driven from the
content. That is, for named strings, an argument (start/first/last) in the
page context determines exactly which string is used in the header. For
RHF, an argument on the element (next-page/this-page) determines exactly
which content is used in the header. I believe both mechanism are useful.
However, it is arbitrary that one mechanism is tied to unstyled strings
and the other is tied to elements.

9. Named flows

It is sometimes useful to move elements out of their normal flow and
into other containers. CSS is not a transformation language, so the
motivation for supporting flows is presentational rather than
structural. Mechanisms to support footnotes, endnotes and running headers
and footers — which are conventional ways of moving content —
have been described above. In this section, a more generic mechanism
called named flows is described.

Not quite described yet, but at least an example is provided

P.side { position: flow(side) }
DIV.side {
content: pending(side);
}

Elements that are moved into a new flow are removed from their current
position to where 'pending(<flow>)' has been
set. Like for footnotes and endnotes, elements that are moved into a named
flow are only displayed once.

If 'pending(<flow>)' isn't set
anywhere, the content should be place at the end?

Should a ::note-call be left in the original location?

Should it be possible to add footnotes/endnotes by way of
named flows?

10. Ad hoc counter styles

Background: CSS defines a number of predefined list style types for the
'list-style-type' property and other places
where a list-style-type value is accepted. Some styles repeat the same
glyph (e.g., 'disc' and 'circle') while others have lists of glyphs (e.g., 'decimal', and 'lower-roman'). To
increase the range of lists that can be achieved through CSS without
adding lots of new keywords, @counter-style rules are introduced. By using
@counter-style, a style sheet can define ad hoc counter styles.

An @counter-style rule consists of the keyword '@counter-style', followed by the name of the symbol
counter style, followed by a space-separated list of strings.

The first string in the list represents number one, the second string
represents number two, etc. If a counter has a value less than one, or
greater than the number of strings in the list, the rendering will be as
if the 'decimal' list style type had been
specified.

For a series of list-item elements inside an
ordered-list element, the value of the items counter
will be -1, 1, 3, 5, 7 etc. Given that the ordinal counter style
only defines a counter style for 1, 2, 3, and 4, the list will be
numbered "-1", "1st", "3rd", "5", "7" etc.

Should it be possible to specify ad hoc counter styles
without naming them?

ol { list-style: "*" "\2020" "\2021" "\A7" "#" }

11. Page-based floats

Background:

The 'float' property is extended with
several new values:

inside

The element generates a block box that is floated to the inside of the
page. On a right page, it means the left side, and on a left page it
means the right side.

outside

The element generates a block box that is floated to the outside of
the page. On a right page, it means the right side, and on a left page it
means the left side.

top

The element generates a block box that is floated to the top of the
page.

bottom

The element generates a block box that is floated to the bottom of the
page.

next

The float is placed on top of the next page from its source location.
If combined with 'bottom', the float is placed on
the bottom of the next page.

img {
float: next; /* float to the top next page */
float: top next; /* float to the top next page */
float: next top; /* float to the top next page */
float: next bottom; /* float to the bottom of the next page */
float: outside top; /* float to the top of the current page, away from the binding */
float: next bottom left; /* float to the bottom left of the next page
float: bottom left right; /* illegal, ignored */
}

If no horizontal value is specified, other content will not be placed to
the left or right of the float.

If no vertical value is specified, the float will appear according to
CSS 2.1.

12. Crop marks

13. Change bars

14. Markers

Markers of various kinds are often used in publishing. Footnotes,
endnotes and list items in general are preceded by markers. Markers are
also used to indicate that an element continues onto a subsequent page, or
that it continues from a preceding page.

The ::marker pseudo-element is described here.

15. Continuation markers

Describe continuation markers. Do we need two new
pseudo-elements, or is ::marker enough?

Continuation markers are used to indicate that an element continues from
one page to the next.

Should we have continuation markers for columns as well?

16. Named page lists

In CSS 2.0, the 'page' property takes one
value. The value can be 'auto' or a named
page. In the case where a named page is specified, a page break is
inserted and the element is put on the named page.

In this specification, a list of values is allowed in the 'page' property. As content is laid out and new
pages are generated, the list is traversed linearly starting at the first
list item. One page is created per item in the list. If more pages are
required than there are items in the list, the last item is repeated as
many times as necessary.

h2 { page: no-header auto }

This means: the content of an h2 element should be laid out on a 'no-header' page, thereafter the auto page (which
is the initial value). The last value (auto) is repeated if there is need
for more pages.

The last value in the list becomes the leaving value which is
compared with the first item the 'page'
property of the next element. If those two values are different, a page
break is generated.

Consider this example:

h2 { page: no-header auto }
p { page: auto }
<h2>foo</h2>
<p>bar</p>

There would be no page break between H2 and P elements as the last
named page on H2 is the same as the first (and only) named page on the P
element.

17. Generated lists

Books typically have sections that are extracted from the main content,
for example, a the table of contents (toc) in the front and an index at
the back. Also, there are glossaries and lists of figures (lof) and lists
of tables (lot). These sections can all be referred to as generated
lists; they are generated from the main content, and have the nature
of lists. Some lists are sorted alphabetically (e.g., an index and a
glossary), and others reflect the order of the content (toc, lof, lot).

To generate lists in CSS, a prototype container must be
established. Other elements will be flowed into the prototype container,
but it can also contain content of its own. Elements with a 'make-element' value other than 'none' will generate an element inside a prototype
container. The value of 'make-element' is the
ID of a prototype entry element which is replicated inside the
prototype container, and a specification of the content which is to be
inserted into the generated list.

17.1. TOC

Here is an example of how to generate a toc with leaders and page
numbers.

There are three new properties and one new value on the 'content' property in the above example. This rule:

#toc { prototype: container }

declares that the #toc element is a prototype container that accepts
generated lists. Prototype containers cannot be nested. Each container
keeps a position of where the last generated list item was added. This
rule:

prototype-insert-position: current;

specifies that entities in the #toc are to be added at the current
position, i.e., after the previous generated list item. This code:

#toc-entry::after { content: leader('. ') source-counter(page) }

has one new value (''source-counter(page)'') which fetches the value of
the 'page' counter from the source element, i.e.,
the element which has a 'make-element'
declaration:

h1.chapter { make-element: toc-entry content() }

The above rule creates one new element. The new element is isomorphic to
the #toc-entry element and is inserted according to the 'prototype-insert-position' of #toc-entry.

17.2. Glossary

Glossaries provide a new kind of challenge: entries are sorted
alphabetically.

By inserting the term 'sorted' and the
definition in the 'current' position, terms will
be sorted alphabetically with their respective definition following.

17.3. Index

An index is a generated list that is sorted alphabetically, just like
glossaries. In addition, indexes often have single letters in large font
sizes to help humans navigate. For example, all index entries starting
with "s" is placed under a large capital "S". There should only be one
large capital "S", and if there are no index entries starting with "s" the
large "S" isn't shown.

To achieve this kind of presentation, the following strategy is
suggested: for every index entry that is encountered, two elements are
generated. One is the large capital letter, and the other is the index
entry itself. To avoid having one large capital letter before each index
entry, the 'insert-policy' property declares
that identical generated list elements are to be deleted.

17.4. A more complex example

Here is a more complex example with several types of generated lists.
Note how multilevel tocs require a prototype container without any
additional content. Also, notice how the "acronym" element generates an
entry both in the index and in the list of acronyms.

18. Conformance

19. Appendix A: On generic vs.
specific mechanism

One group of features in this specification (namely footnotes, endnotes,
running headers/footers, and named flows) warrants a discussion on general
vs. specific mechanisms. These are all about moving elements from one
place in the document to another. One question that quickly arises is
whether to construct one generic "moveto" mechanism or several more
specific mechanisms. The benefits of having one generic mechanism is fewer
new properties/values, and (perhaps) innovative uses of the mechanism. The
benefits of having separate mechanisms is that traditional layout
conventions can be incrementally supported. For example, if a new footnote
convention is discovered in the future, it can be supported in the future
as long as it is known that the element is a footnote (as opposed to just
a moved element).

The following table highlights some important differences between
footnote, endnotes and running headers/footers:

Replicate element on several pages?

Add or replace?

Leave "calls" where element is moved from?

Magic white space handling around "calls"?

Magic page transition in new location? (due to multiple footnotes
spanning several pages)

Primary target

Footnotes

no

add

yes

yes

yes

new "footnote" area

Endnotes

no

add

yes

yes

no

::after pseudo-element

Running headers/footers

yes

replace

no

N/A

no

margin boxes

(The table could have had more columns. As it stands, however, it
illustrates the problem of designing one mechanism to solve all cases.)

Based on the table, one can conclude that a generic "moveto" mechanism
can support all this functionality as long as it supports (a) the
replication of elements, (b) a switch to determine whether a moved element
is added to a list or replaces other elements (c) leaving "calls",
possibly with (d) magic white space handing around them, (e) magic page
transitions, and (f) a way of specifying where the element should be moved
to.

Not all implementations would be expected to support all the
functionality (for example, supporting magic page transitions is hard),
but it must be allowed. In a generic mechanism, a large set of parameters
must therefore be specified. This is not ideal as style sheet designers
would have to specify highly specialized parameters which would be
meaningless for most uses of the mechanism.

The approach taken by this draft is twofold. First, a generic mechanism
for moving elements into named flows is offered. Second, specific
mechanisms are offered for footnotes, endnotes and running
headers/footers. To avoid a proliferation of properties, all mechanisms
are specified on the 'position' property.

Acknowledgments

This document has been improved by Bert Bos, Michael Day, Melinda Grant,
David Baron, Markus Mielke, Steve Zilles and Ian Hickson. [more to be
added]