CSS3 module: Generated Content for Paged Media

W3C Working Draft 12 June 2006

This version:
Latest version:
Håkon Wium Lie, Opera Software, howcome@opera.com


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 document was produced by the CSS Working Group (part of the Style Activity).

This document was produced by a group operating under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. 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 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.

This is the first public Working Draft.

Table of contents

1. Dependencies on other modules

This CSS3 module has non-normative (informative) references to the following other CSS3 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?

3.1. Setting named strings

The 'string-set' property is defined as follows:

Name: string-set
Value: [[ <identifier> <content-list>] [, <identifier> <content-list>]* ] | none
Initial: none
Applies to: all elements
Inherited: no
Percentages: N/A
Media: all
Computed value: as specified value

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:

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?

h1 { string-set: header "Chapter " counter(chapter) content() }
dt { string-set: index first-letter(), entry content() }

3.2. Using named strings

The content of named strings can be recalled by using the 'string()' value on the 'content' property. The 'string()' value has one required argument, namely the name of the string.

@page { @top-center { content: string(header) }}
@page { @right-middle { content: string(index) }}
@page { @top-left { content: string(entry) }}
h1 { string-set: header "Chapter " counter(chapter) content() }
dt { string-set: index first-letter(), entry content() }

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:

@page { @top-left { content: string(entry, first) }}
@page { @top-center { content: string(index) }}
@page { @top-right { content: string(entry, last) }}
dt { string-set: index first-letter(), entry content() }

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:

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.

dt:after { content: leader('. . . ') }
dt:after { content: leader('. . .') }

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:

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

Consider these rules:

h1::after { content: leader(dotted, root) }
h2::after { content: leader(dotted, root) }
h3::after { content: leader(dotted) }
h4::after { content: leader(dotted, current) }

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:

ul.toc a::after {
  content: leader('. . . ') target-counter(attr(href), page);

If the content connected by a leader end up on different lines, the leader will be present on all lines.

Consider this code:

.name::after { content: leader(dotted) }
<div class="entry">
<span class="name">John Doe</span>
<span class="number">123456789</span>

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

John Doe....

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

  1. Lay out the content with minimum leaders
  2. Determine the empty space left on the line.
  3. 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.
  4. Fill the empty space with the specified leader pattern.

Consider this code:

cite::before { content: leader('  ') }
  Bla great bla bla world bla bla
  empire bla bla color bla bla
  history bla bla forever.
    <cite>John Johnson</cite>

Depending on the width of the containing block, this may be rendered as:

  Bla great bla bla world bla bla
  empire bla bla color bla bla
  history bla bla forever.   John 

However, this rendering is preferable:

  Bla great bla bla world bla bla
  empire bla bla color bla bla
  history bla bla forever.
                     John Johnson

To indicate that John Johnson should be kept on one line, this rule can be added to the style sheet:

cite { text-wrap: suppress }

Until 'text-wrap' is widely supported, this rule can also be used:

cite { white-space: nowrap }

Here is another pleasant rendering of this example:

  Bla great bla bla world bla bla empire
  bla bla color bla bla history bla bla 
  forever.                  John Johnson

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.

Here is the CSS code to achieve this on common HTML markup:

a::after { content: "(see page " target-counter(attr(href), page, decimal) ")" }

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:

The default value is 'content()'.

To generate this text

See Chapter 3 ("A better way") on page 31 for an in-depth evaluation.

from this markup:
<p>See <a href="#chx">this chapter</a> for an in-depth evaluation.
<h2 id="chx">A better way</h2>
this CSS code can be used:
h2 { counter-increment: chapter }
a { content: "Chapter " target-counter(attr(href), chapter) 
   ' ("'  target-string(attr(href), content()) '") on page '
   target-counter(attr(href), page);

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:

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.

span.footnote::note-call {
  content: counter(footnote, super-decimal)

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.

These properties apply to the footnote area: 'content', 'border', 'padding', 'margin', 'width', 'max-width', 'min-width', 'height', 'max-height', 'min-height'.

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.

Here is an example of a styled footnote area:

@footnote {
  border-top: thin solid black;
  padding-top: 0.6em;
  margin-top: 0.6em;
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:
  content: "____";
  border-image: url(short-line);
  footnote-rule: 20%;
  border-top: thin solid black / 20%;

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.

title { position: running(header) }
@page { @top-center {
content: pending(header); }

To support conventions for running headers and footers, 'running()' accepts an optional second argument which can be one of three keywords:

the element is repeated starting from this page; this is the default value
the element is repeated starting from the next page

Often, a running header should not appear on the first page of a chapter. To achieve this effect, this markup:

<div class="chapter">Introduction</div>
<div class="header">Introduction</div>

can be combined with this style sheet:

div.header { display: none }
@media print {
div.header {
  display: block;
  position: running(header, next-page);
@page { @top-center { content: pending(header) }}

This code illustrates how to change the running header on only one page.

@page { @top-center {
  content: pending(header) }}
.header { 
  position: running(header, next-page) }
.once { 
  position: running(header, this-page);
  font-weight: bold }
<div class="header">Not now</div>
<p>Da di ha di da di ...
  <span class="header once">NOW!</span>
  <span class="header">Not now</span>
  ... da di ha di hum.</p>
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.

@counter-style daggers "*" "\2020" "\2021" "\A7" "#";
ol { list-style-type: daggers }
@counter-style ordinal "1st" "2nd" "3rd" "4th";
h1:before { content: counter(chapter, ordinal) " chapter" }

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.

Consider this example:

@counter-style ordinal "1st" "2nd" "3rd" "4th";
ordered-list { counter-reset: items -1 }
list-item { counter-increment: items 2 }

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


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

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.
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.
The element generates a block box that is floated to the top of the page.
The element generates a block box that is floated to the bottom of the page.
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.

These values can appear along with the existing values on 'float'. The possible value combinations are: [[ left | right | inside | outside ] || [ top | bottom ] || next ] ] | none | inherit

Here are some examples of how the new values can be used:

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

The 'marks' property from [CSS2] should be supported.

13. Change bars

The XSL properties for change bars should be considered for reuse.

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 }


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.

  #toc { prototype: container }
  #toc-entry { 
    prototype-insert-position: current;
    font-size: 14pt }
  #toc-entry::after { content: leader('. ') source-counter(page) }
  h1.chapter { make-element: toc-entry content() }
<div id="toc">
  <h1>Table of contents</h1>
  <div id="toc-entry"></div>
<h1 class="chapter">Introduction</h1>

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.

Here is an example of how to generate a glossary:

#glossary { prototype: container }
#glossary-term { insert-position: sorted }
#glossary-definition { insert-position: current }
<div id="glossary">
<h2>Glossary of terms</h2>
  <dt id="glossary-term">...</dt>
  <dd id="glossary-definition">...</dd>
<h1 class="chapter">Introduction</h1>

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.

#index {
  prototype: container }
#index-marker {
  insert-position: sorted 
  insert-policy: unique; 
  text-transform: uppercase }
#index-entry {
  insert-position: sorted }
#index-entry::after {
  content: leader(. . ) source-counter(page) }
