- From: Alan Stearns via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 13 Feb 2012 03:21:57 +0000
- To: public-css-commits@w3.org
Update of /sources/public/csswg/css3-page-template
In directory hutz:/tmp/cvs-serv32201/css3-page-template
Added Files:
Overview.src.html
Log Message:
initial draft of page-template proposal
--- NEW FILE: Overview.src.html ---
<!DOCTYPE html>
<html lang="en">
<head profile="http://www.w3.org/2006/03/hcard">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>CSS Page Templates Module Level 3</title>
<link rel="stylesheet" type="text/css" href="../default.css">
<link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-[STATUS]">
<link id="st" href="../alternate-spec-style.css" rel="stylesheet"
type="text/css" title="alternate spec style">
<style type="text/css">
/* delete this block when you've cleared out all the .replaceme elements */
.replaceme {
border: solid red;
padding: 0 0.5em;
margin: 0 0.1em;
background: yellow;
color: green;
}
.replaceme:before {
content: "FIXME(";
color: black;
}
.replaceme:after {
content: ")";
color: black;
}
</style>
</head>
<body><div class="head">
<!--logo-->
<h1>CSS Page Templates Module Level 3</h1>
<h2 class="no-num no-toc">[LONGSTATUS] [DATE]</h2>
<dl>
<dt>This version:
<!--<dd><a href="[VERSION]">[VERSION]</a>-->
<dd><a href="//dev.w3.org/csswg/css3-page-template/">http://dev.w3.org/csswg/css3-page-template/</a>
<dt>Latest version:
<!--<dd><a href="[LATEST]">[LATEST]</a>-->
<dd><a href="//www.w3.org/TR/css3-page-template/">http://www.w3.org/TR/css3-page-template/</a>
<dt>Editor's draft:
<dd><a href="//dev.w3.org/csswg/css3-page-template/">http://dev.w3.org/csswg/css3-page-template/</a>
<!--
<dt>Previous version:
<dd><a href="http://www.w3.org/PreviousVersionURI">
http://www.w3.org/PreviousVersionURI</a>
-->
<dt>Editors:
<dd class="vcard"><span class="fn">Alan Stearns</span>,
<span class="org">Adobe Systems, Inc.</span>,
<span class="email">stearns@adobe.com</span>
<dd class="vcard"><span class="fn">...</span>
</dl>
<!--copyright-->
<hr title="Separator for header">
</div>
<h2 class="no-num no-toc" id="abstract">Abstract</h2>
<p>CSS is a language for describing the rendering of structured documents
(such as HTML and XML) on screen, on paper, in speech, etc. This module
contains the features of CSS level 3 relating to paged view templates.
It includes and extends the functionality of CSS level 2 [[!CSS21]],
which builds on CSS level 1 [[CSS1]].
The main extension compared to level 2 is the ability to specify one or more templates for a paged view to use to render content.
<h2 class="no-num no-toc" id="status">Status of this document</h2>
<p><strong>This document is a proposal that will need a few iterations before becoming an Editor's Draft. It has not yet been adopted by the Working Group, and should not be considered to be part of CSS.</strong></p>
<p>The following features are at risk: <var class="replaceme">everything in this proposal</var>
<h2 class="no-num no-toc" id="contents">Table of contents</h2>
<!--toc-->
<h2 id="intro">
Introduction</h2>
<p><em>This section is not normative.</em>
<p>CSS beyond level 2 is a set of modules, divided up to allow the specifications to develop incrementally, along with their implementations. This specification is one of those modules.
<p>This module describes how to define page templates in CSS. Page templates consist of anonymous boxes called slots created to contain content. Layouts done with page templates mainly determine the size of slots from the template definition instead of the intrinsic size of their content. When content does not fit into a template slot, additional pages are created with more slots to contain the overflow content.
<p>Multiple page templates can be defined for a given document. Which template is used for each page can be defined by a selector or by choosing a template based on available content.
<h3 id="placement">
Module Interactions</h3>
<var class="replaceme"></var>
<h3 id="values">
Values</h3>
<var class="replaceme"></var>
<h2 id="templates-and-slots">
Page Templates and Slots</h2>
<p class="issue">Should we extend the existing @page rule or create a new @page-template or @page-master rule?
<p class="issue">Alternately, we could use concepts from WebComponents to define templates.
<p>A slot is an anonymous box in a page template where content can be placed. In an @page rule the positioned-slots property lists how many slots exist in a particular template, their names, and their order. Each named slot can be addressed and styled with the ::slot() pseudo-element.
<p class="issue">Should the property name be page-slots instead of positioned-slots?
<p>Slots can be assigned content from named flows. If any slot in a template has overflow content, a new page is created with a new set of slots to receive the overflow content. Slots with the same named flow assignment (within a template and/or across pages created from templates) form a region chain.
<p>Slots can contain generated content assigned from the content property. Slots only instantiate if they are assigned content from a named flow, or the computed value of their 'content' property does not match its initial value.
<p>The default size for a paged view is the size of the viewport.
<p class="issue">Do we need to define vertical-align behavior for slots, the way css3-layout does?
<p class="issue">Is there a need to create more structure, nesting slots within slots?
<div class='example'>
<p class="issue">Add graphics for all of the examples.
<p>The simplest example takes all of the content in the document and flows it into a page template with a single slot. This template will display a viewport's worth of content at a time, and will create a new slot on a new page each time content overflows.
<pre>
body { flow-into: body; }
@page {
positioned-slots: main;
::slot(main) {
flow-from: body;
}
}
</pre>
<p class="issue">Should there be an implicit 'body' flow?
</div>
<div class='example'>
<p>A page template could contain two side-by-side slots that paginate two separate articles. This example fills the left side of the paged view with content from article1 and the right side with content from article2. New pages and slots are created until the content from both articles is exhausted.
<pre>
#article1 { flow-into: article1; }
#article2 { flow-into: article2; }
@page {
positioned-slots: left, right;
::slot (left) {
flow-from: article1;
width: 40%;
margin: 5%;
float: left;
}
::slot (right) {
flow-from: article2;
width: 40%;
padding: 5%
float: left;
}
}
<body>
<article id='article1'>...content...</article>
<article id='article2'>...content...</article>
</body>
</pre>
</div>
<div class='example'>
<p>The example above could position the slots using grid layout rather than floats.
<pre>
#article1 { flow-into: article1; }
#article2 { flow-into: article2; }
@page {
positioned-slots: left, right;
display:grid;
grid-columns: 1fr 1fr;
::slot (left) {
flow-from: article1;
padding: 5%;
grid-column: 1;
}
::slot (right) {
flow-from: article2;
padding: 5%
grid-column: 2;
}
}
<body>
<article id='article1'>...content...</article>
<article id='article2'>...content...</article>
</body>
</pre>
</div>
<p class="issue">Add an example of side-by-side article pagination using multicol slots, using more columns for each side of the page with more viewport width. If the articles were different lengths, once the shorter article was exhausted then remaining pages would fill with columns from the longer article.
<p class="issue">Add an example using media queries to choose between portrait and landscape templates.
<h2 id="conditional-templates">
Conditional Template Selection</h2>
<p>Multiple templates can be defined for a single document. Each page view created uses a single template. This template can be chosen using a selector, or by matching available content using the 'required-flow' property.
<h3 id='ordered-templates'>
Selecting Templates by Page Order</h3>
<p>Selectors such as :first can be used on a page template to define a separate template for pages that match the selector.
<p class="issue">Should we allow :left and :right for viewing more than one page at a time in a viewport? Should we have :nth(x) selectors?
<div class='example'>
<p>Any of the side-by-side two-article examples from the previous section could have an @page :first {} template that defined a fancy layout for the first page slots
<p class="issue">define "fancy."
<pre>
@page :first {
positioned-slots: first-left, first-right;
::slot (first-left) {
//fancy styling
flow-from: article1;
}
::slot (first-right) {
//fancy styling
flow-from: article2;
}
}
</pre>
</div>
<h3 id='selection-from-available-content'>
Selecting Templates from Available Content</h3>
<p>The 'required-flow' property can be used in a page template to list named flows that must have available content in order for the template to be used. If more than one template has a 'required-flow' value that matches the available content, the first template that matches will be used.
<div class='example'>
<p>Using the same two-article markup as in previous examples, these page templates will display an inital page with the beginning of both articles. If article1 has more content than will fit on that first page, the next pages will show only content from the first article. When the content from the first article is consumed, then pages will follow with content from the second article.
<pre>
@page :first {
positioned-slots: left, right;
::slot (left) {
flow-from: article1;
width: 40%;
margin: 5%;
float: left;
}
::slot (right) {
flow-from: article2;
width: 40%;
padding: 5%
float: left;
}
}
@page {
positioned-slots: first;
required-flow: article1;
::slot(first) {
flow-from: article1;
column-width: 12em;
}
}
@page {
positioned-slots: second;
required-flow: article2;
::slot(second) {
flow-from: article2;
column-width: 12em;
}
}
</pre>
</div>
<p class="issue">IDPF has a more complex notion of 'available' content. For example, consider a content source that contains a single article with images scattered throughout. Assign the images to a flow named 'images' and the rest of the article to a flow named 'text'. Then define two page templates - one that has slots only for the text flow, and another that has slots for both the text and images flows. Each time a page is laid out, the original article is scanned to see whether an image element would have shown up on the page. If so, then that content from the 'images' flow is available for the purpose of selecting a template.
<div class='example'>
<p>Assume you have an article that contains both pull quotes and images. If only images <em>or</em> pull quotes would occur on a page, position those elements in the center right of the template. But if both images <em>and</em> pull quotes would appear, position the images in the top left and the pull quotes in the bottom right.
<p class="issue">code this example
</div>
<h2 id="page-template-navigation">
Navigating Pages</h2>
<p class="issue">Should this specification define navigation? We could adopt the Paged Presentations properties from GCPM.
<h2 id="cssom">
CSS Object Model Modifications</h2>
<p class='issue'>There should be extensive OM defined to access pages and slots. Lots to fill out here.
<h2 id="conformance">
Conformance</h2>
<h3 id="conventions">
Document Conventions</h3>
<p>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.
<p>All of the text of this specification is normative except sections
explicitly marked as non-normative, examples, and notes. [[!RFC2119]]</p>
<p>Examples in this specification are introduced with the words “for example”
or are set apart from the normative text with <code>class="example"</code>,
like this:
<div class="example">
<p>This is an example of an informative example.</p>
</div>
<p>Informative notes begin with the word “Note” and are set apart from the
normative text with <code>class="note"</code>, like this:
<p class="note">Note, this is an informative note.</p>
<h3 id="conformance-classes">
Conformance Classes</h3>
<p>Conformance to <var class="replaceme">CSS TEMPLATE Module</var>
is defined for three conformance classes:
<dl>
<dt><dfn title="style sheet!!as conformance class">style sheet</dfn>
</dt><dd>A <a href="http://www.w3.org/TR/CSS21/conform.html#style-sheet">CSS
style sheet</a>.
</dd><dt><dfn>renderer</dfn></dt>
<dd>A <a href="http://www.w3.org/TR/CSS21/conform.html#user-agent">UA</a>
that interprets the semantics of a style sheet and renders
documents that use them.
</dd><dt><dfn id="authoring-tool">authoring tool</dfn></dt>
<dd>A <a href="http://www.w3.org/TR/CSS21/conform.html#user-agent">UA</a>
that writes a style sheet.
</dd></dl>
<p>A style sheet is conformant to <var class="replaceme">CSS TEMPLATE Module</var>
if all of its declarations that use properties defined in this module
have values that are valid according to the generic CSS grammar and the
individual grammars of each property as given in this module.
<p>A renderer is conformant to <var class="replaceme">CSS TEMPLATE Module</var>
if, in addition to interpreting the style sheet as defined by the
appropriate specifications, it supports all the features defined
by <var class="replaceme">CSS TEMPLATE Module</var> 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.)
<p>An authoring tool is conformant to <var class="replaceme">CSS TEMPLATE Module</var>
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.
<h3 id="partial">
Partial Implementations</h3>
<p>So that authors can exploit the forward-compatible parsing rules to
assign fallback values, CSS renderers <strong>must</strong>
treat as invalid (and <a href="http://www.w3.org/TR/CSS21/conform.html#ignore">ignore
as appropriate</a>) any at-rules, properties, property values, keywords,
and other syntactic constructs for which they have no usable level of
support. In particular, user agents <strong>must not</strong> 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.</p>
<h3 id="experimental">
Experimental Implementations</h3>
<p>To avoid clashes with future CSS features, the CSS2.1 specification
reserves a <a href="http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords">prefixed
syntax</a> for proprietary and experimental extensions to CSS.
<p>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.
</p>
<h3 id="testing">Non-Experimental Implementations</h3>
<p>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.
<p>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.
<p>Further information on submitting testcases and implementation reports
can be found from on the CSS Working Group's website at
<a href="http://www.w3.org/Style/CSS/Test/">http://www.w3.org/Style/CSS/Test/</a>.
Questions should be directed to the
<a href="http://lists.w3.org/Archives/Public/public-css-testsuite">public-css-testsuite@w3.org</a>
mailing list.
<h3 id="cr-exit-criteria">
CR Exit Criteria</h3>
<p class="issue">[Change or remove the following CR exit criteria if
the spec is not a module, but, e.g., a Note or a profile. This text was <a href="http://www.w3.org/Style/CSS/Tracker/actions/44"> decided on 2008-06-04.</a>]</p>
<p>
For this specification to be advanced to Proposed Recommendation,
there must be at least two independent, interoperable implementations
of each feature. Each feature may be implemented by a different set of
products, there is no requirement that all features be implemented by
a single product. For the purposes of this criterion, we define the
following terms:
<dl>
<dt>independent </dt><dd>each implementation must be developed by a
different party and cannot share, reuse, or derive from code
used by another qualifying implementation. Sections of code that
have no bearing on the implementation of this specification are
exempt from this requirement.
</dd><dt>interoperable </dt><dd>passing the respective test case(s) in the
official CSS test suite, or, if the implementation is not a Web
browser, an equivalent test. Every relevant test in the test
suite should have an equivalent test created if such a user
agent (UA) is to be used to claim interoperability. In addition
if such a UA is to be used to claim interoperability, then there
must one or more additional UAs which can also pass those
equivalent tests in the same way for the purpose of
interoperability. The equivalent tests must be made publicly
available for the purposes of peer review.
</dd><dt>implementation </dt><dd>a user agent which:
<ol class="inline">
<li>implements the specification.
</li><li>is available to the general public. The implementation may
be a shipping product or other publicly available version
(i.e., beta version, preview release, or “nightly build”).
Non-shipping product releases must have implemented the
feature(s) for a period of at least one month in order to
demonstrate stability.
</li><li>is not experimental (i.e., a version specifically designed
to pass the test suite and is not intended for normal usage
going forward).
</li></ol>
</dd></dl>
<p>The specification will remain Candidate Recommendation for at least
six months.
<h2 class="no-num" id="acknowledgments">Acknowledgments</h2>
<p><var class="replaceme">[acknowledgments]</var></p>
<h2 class="no-num" id="references">References</h2>
<h3 class="no-num" id="normative-references">Normative references</h3>
<!--normative-->
<h3 class="no-num" id="other-references">Other references</h3>
<!--informative-->
<h2 class="no-num" id="index">Index</h2>
<!--index-->
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-declaration:"~/SGML/HTML4.decl"
sgml-default-doctype-name:"html"
sgml-minimize-attributes:t
sgml-nofill-elements:("pre" "style" "br")
sgml-live-element-indicator:t
sgml-omittag:nil
sgml-shorttag:nil
sgml-namecase-general:t
sgml-general-insert-case:lower
sgml-always-quote-attributes:t
sgml-indent-step:nil
sgml-indent-data:t
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
Received on Monday, 13 February 2012 03:22:00 UTC