dfn.entry { 
  make-element: index-marker first-letter(), index-entry content() }
<p>An <dfn>emphasized element</dfn> stands out.</p>

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.

#toc-container {
  prototype: container }

#toc-entry-section {
  font-size: large;
  insert-position: current }

#toc-entry-subsection {
  font-size: medium;
  insert-position: current }

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

#acronym-list {
  prototype: container }

#acronym-term {
  insert-position: sorted }

#acronym-definition {
  insert-position: current }

#index {
  prototype: container }

#index-marker {
  insert-position: sorted 
  insert-policy: unique;

#index-entry {
  insert-position: sorted }

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

h2 {
  make-element: toc-entry content() }

h3 {
  make-element: toc-entry content() }

acronym { 
          index-marker first-letter(), 
          index-entry content(), 
          acronym content(), 
          acronym-definition attr(title);

dfn { make-element: 
          index-marker first-letter(), 
          index-entry content()

<div id="toc">
<h2>Table of contents</h2>
  <div id="toc-container">
    <div id="toc-entry-section"></div>
    <div id="toc-entry-subsection"></div>

<div id="acronym-list">
<h2>List of acronyms</h2>
  <dt id="acronym"></dt>
  <dd id="acronym-definition"></dd>

<div id="index">
<div id="index-marker"></div>
<div id="index-entry"></div>



<p>This part defines the a acronym: <acronym title="HyperText
Markup Language">HTML</acronym>.

<h3>More to learn</h3>

<p>An <dfn>emphasized element</dfn> element stands out.


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.


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]


Normative references

Håkon Wium Lie. Multi-column layout in CSS. 18 January 2001. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2001/WD-css3-multicol-20010118
Håkon Wium Lie; Jim Bigelow. CSS3 Paged Media Module. 25 February 2004. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2004/CR-css3-page-20040225

Other references

Bert Bos; et al. Cascading Style Sheets, level 2 (CSS2) Specification. 12 May 1998. W3C Recommendation. URL: http://www.w3.org/TR/1998/REC-CSS2-19980512


Property index

Property Values Initial Applies to Inh. Percentages Media
string-set [[ <identifier> <content-list>] [, <identifier> <content-list>]* ] | none none all elements no N/A all