css-page-3/lc-doc-20040215.htm

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>CSS3 Paged Media Module Last Call Working Draft review Disposition of Comments</title>
<link rel="stylesheet" type="text/css" media="screen" href="https://www.w3.org/StyleSheets/TR/base.css" />
<?xml-stylesheet href="https://www.w3.org/StyleSheets/TR/base.css" type="text/css" media="screen" ?>
<style type="text/css">
  div.toc, div.subtoc {
  background-color: #ccccff;
  padding: 0.5em;
  border: none;
  margin-right: 5%;
}
code {
 font-family: monospace;
 font-weight: bold;
 color: #660099;
}
</style>
</head>
<body>
<div class="head">
<a href="http://www.w3.org/">
<img src="https://www.w3.org/Icons/WWW/w3c_home" alt="W3C" width="72" height="48" /></a>
<h1>CSS3 Paged Media Module Last Call Working Draft review Disposition of Comments</h1>
<h2>20 February 2004</h2>

<dl>
<dt>This version:</dt>

<dd>
<a href="http://www.w3.org/Style/Group/css3-src/css3-page/lc-doc-20040215.htm">
http://www.w3.org/Style/Group/css3-src/css3-page/lc-doc-20040215.htm
</a>
</dd>

<dt>Editors:</dt>

<dd>
<a href="mailto:jim.bigelow@hp.com">Jim Bigelow</a>, Hewlett-Packard Co.
</dd>
</dl>

<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> &#169; 2004 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">
W3C</acronym></a><sup>&#174;</sup> (<a href="http://www.lcs.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title=
"European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href=
"http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p>
</div>
<hr />

<h2>Abstract</h2>

<p>This document outlines the way in which the CSS Working Group addressed the
comments submitted during the CSS3 Paged Media Module Last Call Working Draft
review period.</p>

<h2>Status of this document</h2>

<p>
During the Last Call Working Draft review period for CSS3 Page Media
Module a number of comments were received from both inside and outside
of the W3C. This document presents those comments and describes the
ways in which the comments were addressed by the CSS Working
Group.</p>

<p>Note that the majority of this document is automatically generated
from messages posted in the Working Group's mailing list
www-style@w3.org . As such, it may contain typographical or stylistic
errors. If so, these are contained in the original submissions, and
the CSS Working Group elected to not change these submissions.</p>

<p>This document is a product of the W3C's CSS Working Group as part
of the <a href="http://www.w3.org/Style/">Style activity</a>
(see <a href="/Style/Activity">summary</a>).  This document may be
updated, replaced or rendered obsolete by other W3C documents at any
time. It is inappropriate to use this document as reference material
or to cite it as other than "work in progress". This document is work
in progress and does not imply endorsement by the <a
href="http://www.w3.org/Consortium/Member/List">W3C
membership</a>.</p>

<p>A list of current W3C Recommendations and other technical documents
can be found at <a
href="http://www.w3.org/TR">http://www.w3.org/TR</a>.</p>
<h2>Table of Contents</h2>
<div class=toc>
<table border='1'><tbody>
<tr><th>Issue</th><th>State</th><th>User</th><th>Resolution</th></tr>
<tr><td>01: <a href="#issue01">
 [1] Section 1:
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>02: <a href="#issue02">
 [2] Section 1:
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>03: <a href="#issue03">
 [3] Section 2:
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>04: <a href="#issue04">
 [4] Section 2:
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>05: <a href="#issue05">
 [5] Section 3.1:
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>06: <a href="#issue06">
 [6] Section 3.1 "Page Box":
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>07: <a href="#issue07">
 [7] Section 3.1 "Page Box":
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>08: <a href="#issue08">
 [8] Section 3.1 "Margin box"
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>09: <a href="#issue09">
 [9] Section 3.1 "Margin box"
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>10: <a href="#issue10">
 [10] Section 3.1 "Margin box"
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>11: <a href="#issue11">
 [11] Section 3.1 diagram
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>12: <a href="#issue12">
 [12] Section 3.1 diagram
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>13: <a href="#issue13">
 [13] Section 3.1 diagram
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>14: <a href="#issue14">
 [14] Section 3.2
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>15: <a href="#issue15">
 [15] Section 3.2 "Back side"
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>16: <a href="#issue16">
 [16] Section 3.2 "First page"
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>17: <a href="#issue17">
 [17] Section 3.2 "Left page"
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>18: <a href="#issue18">
 [18] Section 3.2 "Right page"
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, spec updated
</td></tr>
<tr><td>19: <a href="#issue19">
 [19] Section 3.3
</a></td><td>
closed
</td><td>
Agree
</td><td>
accepted, spec updated
</td></tr>
<tr><td>20: <a href="#issue20">
 [20] Section 3.3.1 Example
</a></td><td>
closed
</td><td>
Agree
</td><td>
accepted, spec updated.
</td></tr>
<tr><td>21: <a href="#issue21">
 [21] Section 3.3.2
</a></td><td>
closed
</td><td>
Agree
</td><td>
duplicate of #36
</td></tr>
<tr><td>22: <a href="#issue22">
 [22] Section 3.3.2 <length>
</a></td><td>
closed
</td><td>
Agree
</td><td>
accepted, spec updated.

</td></tr>
<tr><td>23: <a href="#issue23">
 [23] Section 3.4.1 Example
</a></td><td>
closed
</td><td>
Agree
</td><td>
Rejected, editorial comment, not change needed.
</td></tr>
<tr><td>24: <a href="#issue24">
 [24] Section 3.5
</a></td><td>
closed
</td><td>
Agree
</td><td>
Duplicate of #22
</td></tr>
<tr><td>25: <a href="#issue25">
 [25] Section 3.6
</a></td><td>
closed
</td><td>
Agree
</td><td>
Rejected, comment on functionality outside scope of specification.
</td></tr>
<tr><td>26: <a href="#issue26">
 [26] Section 4.2 maximum width of the top center cell
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted and updated spec.
</td></tr>
<tr><td>27: <a href="#issue27">
 [27] Section 7
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted and updated spec.
</td></tr>
<tr><td>28: <a href="#issue28">
 [28] Section 7.4
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted and updated spec.
</td></tr>
<tr><td>29: <a href="#issue29">
 [29] Section 8
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted and updated spec.
</td></tr>
<tr><td>30: <a href="#issue30">
 [30] Section 8
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted and updated spec.
</td></tr>
<tr><td>31: <a href="#issue31">
 RE: [css-page] New, last draft of CSS3 Paged Media Module
</a></td><td>
closed
</td><td>
Agree
</td><td>
Duplicate of #14.
</td></tr>
<tr><td>32: <a href="#issue32">
 [CSS3-Page] 3.3.2 Page Size Error
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted and changed spec.
</td></tr>
<tr><td>33: <a href="#issue33">
 [css3-page] Comment on page counters
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted and changed spec by extending the page-policy to apply to counter-reset.
</td></tr>
<tr><td>34: <a href="#issue34">
 [css3-page] Section 3.4.2. Cascading in the page context
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted and updated spec.
</td></tr>
<tr><td>35: <a href="#issue35">
 [css3-page] Applicable properties in margin boxes
</a></td><td>
closed
</td><td>
Agree
</td><td>
Not an issue, behavior already part of CSS
</td></tr>
<tr><td>36: <a href="#issue36">
 [css3-page] examples in 3.3.2 (page size) are 'US-centric'(?)
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted and corrected units, added set of media names, and referenced PWG media names spec.
</td></tr>
<tr><td>37: <a href="#issue37">
 XSL FO SG comment on css3-page spec
</a></td><td>
closed
</td><td>
Agree
</td><td>
Not an issue, no change proposed.
</td></tr>
<tr><td>38: <a href="#issue38">
 [css3-page] Last Call Comments on CSS3 Paged Media Module
    FW: [css-page] New, last draft of CSS3 Paged Media Module
Thursday, December 18, 2003 12:37 PM To: www-style@w3.org
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted, referenced specification and media names.
</td></tr>
<tr><td>39: <a href="#issue39">
 RE: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example
>  RE: [css3-page] LCWD issue 23 --  [23] Section 3.4.1 Example
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted comment and changed example.
</td></tr>
<tr><td>40: <a href="#issue40">
 [CSS3-page]: Comments on pages media
</a></td><td>
closed
</td><td>
Agree
</td><td>
Rejected, proposed redesign header and footer areas not accepted.
</td></tr>
<tr><td>41: <a href="#issue41">
 [CSS3-page]: Comments on pages media
</a></td><td>
closed
</td><td>
Agree
</td><td>
Rejected, extension outside the scope of specification
</td></tr>
<tr><td>42: <a href="#issue42">
 [CSS3-page]: Comments on pages media
</a></td><td>
closed
</td><td>
Agree
</td><td>
Accepted without changes
</td></tr>
<tr><td>43: <a href="#issue43">
 [CSS3-page]: Comments on pages media
</a></td><td>
closed
</td><td>
Agree
</td><td>
Rejected, no need for new formatting property, existing properties can be used
</td></tr>
<tr><td>44: <a href="#issue44">
 [css3-page] Is auto a page identifier or not?
</a></td><td>
closed
</td><td>
Agree
</td><td>
Rejected since auto is a special identifier
</td></tr>
</tbody></table>
</div>
<h1><a id='sec1' name='sec1'>1. CSS3 Page Media Module</a></h1>
<h2><a id="issue01" name="issue01">1.01  [1] Section 1:
</a></h2><p><b>PROBLEM ID: 01</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List

Subject: [1] Section 1:
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

The link for "Generated content module" should be to
http://www.w3.org/TR/css3-content and not to a specific working draft.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 01 --  [1] Section 1:
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 01.
&gt;
&gt; The link for "Generated content module" should be to
&gt; http://www.w3.org/TR/css3-content and not to a specific working draft.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.
 -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1)
Sent: Tuesday, February 03, 2004 8:32 PM
To: 'Ernest Cline'
Subject: RE: [css3-page] LCWD issue 01 -- [1] Section 1:

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 10 February
2004, to respond.

&gt;
&gt; Thank you for your comment on the CSS3 Paged Media Module,
&gt; archived in:
&gt; http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html
&gt;
&gt; Your issue, shown below, has been assigned the number 01.
&gt;
&gt; The link for "Generated content module" should be to
&gt; http://www.w3.org/TR/css3-content and not to a specific working draft.
&gt;

&gt; A further response will be forthcoming. Please address any replies
&gt; to www-style@w3.org with [css3-page] in the subject line.

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue02" name="issue02">1.02  [2] Section 1:
</a></h2><p><b>PROBLEM ID: 02</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List

Subject: [2] Section 1:
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

In the item "the Generated content module which this module extents"
"extents" should be "extends".

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 02 --  [2] Section 1:
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 02.
&gt;
&gt; In the item "the Generated content module which this module extents"
&gt; "extents" should be "extends".
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1) Sent: Tuesday, February 03, 2004 8:39
PM To: 'ernestcline@mindspring.com' Subject: RE: [css3-page] LCWD
issue 02 -- [2] Section 1:

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 10 February
2004, to respond.

&gt;
&gt;
&gt; Thank you for your comment on the CSS3 Paged Media Module,
&gt; archived in:
&gt; http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html
&gt;
&gt; Your issue, shown below, has been assigned the number 02.
&gt;
&gt; In the item "the Generated content module which this module extents"
&gt; "extents" should be "extends".
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue03" name="issue03">1.03  [3] Section 2:
</a></h2><p><b>PROBLEM ID: 03</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List

Subject: [3] Section 2:
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

The link for "continuous media" should be changed to refer to a non-WD
version such as either:
http://www.w3.org/TR/CSS2/media.html#continuous-media-group or:
http://www.w3.org/TR/CSS21/media.html#continuous-media-group depending
upon whether CSS 2.1 has exited from Last Call at the time this module
exits Last Call.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 03 --  [3] Section 2:
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 03.
&gt;
&gt; The link for "continuous media" should be changed to refer to a non-WD
&gt; version such as either:
&gt; http://www.w3.org/TR/CSS2/media.html#continuous-media-group or:
&gt; http://www.w3.org/TR/CSS21/media.html#continuous-media-group depending
&gt; upon whether CSS 2.1 has exited from Last Call at the time this module
&gt; exits Last Call.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: ernestcline@mindspring.com
Subject: RE: [css3-page] LCWD issue 03 -- [3] Section 2:

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 10 February
2004, to respond.

&gt;
&gt; The link for "continuous media" should be changed to refer to a non-WD
&gt; version such as either:
&gt; http://www.w3.org/TR/CSS2/media.html#continuous-media-group or:
&gt; http://www.w3.org/TR/CSS21/media.html#continuous-media-group depending
&gt; upon whether CSS 2.1 has exited from Last Call at the time this module
&gt; exits Last Call.
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue04" name="issue04">1.04  [4] Section 2:
</a></h2><p><b>PROBLEM ID: 04</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List

Subject: [4] Section 2:
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

The sentence "Furthermore, CSS3 assumes that one page box will be
transfer to a side of a sheet." should have the word "transfer"
changed to "transferred".

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 04 --  [4] Section 2:
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 04.
&gt;
&gt; The sentence "Furthermore, CSS3 assumes that one page box will be
&gt; transfer to a side of a sheet." should have the word "transfer"
&gt; changed to "transferred".
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: ernestcline@mindspring.com
Subject: RE: [css3-page] LCWD issue 04 -- [4] Section 2:

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 10 February
2004, to respond.

&gt;
&gt; The sentence "Furthermore, CSS3 assumes that one page box will be
&gt; transfer to a side of a sheet." should have the word "transfer"
&gt; changed to "transferred".
&gt;
   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue05" name="issue05">1.05  [5] Section 3.1:
</a></h2><p><b>PROBLEM ID: 05</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List

Subject: [5] Section 3.1:
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

In the clause "The following terminology and accompanying diagram make
up the page model:" I would prefer a substitute be used for "make up"
such as "describe" or "specify" be used instead.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 05 --  [5] Section 3.1:
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 05.
&gt;
&gt; In the clause "The following terminology and accompanying diagram make
&gt; up the page model:" I would prefer a substitute be used for "make up"
&gt; such as "describe" or "specify" be used instead.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: ernestcline@mindspring.com
Subject: RE: [css3-page] LCWD issue 05 -- [5] Section 3.1:

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 10 February
2004, to respond.

&gt;
&gt; In the clause "The following terminology and accompanying diagram make
&gt; up the page model:" I would prefer a substitute be used for "make up"
&gt; such as "describe" or "specify" be used instead.
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue06" name="issue06">1.06  [6] Section 3.1 "Page Box":
</a></h2><p><b>PROBLEM ID: 06</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List

Subject: [6] Section 3.1 "Page Box":
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

The link for "box model" should be to http://www.w3.org/TR/css3-box/
instead of to http://www.w3.org/TR/css3-page/ .

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 06 --  [6] Section 3.1 "Page Box":
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 06.
&gt;
&gt; The link for "box model" should be to http://www.w3.org/TR/css3-box/
&gt; instead of to http://www.w3.org/TR/css3-page/ .
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: ernestcline@mindspring.com
Subject: RE: [css3-page] LCWD issue 06 -- [6] Section 3.1 "Page Box":

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 10 February
2004, to respond.

&gt;
&gt; The link for "box model" should be to http://www.w3.org/TR/css3-box/
&gt; instead of to http://www.w3.org/TR/css3-page/ .
&gt;


   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue07" name="issue07">1.07  [7] Section 3.1 "Page Box":
</a></h2><p><b>PROBLEM ID: 07</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [7] Section 3.1 "Page Box":
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

In the clause "there are more complex uses cases", the word "uses"
should be "use".

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 07 --  [7] Section 3.1 "Page Box":
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 07.
&gt;
&gt; In the clause "there are more complex uses cases", the word "uses"
&gt; should be "use".
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: ernestcline@mindspring.com
Subject: RE: [css3-page] LCWD issue 07 -- [7] Section 3.1 "Page Box":

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 10 February
2004, to respond.

&gt;
&gt; In the clause "there are more complex uses cases", the word "uses"
&gt; should be "use".
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue08" name="issue08">1.08  [8] Section 3.1 "Margin box"
</a></h2><p><b>PROBLEM ID: 08</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [8] Section 3.1 "Margin box"
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

'top' and 'bottom' are mentioned as being present for compatibility
with previous versions of the document.  Could references for those be
provided?

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 08 --  [8] Section 3.1 "Margin box"
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 08.
&gt;
&gt; 'top' and 'bottom' are mentioned as being present for compatibility
&gt; with previous versions of the document.  Could references for those be
&gt; provided?
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1)
Sent: Tuesday, February 03, 2004 9:00 PM
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 08 -- [8] Section 3.1 "Margin box"

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 10 February
2004, to respond.

&gt;
&gt; 'top' and 'bottom' are mentioned as being present for compatibility
&gt; with previous versions of the document.  Could references for those be
&gt; provided?
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue09" name="issue09">1.09  [9] Section 3.1 "Margin box"
</a></h2><p><b>PROBLEM ID: 09</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [9] Section 3.1 "Margin box"
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Was having 'left-center', 'left-top', etc. rejected because they were
too kitchen sinkish, or were they not considered?

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 09 --  [9] Section 3.1 "Margin box"
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 09.
&gt;
&gt; Was having 'left-center', 'left-top', etc. rejected because they were
&gt; too kitchen sinkish, or were they not considered?
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1)
Sent: Wednesday, January 07, 2004 4:57 PM
To: 'www-style@w3.org'
Subject: [css3-page] LCWD issue 09 -- [9] Section 3.1 "Margin box"

Ernest,

I didn't consider left-center, left-top, etc.. What is your suggestion?

Jim

-----Original Message-----
From: James Bigelow
Sent: Wednesday, January 07, 2004 4:44 PM
To: www-style@w3.org; ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 09 -- [9] Section 3.1 "Margin box"


Thank you for your comment on the CSS3 Paged Media Module, archived
in: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 09.
&gt;
&gt; Was having 'left-center', 'left-top', etc. rejected because they were
&gt; too kitchen sinkish, or were they not considered?
&gt;

A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.

   -- Jim Bigelow, Editor
</pre>
<p><b>

   FOLLOWUP 02:

   </b></p><pre>
From: Ernest Cline [ernestcline@mindspring.com]
Sent: Wednesday, January 07, 2004 8:20 PM
To: BIGELOW,JIM (HP-Boise,ex1); www-style@w3.org
Subject: RE: [css3-page] LCWD issue 09 -- [9] Section 3.1 "Margin box"


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; To: &lt;www-style@w3.org&gt;
&gt; Date: 1/7/2004 7:57:41 PM
&gt; Subject: [css3-page] LCWD issue 09 --  [9] Section 3.1 "Margin box"
&gt;
&gt;
&gt; Ernest,
&gt;
&gt; I didn't consider left-center, left-top, etc.. What is your
&gt; suggestion?
&gt;
&gt; Jim

The left margin box defined by the '@left' at-rule is deprecated in
favor of those defined by '@left-top', '@left-center', and
'@left-bottom'. Whenever, the deprecated '@left' at-rule occurs with
any of the non-deprecated at-rules listed above, the UA MUST ignore
the declarations of the deprecated at-rule.

The intent is for @left-top, @left-center, and @left-bottom to act
much as @top-left, @top-center, and @top-right do except that instead
of working to divide up the width of the top margin between corner
boxes, they would divide up the height of the left margin between the
corner boxes

All three of these boxes would have a default value of 'text-align' of
"center" (just as @left does) but @left-top would have a default value
of 'vertical-align' of "top" and @left-bottom would have a default
value of "bottom".  (Note: given the rages of values for 'text-align'
and 'vertical-align might it be better to name the @left-center rule
@left-middle instead?)

Similarly for the right margin we would have @right-top,
@right-center, and @right-bottom.  I'm assuming that if is important
to maintain support for @top and @bottom that @left and @right need to
be maintained as well.  If that is not the case then @left and @right
could be simply dropped instead of deprecated.


</pre>
<p><b>

   FOLLOWUP 03:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1)
Sent: Thursday, January 08, 2004 2:45 PM
To: 'ernestcline@mindspring.com'; www-style@w3.org
Cc: H�kon Wium Lie
Subject: RE: [css3-page] LCWD issue 09 -- [9] Section 3.1 "Margin box"

Ernest wrote:
&gt; &gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; &gt; I didn't consider left-center, left-top, etc.. What is your
&gt; &gt; suggestion?
&gt;
&gt; The left margin box defined by the '@left' at-rule is
&gt; deprecated in favor of those defined by '@left-top',
&gt; '@left-center', and '@left-bottom'. Whenever, the deprecated
&gt; '@left' at-rule occurs with any of the non-deprecated
&gt; at-rules listed above, the UA MUST ignore the declarations of
&gt; the deprecated at-rule.
&gt;
&gt; The intent is for @left-top, @left-center, and @left-bottom
&gt; to act much as @top-left, @top-center, and @top-right do
&gt; except that instead of working to divide up the width of the
&gt; top margin between corner boxes, they would divide up the
&gt; height of the left margin between the corner boxes
&gt;
&gt; All three of these boxes would have a default value of
&gt; 'text-align' of "center" (just as @left does) but @left-top
&gt; would have a default value of 'vertical-align' of "top" and
&gt; @left-bottom would have a default value of "bottom".  (Note:
&gt; given the rages of values for 'text-align' and
&gt; 'vertical-align  might it be better to name the @left-center
&gt; rule @left-middle instead?)
&gt;
&gt; Similarly for the right margin we would have @right-top,
&gt; @right-center, and @right-bottom.  I'm assuming that if is
&gt; important to maintain support for @top and @bottom that @left
&gt; and @right need to be maintained as well.  If that is not the
&gt; case then @left and @right could be simply dropped instead of
&gt; deprecated.
&gt;

I don't seem any reason not to divide the left and right margins, just
as the top and bottom are divided.  I assume you meant the height of
the margin boxes would be as dynamic and vary in the same manner as
the top and bottom boxes do.

@top and @bottom are referenced in the PWG CSS Print Profile
specification [1], which is way they are maintain.  Since @left and
@right are not used, we could just drop them.

I'm curious to hear what H�kon thinks of this suggestion.

Jim

[1] http://www.pwg.org/xhtml-print/HTML-Version/CSS-Print.html
</pre>
<p><b>

   FOLLOWUP 04:

   </b></p><pre>
From: Ernest Cline [ernestcline@mindspring.com]
Sent: Thursday, January 08, 2004 8:02 PM
To: BIGELOW,JIM (HP-Boise,ex1); www-style@w3.org
Cc: H�kon Wium Lie
Subject: RE: [css3-page] LCWD issue 09 -- [9] Section 3.1 "Margin box"


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt;
&gt; I don't seem any reason not to divide the left and right margins, just
&gt; as the top and bottom are divided.  I assume you meant the height of
&gt; the
margin
&gt; boxes would be as dynamic and vary in the same manner as the top and
&gt; bottom boxes do.

Just to clarify, the *height* of the left and right margin boxes would
vary in the same manner as the *width* of the top and bottom boxes do.

</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: ernestcline@mindspring.com
Cc: www-style@w3.org
Subject: RE: [css3-page] LCWD issue 09 -- [9] Section 3.1 "Margin box"

Ernest wrote:
&gt;
&gt; [define three left margin boxes] @left-top',
&gt; '@left-center', and '@left-bottom'. ...
&gt;
&gt; The intent is for @left-top, @left-center, and @left-bottom
&gt; to act much as @top-left, @top-center, and @top-right do
&gt; except that instead of working to divide up the width of the
&gt; top margin between corner boxes, they would divide up the
&gt; height of the left margin between the corner boxes
&gt;
&gt; All three of these boxes would have a default value of
&gt; 'text-align' of "center" (just as @left does) but @left-top
&gt; would have a default value of 'vertical-align' of "top" and
&gt; @left-bottom would have a default value of "bottom".  (Note:
&gt; given the ra[n]ges of values for 'text-align' and
&gt; 'vertical-align  might it be better to name the @left-center
&gt; rule @left-middle instead?)
&gt;
&gt; Similarly for the right margin we would have @right-top,
&gt; @right-center, and @right-bottom.  ... @left and @right
&gt; could be simply dropped instead of deprecated.
&gt;

Your issue has been accepted. The @left and @right boxes are removed
since no other specification references them in the way that @top and
@bottom are referenced by PWG specifications [1, 2]. The following
boxes are defined in the place of @left and @right with the defaults
you recommend.

left-top:

a variable height box within the area defined by the left margin and
adjacent to the bottom of the top-left-corner.

left-middle:

a variable height box in the area defined by the left margin, centered
on the page area, and between the left-top and left-bottom margin
boxes.

left-bottom:

a variable height box within the area defined by the left margin and
adjacent to the top of the bottom-left-corner.

right-top:

a variable height box within the area defined by the right margin and
adjacent to the bottom of the top-right-corner.

right-middle:

a variable height box in the area defined by the right margin,
centered on the page area, and between the right-top and right-bottom
margin boxes.

right-bottom:

a variable height box within the area defined by the right margin and
adjacent to the top of the bottom-right-corner.


If you have any further comment on this topic, you have 7 days, until
10 February 2004, to respond.

 -- Jim Bigelow

[1] ftp://ftp.pwg.org/pub/pwg/xhtml-print/drafts/xhtml-print-draft-095.pdf
[2] http://www.pwg.org/xhtml-print/HTML-Version/CSS-Print.html </pre>
<h2><a id="issue10" name="issue10">1.10  [10] Section 3.1 "Margin box"
</a></h2><p><b>PROBLEM ID: 10</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [10] Section 3.1 "Margin box"
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

The table of margin box definitions should be changed either so that
it is a definition list, or the first column contains &lt;th&gt;'s.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 10 --  [10] Section 3.1 "Margin box"
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 10.
&gt;
&gt; The table of margin box definitions should be changed either so that
&gt; it is a definition list, or the first column contains &lt;th&gt;'s.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 10 -- [10] Section 3.1 "Margin box"

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; The table of margin box definitions should be changed either so that
&gt; it is a definition list, or the first column contains &lt;th&gt;'s.
&gt;
   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue11" name="issue11">1.11  [11] Section 3.1 diagram
</a></h2><p><b>PROBLEM ID: 11</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [11] Section 3.1 diagram
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

The diagram contains a &lt;note-box&gt; area with no definition or reference
given in this section.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 11 --  [11] Section 3.1 diagram
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 11.
&gt;
&gt; The diagram contains a &lt;note-box&gt; area with no definition or reference
&gt; given in this section.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 11 -- [11] Section 3.1 diagram

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; The diagram contains a &lt;note-box&gt; area with no definition or reference
&gt; given in this section.
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue12" name="issue12">1.12  [12] Section 3.1 diagram
</a></h2><p><b>PROBLEM ID: 12</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [12] Section 3.1 diagram
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

The pointer for "top box" should be moved so that the text is not
obscured by the vertical lines.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 12 --  [12] Section 3.1 diagram
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 12.
&gt;
&gt; The pointer for "top box" should be moved so that the text is not
&gt; obscured by the vertical lines.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 12 -- [12] Section 3.1 diagram

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; The pointer for "top box" should be moved so that the text is not
&gt; obscured by the vertical lines.
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue13" name="issue13">1.13  [13] Section 3.1 diagram
</a></h2><p><b>PROBLEM ID: 13</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [13] Section 3.1 diagram
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

The diagram contains no visual distinction between the &lt;page-box&gt;
border and the &lt;page-box&gt; padding.  Those not familiar with the CSS
box properties could conclude from this diagram that they are supposed
to be the same thing.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 13 --  [13] Section 3.1 diagram
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 13.
&gt;
&gt; The diagram contains no visual distinction between the &lt;page-box&gt;
&gt; border and the &lt;page-box&gt; padding.  Those not familiar with the CSS
&gt; box properties could conclude from this diagram that they are supposed
&gt; to be the same thing.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 13 -- [13] Section 3.1 diagram

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt; The diagram contains no visual distinction between the &lt;page-box&gt;
&gt; border and the &lt;page-box&gt; padding.  Those not familiar with the CSS
&gt; box properties could conclude from this diagram that they are supposed
&gt; to be the same thing.
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue14" name="issue14">1.14  [14] Section 3.2
</a></h2><p><b>PROBLEM ID: 14</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [14] Section 3.2
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

This section and the accompanying terminology assumes that the
standard Western practice of binding so that the spine is to the left
is the only standard.  This is NOT the case. Standard Japanese
practice is to bind printed matter so that the spine is to the right.
Given the unfortunate choice of :left and :right in CSS 2, I don't
have any expectation of changing the pseudoclasses, but the
explanatory material should be rewritten so as to be supportive of
Japanese binding.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 14 --  [14] Section 3.2
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 14.
&gt;
&gt; This section and the accompanying terminology assumes that the
&gt; standard Western practice of binding so that the spine is to the left
&gt; is the only standard.  This is NOT the case. Standard Japanese
&gt; practice is to bind printed matter so that the spine is to the right.
&gt; Given the unfortunate choice of :left and :right in CSS 2, I don't
&gt; have any expectation of changing the pseudoclasses, but the
&gt; explanatory material should be rewritten so as to be supportive of
&gt; Japanese binding.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Wednesday, January 07, 2004 5:06 PM
To: www-style@w3.org
Cc: ernestcline@mindspring.com
Subject: FW: [css3-page] LCWD issue 14 -- [14] Section 3.2


Ernest,

You wrote:
&gt;
&gt; This section and the accompanying terminology assumes that the
&gt; standard Western practice of binding so that the spine is to the left
&gt; is the only standard.  This is NOT the case. Standard Japanese
&gt; practice is to bind printed matter so that the spine is to the right.
&gt; Given the unfortunate choice of :left and :right in CSS 2, I don't
&gt; have any expectation of changing the pseudoclasses, but the
&gt; explanatory material should be rewritten so as to be supportive of
&gt; Japanese binding.

Thank you, I will edit this section based on your comments.

Jim

-----Original Message-----
From: James Bigelow [mailto:jhb@jhb.boi.hp.com]
Sent: Wednesday, January 07, 2004 4:44 PM
To: www-style@w3.org; ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 14 -- [14] Section 3.2


Thank you for your comment on the CSS3 Paged Media Module, archived
in: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 14.
&gt;
&gt; This section and the accompanying terminology assumes that the
&gt; standard Western practice of binding so that the spine is to the left
&gt; is the only standard.  This is NOT the case. Standard Japanese
&gt; practice is to bind printed matter so that the spine is to the right.
&gt; Given the unfortunate choice of :left and :right in CSS 2, I don't
&gt; have any expectation of changing the pseudoclasses, but the
&gt; explanatory material should be rewritten so as to be supportive of
&gt; Japanese binding.
&gt;

A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.

   -- Jim Bigelow, Editor
</pre>
<p><b>

   FOLLOWUP 02:

   </b></p><pre>
To: ernestcline@mindspring.com
Subject: RE: [css3-page] LCWD issue 14 -- [14] Section 3.2

Ernest,

Your text, below is very nicely written and a great improvement of my
previous efforts. I plan to merge it into document.

Thank for the time and effort you've put into this and the other
reviewing efforts.  I really appreciate it.

Best regards,

Jim

&gt; -----Original Message-----
&gt; From: www-style-request@w3.org
&gt; [mailto:www-style-request@w3.org] On Behalf Of Ernest Cline
&gt; Sent: Monday, February 09, 2004 10:01 PM
&gt; To: BIGELOW,JIM (HP-Boise,ex1)
&gt; Cc: www-style@w3.org
&gt; Subject: RE: [css3-page] LCWD issue 14 -- [14] Section 3.2
&gt;
&gt;
&gt;
&gt;
&gt;
&gt;
&gt; &gt; [Original Message]
&gt; &gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; &gt; To: &lt;ernestcline@mindspring.com&gt;
&gt; &gt; Cc: &lt;www-style@w3.org&gt;
&gt; &gt; Date: 2/8/2004 2:43:04 PM
&gt; &gt; Subject: RE: [css3-page] LCWD issue 14 --  [14] Section 3.2
&gt; &gt;
&gt; &gt; Your issue, shown below, has been accepted by the editor.
&gt; If you have
&gt; &gt; any further comment on this topic, you have 7 days, until
&gt; 15 February
&gt; &gt; 2004, to respond.
&gt; &gt;
&gt; &gt; &gt;
&gt; &gt; &gt; This section and the accompanying terminology assumes that the
&gt; &gt; &gt; standard Western practice of binding so that the spine is
&gt; to the left
&gt; &gt; &gt; is the only standard.  This is NOT the case. Standard Japanese
&gt; &gt; &gt; practice is to bind printed matter so that the spine is
&gt; to the right.
&gt; &gt; &gt; Given the unfortunate choice of :left and :right in CSS
&gt; 2, I don't
&gt; &gt; &gt; have any expectation of changing the pseudo-classes, but the
&gt; &gt; &gt; explanatory material should be rewritten so as to be
&gt; supportive of
&gt; &gt; &gt; Japanese binding.
&gt; &gt; &gt;
&gt; &gt;
&gt; &gt; You issue while true is vague as to how it should be accomplished.
&gt; &gt; The new text of this section is included below for your
&gt; review.  Any
&gt; &gt; help you can offer to improve it would be welcomed.
&gt;
&gt; Well, I didn't want to usurp your prerogatives, but here goes
&gt; my version of Section 3.2  I did take the liberty of using
&gt; the term pseudo-page in hopes that term is accepted.  If it
&gt; isn't it should be simple enough to revert back to pseudo-class.
&gt;
&gt; Features of my draft:
&gt; 1) Removed an ambiguity over whether a square page is
&gt; portrait or landscape by explicitly saying it doesn't matter.
&gt; 2) Introduced a separate definition of Duplex Printing
&gt; because it seemed to make what I wanted to say clearer.
&gt; 3) Dropped all discussion of page numbering, largely because
&gt; there is no guarantee that the page number of the nth page
&gt; would be n, making discussion of page numbers irrelevant to
&gt; the concepts described here.
&gt; 4) Added a definition of Major Writing Direction with the
&gt; intent of tying it to the value of the 'direction' property
&gt; of the root element. I was uncertain whether to use MAY or
&gt; MUST in the definition and it may well be that I overdid my
&gt; attempt at tying down its value.
&gt;
&gt; 3.2. Page types
&gt;
&gt; Pages and their corresponding page layouts have many possible
&gt; formats. Among the aspects of page layout that can vary are
&gt; paper size, orientation of the layout with respect to the
&gt; paper, order of the pages, how the document will be printed,
&gt; and how the document will be bound. Some of these depend upon
&gt; factors such as the major writing direction and the media
&gt; type that are not be specified by this module. The following
&gt; terminology is used to describe pages and page treatments:
&gt;
&gt; Page Orientation
&gt; The page orientation is defined by comparing the length of
&gt; the edges of a page box. The page box is a rectangle with two
&gt; perpendicular edges called the long edge and the short edge.
&gt; The length of the long edge is always greater than or equal
&gt; to the length of the short edge.  When the page box is
&gt; square, the two edges are of the same length and either can
&gt; be used as the long edge with the other being  the short edge.
&gt;
&gt; Portrait Orientation
&gt; A portrait page's height is greater than or equal to its
&gt; width. Horizontal elements are parallel to the short edge and
&gt; vertical elements to the long edge.
&gt;
&gt; Landscape Orientation
&gt; A landscape page's width is greater than or equal to its
&gt; height. Horizontal elements are parallel to the long edge and
&gt; vertical elements to the short edge.
&gt;
&gt; Front Side
&gt; Media used as a stack of sheets have two sides known as the
&gt; front and the back. Typically, the user agent prints on the
&gt; front side of the media when using only one side of the page
&gt; sheet.  Media used from a roll or continuous form will print
&gt; only on the front side. CSS does not provide a mechanism to
&gt; deal directly with the front and back sides, rather page
&gt; layouts must be designed in terms of left and right pages.
&gt;
&gt; Back Side
&gt; The back side of a sheet medium is the side that cannot be
&gt; seen when looking at the front side. Typically, the back side
&gt; is only used when printing on both sides of the medium.
&gt; Unless using special paper stock such as letterhead it does
&gt; not usually matter which side is the front and which is the back.
&gt;
&gt; Duplex Printing
&gt; Duplex printing uses one page box per side of a page sheet
&gt; and uses both sides of the page sheet.  This module provides
&gt; no ability to specify whether a document is duplex printed,
&gt; but the concept of left and right pages is based on the
&gt; assumption that the document is duplex printed, regardless of
&gt; whether it actually is.
&gt;
&gt; Binding Edge
&gt; The binding edge is the edge of the page box that is towards
&gt; the binding if the material is bound.  The binding edge often
&gt; has a larger margin than the opposite edge to provide for the
&gt; space used by the binding.  The binding edge can be any of
&gt; the four edges.  However, page sheets are customarily bound
&gt; so that the binding edge of page boxes with portrait
&gt; orientation is vertical.  This module provides no method to
&gt; specify the binding edge.  In duplex printing, the binding
&gt; edge is on opposite sides of the page box for the left and
&gt; right pages.
&gt;
&gt; Facing Pages
&gt; Facing pages are two sequential pages such that when the
&gt; document is duplex printed they are on separate sheets of
&gt; paper. Typically, the earlier page will be the back side of
&gt; one sheet and the later page will be the front side of
&gt; another. They are usually laid out so that the binding edges
&gt; of facing pages are vertical and adjacent when the pages are
&gt; placed in their normal reading orientation.  It is up to the
&gt; UA to determine whether the left page or the right page of a
&gt; pair of facing pages is the earlier one of the sequence.  How
&gt; the UA makes this determination is implementation dependent
&gt; but often depends upon the predominant writing direction of
&gt; the document.
&gt;
&gt; Major Writing Direction
&gt; The major writing direction for the document is determined by
&gt; the UA. If the UA supports the 'direction' property from CSS2
&gt; or the CSS 3 Text Module it (MAY/MUST) determine it using the
&gt; value of that property on the root element.
&gt;
&gt; Left Page
&gt; A page that will be on the left if it is part of a pair of
&gt; facing pages as typically laid out. Page layouts for
&gt; documents using a left-to-right major writing direction have
&gt; the earlier of the facing pages on the left.  Rules for the
&gt; left page can be specified using the :left pseudo-page selector.
&gt;
&gt; Right Page
&gt; A page that will be on the right if it is part of a pair of
&gt; facing pages as typically laid out. Page layouts for
&gt; documents using a right-to-left writing major direction have
&gt; the earlier of the facing pages on the right.  Rules for the
&gt; right page can be specified using the :right pseudo-page selector.
&gt;
&gt; First Page
&gt; The first page in a set of pages.  The UA determines which
&gt; page is the first page.  The first page is generally printed
&gt; on the front side of a medium.  Rules for the first page can
&gt; be specified using the :first pseudo-page selector.  A first
&gt; page can be either a left page or a right page but a UA MUST
&gt; apply any rules defined for a first page in preference to
&gt; those defined on a left page or a right page.
&gt;
&gt; </pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Cc: www-style@w3.org
Subject: RE: [css3-page] LCWD issue 14 -- [14] Section 3.2

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 15 February
2004, to respond.

&gt;
&gt; This section and the accompanying terminology assumes that the
&gt; standard Western practice of binding so that the spine is to the left
&gt; is the only standard.  This is NOT the case. Standard Japanese
&gt; practice is to bind printed matter so that the spine is to the right.
&gt; Given the unfortunate choice of :left and :right in CSS 2, I don't
&gt; have any expectation of changing the pseudoclasses, but the
&gt; explanatory material should be rewritten so as to be supportive of
&gt; Japanese binding.
&gt;

You issue while true is vague as to how it should be accomplished.
The new text of this section is included below for your review.  Any
help you can offer to improve it would be welcomed.

 -- Jim Bigelow, editor

Updated Section 3.2:

Page types

Pages and the graphic designs that create page layouts can vary in
many ways.  Pages can vary in orientation, size, side in view and
order within a printed document. Page layouts can have apply special
treatments to pages based on things such as the document's writing
direction, the anticipated printing treatment (double or single sided
printing), or the planned document binding technique, stapling for
example. The following terminology is used to describe pages and page
treatments:

Page Orientation

The page orientation, or more simply orientation, is the page's
orientation as defined by a comparison of the length of the edges of a
page box. A page box has a long edge and a short edge. When a page box
is a square the long edge is the same length as the short edge,
otherwise the page box is a rectangle and the length of the long edge
is greater than the length of the short edge.

Portrait Orientation

A portrait page's height is greater than its width. Horizontal
elements are parallel to the short edge and vertical elements to the
long edge.

Landscape Orientation

A landscape page's width is greater than its height. Horizontal
elements are parallel to the long edge and vertical elements to the
short edge.

Front Side

Media used as a stack of sheets have two sides known as the front and
the back. The front side is the side in view. Typically, the user
agent prints on the front side of the media although it MAY place the
page in an output bin after printing so that the back is
visible. Media used from a roll or continuous form only have a front
side. CSS does not provide a mechanism to deal directly with the front
and back sides, rather page layouts must be designed in terms of left
and right pages.

Back Side

The back side of a sheet medium, is the side that cannot be seen when
looking at the front side. Typically, the back side is only used when
printing on both sides of the medium. Media from a roll or continuous
form do not have a back side

First Page

The first page in a set of pages. The UA determines which page is the
first page. The first page is generally printed on the front side of a
medium, however documents where the writing direction is right-to-left
may cause the printer to place the first page on the back side of the
first sheet.

Facing Pages

Facing pages are two pages in order so that when viewed one page is on
the left and the other is on the right. For example, when a document
is printed with one page box per page sheet, on the front and back
sides of the page sheet and bound, the pages face each other. Page
layouts for left-to-right writing generally have the even numbered
page on the left and odd numbered on the right for documents. Other
writing directions, as well as, printing and binding treatments will
cause different page numbering.

Left Page

The left facing page, usually even numbered in left-to-right writing
directions The UA MUST distinguish the left page from the first and
right pages. Typically, when printing documents with a predominately
left-to-right writing direction, this page will be printed on front
side of a medium when printing on only one side of the media and on
the back when printing on both sides. Other binding styles are
possible, for example, the standard Japanese practice is to bind
documents on the right rather than on the left, so that the left and
right pages are effectively reversed.

Right Page

The right facing page, usually odd numbered in left-to-right writing
directions. The UA MUST distinguish the right page from the first and
left pages. This is page is printed on the front of a medium for
left-to-right documents. As with the left page, other writing
directions and binding styles will can effectively reverse the left
and right pages.

Binding Edge treatment

The binding edge is the page edge that will be stitched, stapled, or
punched with holes when preparing the pages of the document for
binding. Graphic designs of page layouts can call for an increase in
the margin of the binding edge, to accommodate the space needed for
binding. Page designs for documents with a left-to-right writing
direction, usually designate the left side of a page as the binding
edge when printing in portrait mode on the right page. The binding
edge is usually on the right side of a portrait oriented left page
when with a left-to-right document that is bound on the
left.. Similarly, The top and bottom edges can be the binding edges
when printing in landscape orientation. There are no provisions within
CSS3 for specifying a binding edge and an accompanying increased
margin size. However, the :left and :right page selectors can be used
to write style sheet rule sets for binding edges.
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Monday, February 09, 2004 10:01 PM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: www-style@w3.org
Subject: RE: [css3-page] LCWD issue 14 -- [14] Section 3.2


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; To: &lt;ernestcline@mindspring.com&gt;
&gt; Cc: &lt;www-style@w3.org&gt;
&gt; Date: 2/8/2004 2:43:04 PM
&gt; Subject: RE: [css3-page] LCWD issue 14 --  [14] Section 3.2
&gt;
&gt; Your issue, shown below, has been accepted by the editor.  If you have
&gt; any further comment on this topic, you have 7 days, until 15 February
&gt; 2004, to respond.
&gt;
&gt; &gt;
&gt; &gt; This section and the accompanying terminology assumes that the
&gt; &gt; standard Western practice of binding so that the spine is to the left
&gt; &gt; is the only standard.  This is NOT the case. Standard Japanese
&gt; &gt; practice is to bind printed matter so that the spine is to the right.
&gt; &gt; Given the unfortunate choice of :left and :right in CSS 2, I don't
&gt; &gt; have any expectation of changing the pseudo-classes, but the
&gt; &gt; explanatory material should be rewritten so as to be supportive of
&gt; &gt; Japanese binding.
&gt; &gt;
&gt;
&gt; You issue while true is vague as to how it should be accomplished.
&gt; The new text of this section is included below for your review.  Any
&gt; help you can offer to improve it would be welcomed.

Well, I didn't want to usurp your prerogatives, but here goes my
version of Section 3.2 I did take the liberty of using the term
pseudo-page in hopes that term is accepted.  If it isn't it should be
simple enough to revert back to pseudo-class.

Features of my draft:

1) Removed an ambiguity over whether a square page is portrait or
   landscape by explicitly saying it doesn't matter.

2) Introduced a separate definition of Duplex Printing because it
   seemed to make what I wanted to say clearer.

3) Dropped all discussion of page numbering, largely because there is
   no guarantee that the page number of the nth page would be n,
   making discussion of page numbers irrelevant to the concepts
   described here.

4) Added a definition of Major Writing Direction with the intent of
   tying it to the value of the 'direction' property of the root
   element. I was uncertain whether to use MAY or MUST in the
   definition and it may well be that I overdid my attempt at tying
   down its value.

3.2. Page types

Pages and their corresponding page layouts have many possible
formats. Among the aspects of page layout that can vary are paper
size, orientation of the layout with respect to the paper, order of
the pages, how the document will be printed, and how the document will
be bound. Some of these depend upon factors such as the major writing
direction and the media type that are not be specified by this
module. The following terminology is used to describe pages and page
treatments:

Page Orientation

The page orientation is defined by comparing the length of the edges
of a page box. The page box is a rectangle with two perpendicular
edges called the long edge and the short edge.  The length of the long
edge is always greater than or equal to the length of the short edge.
When the page box is square, the two edges are of the same length and
either can be used as the long edge with the other being the short
edge.

Portrait Orientation

A portrait page's height is greater than or equal to its
width. Horizontal elements are parallel to the short edge and vertical
elements to the long edge.

Landscape Orientation

A landscape page's width is greater than or equal to its
height. Horizontal elements are parallel to the long edge and vertical
elements to the short edge.

Front Side

Media used as a stack of sheets have two sides known as the front and
the back. Typically, the user agent prints on the front side of the
media when using only one side of the page sheet.  Media used from a
roll or continuous form will print only on the front side. CSS does
not provide a mechanism to deal directly with the front and back
sides, rather page layouts must be designed in terms of left and right
pages.

Back Side

The back side of a sheet medium is the side that cannot be seen when
looking at the front side. Typically, the back side is only used when
printing on both sides of the medium.  Unless using special paper
stock such as letterhead it does not usually matter which side is the
front and which is the back.

Duplex Printing

Duplex printing uses one page box per side of a page sheet and uses
both sides of the page sheet.  This module provides no ability to
specify whether a document is duplex printed, but the concept of left
and right pages is based on the assumption that the document is duplex
printed, regardless of whether it actually is.

Binding Edge

The binding edge is the edge of the page box that is towards the
binding if the material is bound.  The binding edge often has a larger
margin than the opposite edge to provide for the space used by the
binding.  The binding edge can be any of the four edges.  However,
page sheets are customarily bound so that the binding edge of page
boxes with portrait orientation is vertical.  This module provides no
method to specify the binding edge.  In duplex printing, the binding
edge is on opposite sides of the page box for the left and right
pages.

Facing Pages

Facing pages are two sequential pages such that when the document is
duplex printed they are on separate sheets of paper. Typically, the
earlier page will be the back side of one sheet and the later page
will be the front side of another. They are usually laid out so that
the binding edges of facing pages are vertical and adjacent when the
pages are placed in their normal reading orientation.  It is up to the
UA to determine whether the left page or the right page of a pair of
facing pages is the earlier one of the sequence.  How the UA makes
this determination is implementation dependent but often depends upon
the predominant writing direction of the document.

Major Writing Direction

The major writing direction for the document is determined by the
UA. If the UA supports the 'direction' property from CSS2 or the CSS 3
Text Module it (MAY/MUST) determine it using the value of that
property on the root element.

Left Page

A page that will be on the left if it is part of a pair of facing
pages as typically laid out. Page layouts for documents using a
left-to-right major writing direction have the earlier of the facing
pages on the left.  Rules for the left page can be specified using the
:left pseudo-page selector.

Right Page

A page that will be on the right if it is part of a pair of facing
pages as typically laid out. Page layouts for documents using a
right-to-left writing major direction have the earlier of the facing
pages on the right.  Rules for the right page can be specified using
the :right pseudo-page selector.

First Page

The first page in a set of pages.  The UA determines which page is the
first page.  The first page is generally printed on the front side of
a medium.  Rules for the first page can be specified using the :first
pseudo-page selector.  A first page can be either a left page or a
right page but a UA MUST apply any rules defined for a first page in
preference to those defined on a left page or a right page.

</pre>
<h2><a id="issue15" name="issue15">1.15  [15] Section 3.2 "Back side"
</a></h2><p><b>PROBLEM ID: 15</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [15] Section 3.2 "Back side"
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

In the sentence "Typically, the back side is only used when printing
on both side of the medium." the phrase "on both side" should be "on
both sides".

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 15 --  [15] Section 3.2 "Back side"
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 15.
&gt;
&gt; In the sentence "Typically, the back side is only used when printing
&gt; on both side of the medium." the phrase "on both side" should be "on
&gt; both sides".
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 15 -- [15] Section 3.2 "Back side"

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; In the sentence "Typically, the back side is only used when printing
&gt; on both side of the medium." the phrase "on both side" should be "on
&gt; both sides".
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue16" name="issue16">1.16  [16] Section 3.2 "First page"
</a></h2><p><b>PROBLEM ID: 16</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [16] Section 3.2 "First page"
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

In the clause "documents where the writing direction is right-to-left
my cause the printer to place the first page on the back side of the
first sheet" the word "my" should be "may".

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 16 --  [16] Section 3.2 "First page"
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 16.
&gt;
&gt; In the clause "documents where the writing direction is right-to-left
&gt; my cause the printer to place the first page on the back side of the
&gt; first sheet" the word "my" should be "may".
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 16 -- [16] Section 3.2 "First page"

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; In the clause "documents where the writing direction is right-to-left
&gt; my cause the printer to place the first page on the back side of the
&gt; first sheet" the word "my" should be "may".
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue17" name="issue17">1.17  [17] Section 3.2 "Left page"
</a></h2><p><b>PROBLEM ID: 17</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [17] Section 3.2 "Left page"
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

According to the only English dictionary I have been able to find that
mentioned this term, "versos" is the plural and "verso" is the
singular. The definition is written so that the singular should be
used.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 17 --  [17] Section 3.2 "Left page"
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 17.
&gt;
&gt; According to the only English dictionary I have been able to find that
&gt; mentioned this term, "versos" is the plural and "verso" is the
&gt; singular. The definition is written so that the singular should be
&gt; used.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 17 -- [17] Section 3.2 "Left page"

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; According to the only English dictionary I have been able to find that
&gt; mentioned this term, "versos" is the plural and "verso" is the
&gt; singular. The definition is written so that the singular should be
&gt; used.
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue18" name="issue18">1.18  [18] Section 3.2 "Right page"
</a></h2><p><b>PROBLEM ID: 18</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [18] Section 3.2 "Right page"
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

According to the only English dictionary I have been able to find that
mentioned this term, "rectos" is the plural and "recto" is the
singular. The definition is written so that the singular should be
used.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 18 --  [18] Section 3.2 "Right page"
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 18.
&gt;
&gt; According to the only English dictionary I have been able to find that
&gt; mentioned this term, "rectos" is the plural and "recto" is the
&gt; singular. The definition is written so that the singular should be
&gt; used.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 18 -- [18] Section 3.2 "Right page"

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; According to the only English dictionary I have been able to find that
&gt; mentioned this term, "rectos" is the plural and "recto" is the
&gt; singular. The definition is written so that the singular should be
&gt; used.
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue19" name="issue19">1.19  [19] Section 3.3
</a></h2><p><b>PROBLEM ID: 19</b></p>
<p><b>STATE: closed
<br />RESOLUTION:accepted, spec updated
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [19] Section 3.3
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

In the sentence "Different parts of the world uses different paper
sizes." the verb "uses" should be in the singular form, "use".

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 19 --  [19] Section 3.3
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 19.
&gt;
&gt; In the sentence "Different parts of the world uses different paper
&gt; sizes." the verb "uses" should be in the singular form, "use".
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 19 -- [19] Section 3.3

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; In the sentence "Different parts of the world uses different paper
&gt; sizes." the verb "uses" should be in the singular form, "use".
&gt;


   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue20" name="issue20">1.20  [20] Section 3.3.1 Example
</a></h2><p><b>PROBLEM ID: 20</b></p>
<p><b>STATE: closed
<br />RESOLUTION:accepted, spec updated.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [20] Section 3.3.1 Example
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

As Lachlan Hunt has already pointed out, the "cm"s for the A4 paper
size need to be changed to "mm"s.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 20 --  [20] Section 3.3.1 Example
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 20.
&gt;
&gt; As Lachlan Hunt has already pointed out, the "cm"s for the A4 paper
&gt; size need to be changed to "mm"s.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 20 -- [20] Section 3.3.1 Example

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; As Lachlan Hunt has already pointed out, the "cm"s for the A4 paper
&gt; size need to be changed to "mm"s.
&gt;


   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue21" name="issue21">1.21  [21] Section 3.3.2
</a></h2><p><b>PROBLEM ID: 21</b></p>
<p><b>STATE: closed
<br />RESOLUTION:duplicate of #36
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [21] Section 3.3.2
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Having opened Pandora's box with "A4" and "letter", I feel that the
standard should either (1) explain why the decision was made to limit
the listed sizes to just these two, (2) drop these sizes, or (3)
change the list of predefined sizes and explain why those were chosen.

With "A4" and "letter" as part of the standard, it does not take much
imagination to suppose that there will be those who try to extend the
standard on their own.  It would be best if the standard tries to
control these non-standard extensions is some manner.

For example, one could justify supporting only the ISO defined paper
sizes (ISO 216). envelope sizes (ISO 269), etc. by way of
non-hyphenated keywords.  Then if national sizes need to be predefined
as well, the standard could specify a convention such as:
&lt;country-code&gt; "-" &lt;name&gt; Thus, we could have "us-letter" "ca-p4" or
"ja-b4" if including keywords for national standard paper sizes be
deemed necessary.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 21 --  [21] Section 3.3.2
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 21.
&gt;
&gt; Having opened Pandora's box with "A4" and "letter", I feel that the
&gt; standard should either (1) explain why the decision was made to limit
&gt; the listed sizes to just these two, (2) drop these sizes, or (3)
&gt; change the list of predefined sizes and explain why those were chosen.
&gt;
&gt; With "A4" and "letter" as part of the standard, it does not take much
&gt; imagination to suppose that there will be those who try to extend the
&gt; standard on their own.  It would be best if the standard tries to
&gt; control these non-standard extensions is some manner.
&gt;
&gt; For example, one could justify supporting only the ISO defined paper
&gt; sizes (ISO 216). envelope sizes (ISO 269), etc. by way of
&gt; non-hyphenated keywords.  Then if national sizes need to be predefined
&gt; as well, the standard could specify a convention such as:
&gt; &lt;country-code&gt; "-" &lt;name&gt; Thus, we could have "us-letter" "ca-p4" or
&gt; "ja-b4" if including keywords for national standard paper sizes be
&gt; deemed necessary.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Wednesday, January 07, 2004 5:22 PM
To: www-style@w3.org; ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 21 -- [21] Section 3.3.2


Ernest,

The list of media names is very large and unbounded. See The Printer
Working Group Standard for Media Standardized Names [1].  However,
specifying the media names letter and A4: 1. addresses a very large
number of uses, 2. is notationally convenient (more so than 8.5 11in,
etc.), and 3. is not prone to math round-off or representational
errors may not match the specification by numbers to their internal
representation of media sizes.  For example, its more accurate and
less ambiguous to say A4 than 210m 297mm which when converted to
printer dots (at 600dpi, 1200dpi, etc) may not match the internal
representation.

I attempted a compromise by using the two most often used names/sizes
rather than all media names.

Comments?

Jim

[1] ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf

&gt; -----Original Message-----
&gt; From: James Bigelow [mailto:jhb@jhb.boi.hp.com]
&gt; Sent: Wednesday, January 07, 2004 4:44 PM
&gt; To: www-style@w3.org; ernestcline@mindspring.com
&gt; Subject: [css3-page] LCWD issue 21 -- [21] Section 3.3.2
&gt;
&gt;
&gt; Thank you for your comment on the CSS3 Paged Media Module,
&gt; archived in:
&gt; http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.htm
l

Your issue, shown below, has been assigned the number 21.
&gt;
&gt; Having opened Pandora's box with "A4" and "letter", I feel that the
&gt; standard should either (1) explain why the decision was made to limit
&gt; the listed sizes to just these two, (2) drop these sizes, or (3)
&gt; change the list of predefined sizes and explain why those were chosen.
&gt;
&gt; With "A4" and "letter" as part of the standard, it does not take much
&gt; imagination to suppose that there will be those who try to extend the
&gt; standard on their own.  It would be best if the standard tries to
&gt; control these non-standard extensions is some manner.
&gt;
&gt; For example, one could justify supporting only the ISO defined paper
&gt; sizes (ISO 216). envelope sizes (ISO 269), etc. by way of
&gt; non-hyphenated keywords.  Then if national sizes need to be predefined
&gt; as well, the standard could specify a convention such as:
&gt; &lt;country-code&gt; "-" &lt;name&gt; Thus, we could have "us-letter" "ca-p4" or
&gt; "ja-b4" if including keywords for national standard paper sizes be
&gt; deemed necessary.
&gt;

A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.

   -- Jim Bigelow, Editor
</pre>
<p><b>

   FOLLOWUP 02:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Wednesday, January 07, 2004 10:26 PM
To: W3C CSS List
Subject: FW: RE: [css3-page] LCWD issue 21 -- [21] Section 3.3.2


Sorry about that. I guess I hit Reply instead of Reply All on this one.

&gt; [Original Message]
&gt; From: Ernest Cline &lt;ernestcline@mindspring.com&gt;
&gt; To: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; Date: 1/7/2004 11:21:43 PM
&gt; Subject: RE: [css3-page] LCWD issue 21 --  [21] Section 3.3.2
&gt;
&gt;
&gt;
&gt;
&gt; &gt; [Original Message]
&gt; &gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; &gt; To: &lt;www-style@w3.org&gt;; &lt;ernestcline@mindspring.com&gt;
&gt; &gt; Date: 1/7/2004 8:19:51 PM
&gt; &gt; Subject: [css3-page] LCWD issue 21 --  [21] Section 3.3.2
&gt; &gt;
&gt; &gt; Ernest,
&gt; &gt;
&gt; &gt; The list of media names is very large and unbounded. See The Printer
&gt; &gt; Working Group
&gt; &gt; Standard for Media Standardized Names [1].  However, specifying the
&gt; &gt; media names letter and A4:
&gt; &gt; 1. addresses a very large number of uses,
&gt; &gt; 2. is notationally convenient (more so than 8.5 11in, etc.), and
&gt; &gt; 3. is not prone to math round-off or representational errors may not
&gt; &gt; match the specification by numbers to their internal representation of
&gt; &gt; media sizes.  For example, its more accurate and less ambiguous to
&gt; &gt; say A4 than 210m 297mm which when converted to printer dots (at
&gt; &gt; 600dpi, 1200dpi, etc)
&gt; &gt; may not match the internal representation.
&gt; &gt;
&gt; &gt; I attempted a compromise by using the two most often used
&gt; &gt; names/sizes rather
&gt; &gt; than all media names.
&gt; &gt;
&gt; &gt; Comments?
&gt; &gt;
&gt; &gt; Jim
&gt; &gt;
&gt; &gt; [1] ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf
&gt;
&gt; The worry about size and bounds could also be said to apply to
&gt; MIME types and languages.  In this case, since there already exists
&gt; an organization which is defining labels for paper sizes and allows
&gt; free access to those labels, why not just go ahead and use them?
&gt;
&gt; If you are worried about overexactness or name length, that standard
&gt; allows the size information to be dropped and to use only the
&gt; class-name and the size-name.  (Given the possibility of confusion
&gt; between the ISO B# sizes and the JIS B# sizes, I would not recommend
&gt; the allowed usage of just size name.) So, we could have iso_b4 or
&gt; na_letter or even om_juuro-ku-kai and let the UA decide which sizes it
&gt; can or will support.
&gt;
&gt;  Add in support for the self-describing names and then by using names
&gt; such as custom_pre-shredded_1x297mm the standard could support custom
&gt; page sizes without having to use a &lt;length&gt; unit that is different
&gt; from any other usage of &lt;length&gt; in the standard. Having  exceptions
&gt; to standard values is not a good idea.  Handling custom sizes this way
&gt; allows the standard to avoid the use of  em and ex and how often will
&gt; someone really want to specify a paper size in px or pt?
&gt;
&gt; For a non-technical user, they would be able to specify just
&gt; "na_letter" or "na_legal" or "iso_a4" for the common sizes, while
&gt; technical users would probably use the full descriptive names for the
&gt; uncommonly used paper sizes assuming that they bother to write
&gt; specific rules for them, while increasing the chance that the UA would
&gt; be able to understand what they mean.  It might be worth including
&gt; required support for certain common sizes such as "na_letter",
&gt; "na_legal", "na_tabloid", "iso_a4", etc. But I don't think it is
&gt; essential.  If a UA supports printing to a common paper size it will
&gt; almost certainly be able to understand the short form of the name,
&gt; while a user who wishes to use an unusual paper size will almost
&gt; certainly be aware that it would be a good idea to include the
&gt; official dimensions.


</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 21 -- [21] Section 3.3.2

Your issue, shown below, has been has been resolved by the editor as a
duplicate of issue 36 [1] and its accompany message thread.  If you
have any further comment on this topic, you have 7 days, until 16
February 2004, to respond.

&gt;
&gt; Having opened Pandora's box with "A4" and "letter", I feel that the
&gt; standard should either (1) explain why the decision was made to limit
&gt; the listed sizes to just these two, (2) drop these sizes, or (3)
&gt; change the list of predefined sizes and explain why those were chosen.
&gt;
&gt; With "A4" and "letter" as part of the standard, it does not take much
&gt; imagination to suppose that there will be those who try to extend the
&gt; standard on their own.  It would be best if the standard tries to
&gt; control these non-standard extensions is some manner.
&gt;
&gt; For example, one could justify supporting only the ISO defined paper
&gt; sizes (ISO 216). envelope sizes (ISO 269), etc. by way of
&gt; non-hyphenated keywords.  Then if national sizes need to be predefined
&gt; as well, the standard could specify a convention such as:
&gt; &lt;country-code&gt; "-" &lt;name&gt; Thus, we could have "us-letter" "ca-p4" or
&gt; "ja-b4" if including keywords for national standard paper sizes be
&gt; deemed necessary.
&gt;


   -- Jim Bigelow, Editor

[1] http://lists.w3.org/Archives/Public/www-style/2004Jan/0158.html
</pre>
<h2><a id="issue22" name="issue22">1.22  [22] Section 3.3.2 <length>
</a></h2><p><b>PROBLEM ID: 22</b></p>
<p><b>STATE: closed
<br />RESOLUTION:accepted, spec updated.

<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [22] Section 3.3.2 &lt;length&gt;
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Why does the page context have no notion of fonts?  Couldn't this be
the same as the notion held by ":root" exterior to this @-rule?  Or
does this introduce some sort of loop that isn't apparent to me?
Granted, specifying page margins with respect to font size may not be
a good thing to do most of the time, but I fail to see why it is
impossible.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 22 --  [22] Section 3.3.2 &lt;length&gt;
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 22.
&gt;
&gt; Why does the page context have no notion of fonts?  Couldn't this be
&gt; the same as the notion held by ":root" exterior to this @-rule?  Or
&gt; does this introduce some sort of loop that isn't apparent to me?
&gt; Granted, specifying page margins with respect to font size may not be
&gt; a good thing to do most of the time, but I fail to see why it is
&gt; impossible.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Sunday, February 15, 2004 9:41 PM
To: BIGELOW,JIM (HP-Boise,ex1); W3C CSS List
Subject: RE: [css3-page] LCWD issue 22 -- [22] Section 3.3.2 &lt;length&gt;

&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt;
&gt; You issue (#22) shown below has been rejected.
&gt;
&gt; &gt;
&gt; &gt; Why does the page context have no notion of fonts?  Couldn't this be
&gt; &gt; the same as the notion held by ":root" exterior to this @-rule?  Or
&gt; &gt; does this introduce some sort of loop that isn't apparent to me?
&gt; &gt; Granted, specifying page margins with respect to font size may not be
&gt; &gt; a good thing to do most of the time, but I fail to see why it is
&gt; &gt; impossible.
&gt;
&gt; The page context does not have a font associated with it.  The
&gt; document's content as embodied in the body of the document has one or
&gt; more fonts, but the page does not. I don't understand you comment
&gt; about the ":root" exterior.

In your earlier response on this issue [1] you said:

"The page context comes before and is independent of content.  You
don't want to specify the width of the page in points. It's a physical
sheet of paper, better suited to be described in absolute terms. "

However, what the size property is describing is not the size of a
page sheet which is physical, but the size of a page box.  Granted,
the usual intent will be to specify a page box that will occupy a page
sheet exactly, but that is not the only use for specifying the size of
a page box.  Therefore, an author might wish to specify an abstract
page box which the UA will then fit if his intent is to insure that a
certain number of lines will be printed per page The mechanism would
in essence be no different from having specified "size:A4" and the UA
having to decide how to print the A4-sized page box on a letter-sized
page sheet. Thus the physicality of the page sheet is not a relevant
point. The only relevant point is "Is there a reasonable
interpretation for the relative units "em", and "ex" with respect to
the page box?"

The root element (in XHTML that would the single occurrence of &lt;html&gt;)
has a font size as determined by the UA if there is no CSS rule that
sets the size or is defined by the cascade if it is not.  That was the
font size I was thinking that could be used to specify the dimensions
of a page box that used "em" or "ex".  Consider the following simple
stylesheet:

@page {
size: 25em 17.5em;
margin: 2.5em;
}
:root {
font-size: 24pt;
}

This would make this effectively the same as if @page had been defined as:

@page {
size: 600pt 420pt;
margin: 60pt;
}

which is allowed by the current interpretation.

The UA will have to determine the value of 'font-size' for the root
element of the document, and this does not involve any of the rules
contained in @page.  This is what I was referring to when I said, "the
same as the notion held by ':root' exterior to this @-rule".

Using this notion does not appear to cause any problems with
determining specified values in the cascade [2] as at this part of the
cascade the @page rule and the rulesets for the elements do not
interact.

At the computed values [3] stage we do have an interaction.  For
elements, the computed values for 'height' and 'width' and other
related properties can depend upon the computed value of the initial
containing block which will depend upon the computed value of the
'size' of the page box. The computed value of the 'size' of the page
box could depend upon the computed 'font-size' of the root element.
This computed 'font-size' will be an absolute value and will not
depend upon anything other than the specified value of the 'font-size'
of the root element and maybe the default value chosen by the UA.

Thus the only requirement that I can see that is imposed by allowing
"em" and "ex" to be used to express the size of the page box, is that
when determining computed values, the following additional constraint
on the order of doing the determination is imposed.

   Determine the computed value of 'font-size' for the root element.
   before determining the computed value of 'size', 'margin', 'border',
   and 'padding' for the page box.

This does not appear to introduce any inefficiencies upon the process,
altho it does mean that the determination of some computed values of
the page box interact with those of the root element. (See below for
an alternative that avoids even this.)

So unless I am totally missing something here, it would seem that it
should not be impossible (or even difficult) to determine the size of
the page box with respect to font size.  For the page sheet, it would
be ridiculous to talk about specifying the size in terms of font size,
but the page sheet is not what is being specified in this module.

As a final aside, the statement, "The page context has no notion of
fonts," while true for CSS2 would seem to no longer apply for CSS 3.
In CSS 2 there was no provision for adding content to the @page rule.
While it would not makes sense in CSS3 to add content directly to
@page, the margin boxes which are defined inside the page box do have
content which will require a notion of fonts.  Unless the margin boxes
are not considered to be part of the page context, which would seem to
be very strange, there is now text associated with the page box, and
there fore it would make sense for the page box to have a notion of
fonts.  After all, why wouldn't one want to be able to specify:

@page {
  font-size:9pt;
  counter-increment: page;

  @top-center{ content: "An Example" }

  @bottom-center {
    content: "Page " counter(page);
    content: "Page " counter(page) " of " counter(pages);
  }
}

so that one wouldn't have to specify a 'font-size' for each margin box
instead.  If the page box had a notion of fonts, It might be
reasonable for it to have a notion independent of the root element.
That would enable the page box to retain its traditional independence
from the properties of the elements of the document tree, while
providing a definition of 'font-size' that could be used to determine
what the "em" and "ex" units refer to in the case of 'size', 'margin',
'border', and 'padding'.

[1] http://lists.w3.org/Archives/Public/www-style/2004Jan/0038.html

[2] http://www.w3.org/TR/CSS21/cascade.html#specified-value

[3] http://www.w3.org/TR/CSS21/cascade.html#computed-value


</pre>
<p><b>

   FOLLOWUP 02:

   </b></p><pre>
To: ernestcline@mindspring.com; =SMTP:jim.bigelow@hp.com; W3C CSS List
Subject: RE: [css3-page] LCWD issue 22 -- [22] Section 3.3.2 &lt;length&gt;

Ernest wrote [1]:
&gt; ... what the size property is describing is not the size
&gt; of a page sheet which is physical, but the size of a page
&gt; box.  Granted, the usual intent will be to specify a page box
&gt; that will occupy a page sheet exactly, but that is not the
&gt; only use for specifying the size of a page box.  Therefore,
&gt; an author might wish to specify an abstract page box which
&gt; the UA will then fit if his intent is to insure that a
&gt; certain number of lines will be printed per page  The
&gt; mechanism would in essence be no different from having
&gt; specified "size:A4" and the UA having to decide how to print
&gt; the A4-sized page box on a letter-sized page sheet. Thus the
&gt; physicality of the page sheet is not a relevant point. The
&gt; only relevant point is "Is there a reasonable interpretation
&gt; for the relative  units "em", and "ex" with respect to the page box?"

After reading the line of reasoning in [1], I disagree.

The Chicago Manual of Style defines em as, "The unit of linear measure
equal to the point size of the type in question." The CSS 2.0 and 2.1
specifications define em and ex as relative units. Reference to the
width variability fonts is missing from the reasoning in [1]. The
units ex and em are defined in terms of a font, and so can be
different for Serif and Sans-Serif.

Use of em and ex makes sense in the context of text where the
font-family, font-size, font-weight, font-style, font-stretch,
font-variant, line-height and letter-spacing properties apply to an
abstract character sequence [2].  However, both the document (content
of body element) and page box can contain many abstract character
sequences with different values of em and ex.  Requiring the UA to
determine the values of em and ex before determining the size of the
page could require multiple passes through the document.

On another note, I don't see that the document author gains much in
clarity of style sheets or usability of CSS properties by allowing the
use of em and ex.

Points and picas are units of absolute length rather than relative
units.  The other relative unit, px (pixel) is device dependent.
Images printed in a 300 dot per inch device may not be the same size
as one rendered on a 600 dpi device. The same pitfall of device
dependence holds for specifying the page size in pixels.

[1] http://lists.w3.org/Archives/Public/www-style/2004Feb/0296.html
[2] http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf, D4, Page 64.</pre>
<p><b>

   FOLLOWUP 03:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Boris Zbarsky
[bzbarsky@MIT.EDU]
Sent: Tuesday, February 17, 2004 12:55 PM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: ernestcline@mindspring.com; W3C CSS List
Subject: Re: [css3-page] LCWD issue 22 -- [22] Section 3.3.2 &lt;length&gt;


&gt; Points and picas are units of absolute length rather than relative
&gt; units. The other relative unit, px (pixel) is device dependent.
&gt; Images printed in a  300 dot per inch device may not be the same size
&gt; as one rendered on a 600 dpi device. The same pitfall of device
&gt; dependence holds for specifying the page size in pixels.

Actually, if I understand the definition of "pixel" in CSS correctly,
that is precisely what should NOT happen if pixels are implemented
correctly.  In CSS "pixel" does not refer to a dot but rather to a
solid angle in the field of view.  Therefore a "300px" image should
have the same physical dimensions (as measured with a ruler) no matter
what the medium, as long as the viewing distance is held constant
(modulo the possily low resolution of the imaging device, actually).

This is not a problem with desktops yet, since they almost all have
basically the same DPI.  But with the appearance of 200+ dpi LCD
displays on the market will expose the fact many implementations do
_not_ in fact implement CSS pixel units correctly and should hopefully
lead to said implementations being corrected (for the simple reason
that on such a display a CSS implementation which directly maps pixels
to screen dots will show all images 1/2 to 1/3 of the size they really
should be, and the discrepancy will be glaringly obvious).

Boris
--
A computer lets you make more mistakes faster than any invention in
human history, with the possible exceptions of handguns and tequila.
</pre>
<p><b>

   FOLLOWUP 04:

   </b></p><pre>
To: Boris Zbarsky
Cc: W3C CSS List
Subject: RE: [css3-page] LCWD issue 22 -- [22] Section 3.3.2 &lt;length&gt;

Boris wrote:
&gt; Actually, if I understand the definition of "pixel" in CSS
&gt; correctly, that is precisely what should NOT happen if pixels
&gt; are implemented correctly.  In CSS "pixel" does not refer to
&gt; a dot but rather to a solid angle in the field of view.
&gt; Therefore a "300px" image should have the same physical
&gt; dimensions (as measured with a ruler) no matter what the
&gt; medium, as long as the viewing distance is held constant
&gt; (modulo the possily low resolution of the imaging device, actually).
&gt;
 Thank you, I stand corrected.
  - Jim
</pre>
<p><b>

   FOLLOWUP 05:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Tuesday, February 17, 2004 1:33 PM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: W3C CSS List
Subject: RE: [css3-page] LCWD issue 22 -- [22] Section 3.3.2 &lt;length&gt;


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; To: &lt;ernestcline@mindspring.com&gt;
&gt; Cc: W3C CSS List &lt;www-style@w3.org&gt;
&gt; Date: 2/17/2004 3:23:01 PM
&gt; Subject: RE: [css3-page] LCWD issue 22 --  [22] Section 3.3.2 &lt;length&gt;
&gt;
&gt;
&gt; Ernest wrote [1]:
&gt; &gt; ... what the size property is describing is not the size
&gt; &gt; of a page sheet which is physical, but the size of a page
&gt; &gt; box.  Granted, the usual intent will be to specify a page box
&gt; &gt; that will occupy a page sheet exactly, but that is not the
&gt; &gt; only use for specifying the size of a page box.  Therefore,
&gt; &gt; an author might wish to specify an abstract page box which
&gt; &gt; the UA will then fit if his intent is to insure that a
&gt; &gt; certain number of lines will be printed per page  The
&gt; &gt; mechanism would in essence be no different from having
&gt; &gt; specified "size:A4" and the UA having to decide how to print
&gt; &gt; the A4-sized page box on a letter-sized page sheet. Thus the
&gt; &gt; physicality of the page sheet is not a relevant point. The
&gt; &gt; only relevant point is "Is there a reasonable interpretation
&gt; &gt; for the relative  units "em", and "ex" with respect to the page box?"
&gt;
&gt; After reading the line of reasoning in [1], I disagree.
&gt;
&gt; The Chicago Manual of Style defines em as, "The unit of linear measure
&gt; equal to the point size of the type in question." The CSS 2.0 and 2.1
&gt; specifications define em and ex as relative units. Reference to the
&gt; width variability fonts is missing from the reasoning in [1]. The
&gt; units ex and
em
&gt; are defined in terms of a font, and so can be different for Serif and
&gt; Sans-Serif.

What variability are you referring to?  The context that would be used
would have exactly one font.  While that font could differ based on
what fonts the UA has available, it would be easily and uniquely
determined for a given UA and set of stylesheets.  So yes, different
UA's might size the page box differently in terms of absolute units,
but where you see that as a disadvantage, I see that as an advantage.
In any case, given that the relative unit "px" is already acceptable
for page boxes, that page boxes can have different absolute sizes is
already present in CSS.  While this would be a problem for the page
sheet. This module doesn't specify page sheets, but page boxes.

&gt; Use of em and ex makes sense in the context of text where the
&gt; font-family, font-size, font-weight, font-style, font-stretch,
&gt; font-variant,
line-height
&gt; and letter-spacing properties apply to an abstract character sequence
&gt; [2]. However, both the document (content of body element) and page box
&gt; can contain many abstract character sequences with different values of
&gt; em and ex.  Requiring the UA to determine the values of em and ex
&gt; before determining the size of the page could require multiple passes
&gt; through the document.

What multiple passes?  I'm not talking about resizing the page box for
every page based on the fonts used on it.  I am talking about using a
size based upon ONE SPECIFIC FONT DEFINITION.  My initial thinking was
that it would be should be the same as that used by the root element
of the document.  Thinking further on this has caused me to come to
the conclusion that it should be a font defined by the page box, a
definition that would also be inherited by the margin boxes it
contains.  Even if my old premise of using the font definition used by
the root element was followed (or if the page box were to inherit its
font definition from the root element), I showed in my previous post
[1] that it WOULD NOT REQUIRE MULTIPLE PASSES.  The only thing that
would be added was one specific change in the normal order of
calculating "computed values".

&gt; On another note, I don't see that the document author gains much in
clarity
&gt; of style sheets or usability of CSS properties by allowing the use of
&gt;em and ex.

The main benefit is actually to an implementer of a UA, in that the
definition of &lt;length&gt; will not need to be special cased for
properties that occur in the page box.  The side benefit of being able
to define the page in terms of a font is agreeably a minor benefit.

&gt; Points and picas are units of absolute length rather than relative
&gt; units. The other relative unit, px (pixel) is device dependent.
&gt; Images printed
in
&gt; a  300 dot per inch device may not be the same size as one rendered on
&gt; a 600 dpi device. The same pitfall of device dependence holds for
&gt; specifying the page size in pixels.

And yet "px" is allowed and has been since CSS 2. The exclusion of
"em" and "ex" could be justified for CSS 2, in that it would require
supporting a font context for the page box, solely for the point of
supporting the use of "em" and "ex".  As I showed in my previous post
in this thread, with the introduction of margin-boxes that can have
text content, there is now a reasonable use case for a font context in
the page box, which the margin boxes would inherit from.

&gt; [1] http://lists.w3.org/Archives/Public/www-style/2004Feb/0296.html
&gt; [2] http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf, D4, Page
&gt; 64.


</pre>
<p><b>

   FOLLOWUP 06:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Tuesday, February 17, 2004 1:52 PM
To: BIGELOW,JIM (HP-Boise,ex1); Boris Zbarsky
Cc: W3C CSS List
Subject: RE: [css3-page] LCWD issue 22 -- [22] Section 3.3.2 &lt;length&gt;


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; To: Boris Zbarsky &lt;bzbarsky@MIT.EDU&gt;
&gt;
&gt; Boris wrote:
&gt; &gt; Actually, if I understand the definition of "pixel" in CSS
&gt; &gt; correctly, that is precisely what should NOT happen if pixels
&gt; &gt; are implemented correctly.  In CSS "pixel" does not refer to
&gt; &gt; a dot but rather to a solid angle in the field of view.
&gt; &gt; Therefore a "300px" image should have the same physical
&gt; &gt; dimensions (as measured with a ruler) no matter what the
&gt; &gt; medium, as long as the viewing distance is held constant
&gt; &gt; (modulo the possily low resolution of the imaging device, actually).
&gt;
&gt;  Thank you, I stand corrected.

Close, but not quite.  What should happen is that 1px should be
selected so that it is an integral multiple of the device pixel that
comes closest to having the desired size of the reference pixel, which
also depends upon the desired

Thus for example, both CSS2.1 and CSS3 Values suggest that a 300dpi
printer should use 1px = 3dots while a 600dpi printer should use 1px =
5dots.

</pre>
<p><b>

   FOLLOWUP 07:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1)
Sent: Tuesday, February 17, 2004 1:59 PM
To: H�kon Wium Lie; 'Ian Hickson'; 'Tantek �elik'; 'Bert Bos'; L. David
Baron
Cc: 'ernestcline@mindspring.com'
Subject: FW: [css3-page] LCWD issue 22 -- [22] Section 3.3.2 &lt;length&gt;

H�kon, Ian, Tantek, Bert and David,

Do you have an opinion on Ernest's proposal? I feel that you should
explicitly express your support or rejection on this proposal.
Ernest's reasoning has convinced me.  If I don't hear otherwise by 9AM
Pacific Standard Time, 19 February 2003, I will accept it.

Jim

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Ernest Cline
Sent: Tuesday, February 17, 2004 1:33 PM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: W3C CSS List
Subject: RE: [css3-page] LCWD issue 22 -- [22] Section 3.3.2 &lt;length&gt;


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; To: &lt;ernestcline@mindspring.com&gt;
&gt; Cc: W3C CSS List &lt;www-style@w3.org&gt;
&gt; Date: 2/17/2004 3:23:01 PM
&gt; Subject: RE: [css3-page] LCWD issue 22 --  [22] Section 3.3.2 &lt;length&gt;
&gt;
&gt;
&gt; Ernest wrote [1]:
&gt; &gt; ... what the size property is describing is not the size
&gt; &gt; of a page sheet which is physical, but the size of a page
&gt; &gt; box.  Granted, the usual intent will be to specify a page box
&gt; &gt; that will occupy a page sheet exactly, but that is not the
&gt; &gt; only use for specifying the size of a page box.  Therefore,
&gt; &gt; an author might wish to specify an abstract page box which
&gt; &gt; the UA will then fit if his intent is to insure that a
&gt; &gt; certain number of lines will be printed per page  The
&gt; &gt; mechanism would in essence be no different from having
&gt; &gt; specified "size:A4" and the UA having to decide how to print
&gt; &gt; the A4-sized page box on a letter-sized page sheet. Thus the
&gt; &gt; physicality of the page sheet is not a relevant point. The
&gt; &gt; only relevant point is "Is there a reasonable interpretation
&gt; &gt; for the relative  units "em", and "ex" with respect to the page box?"
&gt;
&gt; After reading the line of reasoning in [1], I disagree.
&gt;
&gt; The Chicago Manual of Style defines em as, "The unit of linear measure
&gt; equal to the point size of the type in question." The CSS 2.0 and 2.1
&gt; specifications define em and ex as relative units. Reference to the
&gt; width variability fonts is missing from the reasoning in [1]. The
&gt; units ex and
em
&gt; are defined in terms of a font, and so can be different for Serif and
&gt; Sans-Serif.

What variability are you referring to?  The context that would be used
would have exactly one font.  While that font could differ based on
what fonts the UA has available, it would be easily and uniquely
determined for a given UA and set of stylesheets.  So yes, different
UA's might size the page box differently in terms of absolute units,
but where you see that as a disadvantage, I see that as an advantage.
In any case, given that the relative unit "px" is already acceptable
for page boxes, that page boxes can have different absolute sizes is
already present in CSS.  While this would be a problem for the page
sheet. This module doesn't specify page sheets, but page boxes.

&gt; Use of em and ex makes sense in the context of text where the
&gt; font-family, font-size, font-weight, font-style, font-stretch,
&gt; font-variant,
line-height
&gt; and letter-spacing properties apply to an abstract character sequence
&gt; [2]. However, both the document (content of body element) and page box
&gt; can contain many abstract character sequences with different values of
&gt; em and ex.  Requiring the UA to determine the values of em and ex
&gt; before determining the size of the page could require multiple passes
&gt; through the document.

What multiple passes?  I'm not talking about resizing the page box for
every page based on the fonts used on it.  I am talking about using a
size based upon ONE SPECIFIC FONT DEFINITION.  My initial thinking was
that it would be should be the same as that used by the root element
of the document.  Thinking further on this has caused me to come to
the conclusion that it should be a font defined by the page box, a
definition that would also be inherited by the margin boxes it
contains.  Even if my old premise of using the font definition used by
the root element was followed (or if the page box were to inherit its
font definition from the root element), I showed in my previous post
[1] that it WOULD NOT REQUIRE MULTIPLE PASSES.  The only thing that
would be added was one specific change in the normal order of
calculating "computed values".

&gt; On another note, I don't see that the document author gains much in
clarity
&gt; of style sheets or usability of CSS properties by allowing the use of
&gt;em and ex.

The main benefit is actually to an implementer of a UA, in that the
definition of &lt;length&gt; will not need to be special cased for
properties that occur in the page box.  The side benefit of being able
to define the page in terms of a font is agreeably a minor benefit.

&gt; Points and picas are units of absolute length rather than relative
&gt; units. The other relative unit, px (pixel) is device dependent.
&gt; Images printed
in
&gt; a  300 dot per inch device may not be the same size as one rendered on
&gt; a 600 dpi device. The same pitfall of device dependence holds for
&gt; specifying the page size in pixels.

And yet "px" is allowed and has been since CSS 2. The exclusion of
"em" and "ex" could be justified for CSS 2, in that it would require
supporting a font context for the page box, solely for the point of
supporting the use of "em" and "ex".  As I showed in my previous post
in this thread, with the introduction of margin-boxes that can have
text content, there is now a reasonable use case for a font context in
the page box, which the margin boxes would inherit from.

&gt; [1] http://lists.w3.org/Archives/Public/www-style/2004Feb/0296.html
&gt; [2] http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf, D4, Page
&gt; 64.


</pre>
<p><b>

   FOLLOWUP 08:

   </b></p><pre>
From: Ian Hickson [ian@hixie.ch]
Sent: Tuesday, February 17, 2004 2:50 PM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: H�kon Wium Lie; Tantek �elik; Bert Bos; L. David Baron;
ernestcline@mindspring.com
Subject: Re: FW: [css3-page] LCWD issue 22 -- [22] Section 3.3.2
&lt;length&gt;

On Tue, 17 Feb 2004, BIGELOW,JIM (HP-Boise,ex1) wrote:
&gt;
&gt; Do you have an opinion on Ernest's proposal? I feel that you should
&gt; explicitly express your support or rejection on this proposal.
&gt; Ernest's reasoning has convinced me.  If I don't hear otherwise by
&gt; 9AM Pacific Standard Time, 19 February 2003, I will accept it.

I'm fine with it so long as it works in the same way as 'rem' in CSS3,
namely, just uses the initial font, not the font on the :root
element. (Or, if 'font' is allowed to apply to the @page context, that
font. Given that @page{@top} can have a font, it seems to make sense
that @page could have one and it could then inherit down.)

--
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
</pre>
<p><b>

   FOLLOWUP 09:

   </b></p><pre>
From: Bert Bos [Bert.Bos@sophia.inria.fr]
Sent: Tuesday, February 17, 2004 5:03 PM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: H�kon Wium Lie; Ian Hickson; Tantek �elik; L. David Baron;
ernestcline@mindspring.com
Subject: Re: FW: [css3-page] LCWD issue 22 -- [22] Section 3.3.2
&lt;length&gt;

On Tue, 17 Feb 2004, BIGELOW,JIM (HP-Boise,ex1) wrote:

&gt; H�kon, Ian, Tantek, Bert and David,
&gt;
&gt; Do you have an opinion on Ernest's proposal? I feel that you should
&gt; explicitly express your support or rejection on this proposal.
&gt; Ernest's reasoning has convinced me.  If I don't hear otherwise by
&gt; 9AM Pacific Standard Time, 19 February 2003, I will accept it.

Let me see if I understand correctly:

The question is whether 'em' can be used in '@page {size: 10em 20em}'
We've said so far that that doesn't make sense, because '@page' can't
contain 'font-size' and thus the 'em' is undefined.

On the other hand, there is the notion of the UA default font and we
do allow 'html {font-size: 2em}' to refer to that UA default font.

I'm OK with allowing 'em' on the 'size' property, if it means the em
of that UA default font. There is no way in CSS to define its value,
not even in the user style sheet or in the UA style sheet, but that is
OK.


Bert
--
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

</pre>
<p><b>

   FOLLOWUP 10:

   </b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Thursday, February 19, 2004 6:22 PM
To: Bert Bos
Cc: H�kon Wium Lie; Ian Hickson; Tantek �elik; L. David Baron;
ernestcline@mindspring.com; www-style@w3.org
Subject: RE: FW: [css3-page] LCWD issue 22 -- [22] Section 3.3.2
&lt;length&gt;


Bert wrote:
&gt; On Tue, 17 Feb 2004, BIGELOW,JIM (HP-Boise,ex1) wrote:
&gt;
&gt; &gt; H�kon, Ian, Tantek, Bert and David,
&gt; &gt;
&gt; &gt; Do you have an opinion on Ernest's proposal? I feel that you should
&gt; &gt; explicitly express your support or rejection on this proposal.
&gt; &gt; Ernest's reasoning has convinced me.  If I don't hear otherwise by
&gt; &gt; 9AM Pacific Standard Time, 19 February 2003, I will accept it.
&gt;
&gt; Let me see if I understand correctly:
&gt;
&gt; The question is whether 'em' can be used in '@page {size:
&gt; 10em 20em}' We've said so far that that doesn't make sense,
&gt; because '@page' can't contain 'font-size' and thus the 'em'
&gt; is undefined.

Can you help me understand why and where it says that @page cannot
contain either font-size or font-family?  This is exactly Ernest seems
to be arguing for.  If they are allowed, then em and ex make sense.


 -- Jim
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'; www-style@w3.org
Subject: RE: [css3-page] LCWD issue 22 -- [22] Section 3.3.2 &lt;length&gt;

Ernest,

You issue (#22) shown below has been rejected.

&gt;
&gt; Why does the page context have no notion of fonts?  Couldn't this be
&gt; the same as the notion held by ":root" exterior to this @-rule?  Or
&gt; does this introduce some sort of loop that isn't apparent to me?
&gt; Granted, specifying page margins with respect to font size may not be
&gt; a good thing to do most of the time, but I fail to see why it is
&gt; impossible.
&gt;

The page context does not have a font associated with it.  The
document's content as embodied in the body of the document has one or
more fonts, but the page does not. I don't understand you comment
about the ":root" exterior.

   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1)
Sent: Friday, February 20, 2004 9:36 AM
To: 'ernestcline@mindspring.com'; 'www-style@w3.org'
Subject: RE: [css3-page] LCWD issue 22 -- [22] Section 3.3.2 &lt;length&gt;

Ernest,

Your issue, shown below, has been accepted by the editor.
&gt; &gt;
&gt; &gt; Why does the page context have no notion of fonts?  Couldn't this be
&gt; &gt; the same as the notion held by ":root" exterior to this @-rule?  Or
&gt; &gt; does this introduce some sort of loop that isn't apparent to me?
&gt; &gt; Granted, specifying page margins with respect to font size may not
&gt; &gt; be a good thing to do most of the time, but I fail to see why it is
&gt; &gt; impossible.
&gt; &gt;

The specification now reads, "The page context has a font associated
with it either by an explicit use of the 'font-family' and 'font-size'
properties or from the UA's default style sheet. Therefore, values in
units of 'em' and 'ex' refer to the page context's font."

 -- Jim Bigelow
</pre>
<h2><a id="issue23" name="issue23">1.23  [23] Section 3.4.1 Example
</a></h2><p><b>PROBLEM ID: 23</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Rejected, editorial comment, not change needed.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [23] Section 3.4.1 Example
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html


The placing of the comments in the example is haphazard.  Sometimes
they are inside the declaration block, other times they are outside.
Either placement is justifiable, but the example would look better if
comment placement were consistent.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 23 --  [23] Section 3.4.1 Example
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 23.
&gt;
&gt;
&gt; The placing of the comments in the example is haphazard.  Sometimes
&gt; they are inside the declaration block, other times they are outside.
&gt; Either placement is justifiable, but the example would look better if
&gt; comment placement were consistent.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: Ernest Cline [ernestcline@mindspring.com]
Sent: Saturday, February 07, 2004 8:55 PM
To: BIGELOW,JIM (HP-Boise,ex1); W3C CSS List
Subject: RE: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt;
&gt; &gt; I plan to amend the specification say that the UA MUST use
&gt; &gt; the declarations of the :first pseudo-class, if it exists,
&gt; &gt; rather than either the :left or :right declarations

I must say that now that I've noticed it, I don't like :first acting
differently from other pseudo-classes in overriding :left and :right
so that regardless of whether @page :left comes before or after @page
:first, the rules in @page :first take precedence, but that is the
behavior specified by CSS 2, so the question becomes which way do you
want consistency?

(i.e. do we want behavior in CSS3 matching that in CSS 2 or do we want
all pseudo-classes having equal merit?)

Perhaps :left, :right, and :first should become ::left. ::right and
::first? They do seem to act more like pseudo-elements than like
pseudo-classes anyway. And pseudo-elements such as ::first-letter and
::first-line have these sorts of defined interactions regardless of
the relative position of the rules in the stylesheet.  Of course as
legacy pseudo-elements, the forms :left, :right, and :first would have
to continue to be accepted anyway.  This allows the convention of all
pseudo-classes being equal to continue to apply while also preserving
the behavior specified in CSS 2 to be used in CSS3.

</pre>
<p><b>

   FOLLOWUP 02:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1)
Sent: Saturday, February 07, 2004 8:07 PM
To: W3C CSS List
Subject: RE: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example

Ernest,

You wrote:
&gt; &gt; Thus, the example either needs an @bottom-left-corner rule added to
&gt; &gt; the last declaration block or the comment needs to be changed, for
&gt; &gt; that rule will not produce an empty footer if the first page is a
&gt; &gt; left page.
&gt; &gt;
&gt; &gt;
&gt; I plan to amend the specification say that the UA MUST use
&gt; the declarations of the :first pseudo-class, if it exists,
&gt; rather than either the :left or :right declarations
&gt;

I understand you point, now.  If the document's first page is left,
since the declarations in the :first pseudo-class do not override
those in the :left, there would be a page number on the first page.  I
will amend the example as you suggest.

@page :left { @bottom-left-corner { ... /* left page numbers */ }}
@page :right { @bottom-right-corner { ... /* right page numbers */ }}
@page :first { @bottom-right-corner { ... /* empty footer on 1st page */ }
		   @bottom-left-corner { ... } }

If you have any further comment on this topic, you have 7 days, until
14 February 2004, to respond.

 -- Jim Bigelow
</pre>
<p><b>

   FOLLOWUP 03:

   </b></p><pre>
From: www-style-request@w3.org on behalf of L. David Baron
[dbaron@dbaron.org]
Sent: Saturday, February 07, 2004 10:41 PM
To: W3C CSS List
Subject: Re: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example


On Saturday 2004-02-07 23:54 -0500, Ernest Cline wrote:
&gt; Perhaps :left, :right, and :first should become ::left. ::right and
&gt; ::first? They do seem to act more like pseudo-elements than like
&gt; pseudo-classes anyway. And pseudo-elements such as ::first-letter

They seem more like pseudo-classes to me.  With normal selectors (used
in rules), pseudo-classes select things (elements) that are selected
by other selectors, whereas pseudo-elements select other things.  I
think it should be the same for page selectors -- both page names and
:left, :right, and :first select pages, so it seems odd to want to
turn the latter group into pseudo-elements rather than pseudo-classes.

To put it another way, there is no object that can be matched by both
a selector with a pseudo-element and a selector without one.  Making
:left, etc., pseudo-elements would mean that a single page box could
be selected both by a selector with a pseudo-element and a selector
without one.

-David

[1] http://www.w3.org/TR/2003/WD-css3-page-20031218/#syntax-page-selector

--
L. David Baron                                &lt;URL: http://dbaron.org/ &gt;
</pre>
<p><b>

   FOLLOWUP 04:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Sunday, February 08, 2004 11:49 AM
To: L. David Baron; W3C CSS List
Subject: Re: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example


&gt; [Original Message]
&gt; From: L. David Baron &lt;dbaron@dbaron.org&gt;
&gt;
&gt; They seem more like pseudo-classes to me.  With normal selectors (used
&gt; in rules), pseudo-classes select things (elements) that are selected
&gt; by other selectors, whereas pseudo-elements select other things.  I
&gt; think it should be the same for page selectors -- both page names and
&gt; :left, :right, and :first select pages, so it seems odd to want to
&gt; turn the latter group into pseudo-elements rather than pseudo-classes.
&gt;
&gt; To put it another way, there is no object that can be matched by both
&gt; a selector with a pseudo-element and a selector without one.  Making
&gt; :left, etc., pseudo-elements would mean that a single page box could
&gt; be selected both by a selector with a pseudo-element and a selector
&gt; without one.

I see your point as to why they are not analogous to pseudo-elements,
but that makes the :left, :right, and :first essentially neither fish
nor fowl since they are not acting like pseudo-classes either because
of what I mentioned earlier.

Perhaps they should be renamed pseudo-pages instead and they just
happen to look like pseudo-classes.  After all, they aren't usable as
ordinary pseudo-classes, or vice versa are they?  I realize its a bit
late to be picky about terminology, yet if they are going to be called
pseudo-classes, then to be consistent with pseudo-classes in general
then with the following example the color of a &lt;span&gt; on a first right
page would have to be red, while for CSS2 it must be blue.

@page :first {span {color:blue}}
@page :right {span {color:red}}

Of course, with either interpretation this next example always yields
a span on the first page with a color of blue under either
interpretation.

@page :right {span {color:red}}
@page :first {span {color:blue}}

So as I see it, in order to keep pseudo-class specificity consistent,
either CSS3 should call :left, :right, and :first by some other name
than pseudo-classes or it should change the rules so that like other
pseudo-classes the position of the rules determines which wins when
the rules have equal specificity.  If the name is changed, calling
them pseudo-pages would seem to make the most sense, and it is what
they are called in the grammar given in Section 3.4.1.  I can't see
that this issue is important enough to cause a set of valid CSS2 rules
to be interpreted differently under CSS3, so even if they are still
called pseudo-classes I would have to support maintaining consistency
with CSS2.

</pre>
<p><b>

   FOLLOWUP 05:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Michael Day
[mikeday@yeslogic.com]
Sent: Monday, February 09, 2004 12:46 AM
To: Ernest Cline
Cc: W3C CSS List
Subject: Re: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example


&gt; @page :first {span {color:blue}}
&gt; @page :right {span {color:red}}

Surely no level of CSS allows element selectors to be nested within page
rules in this way?

Michael

--
YesLogic Prince prints XML!
http://yeslogic.com
</pre>
<p><b>

   FOLLOWUP 06:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Monday, February 09, 2004 8:53 AM
To: Michael Day
Cc: W3C CSS List
Subject: Re: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example


&gt; [Original Message]
&gt; From: Michael Day &lt;mikeday@yeslogic.com&gt;
&gt; To: Ernest Cline &lt;ernestcline@mindspring.com&gt;
&gt; Cc: W3C CSS List &lt;www-style@w3.org&gt;
&gt; Date: 2/9/2004 11:43:56 PM
&gt; Subject: Re: [css3-page] LCWD issue 23 --  [23] Section 3.4.1 Example
&gt;
&gt;
&gt; &gt; @page :first {span {color:blue}}
&gt; &gt; @page :right {span {color:red}}
&gt;
&gt; Surely no level of CSS allows element selectors to be nested within
&gt; page
&gt; rules in this way?

You're right, the grammar says declaration not ruleset

however one can easily modify my examples to:

@page :first {background:blue}
@page :right {background:red}

and

@page :right {background:red}
@page :first {background:blue}

If :first and :right acted like other pseudo-classes the order of the
rules (since they have equal specificity) would determine whether a
right first page had a red or a blue background. Instead, because CSS2
insists that rules in :first always take precedence over :right, a
right first page should have a blue background with either example.
It would be more practical to change the terminology than to change
existing CSS2 behavior so that :first, :left, and :right acted like
regular pseudo-classes.

I am not asking for any change in behavior or rule interpretation,
just that :first, :left and :right not be called pseudo-classes.


</pre>
<p><b>

   FOLLOWUP 07:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Michael Day
[mikeday@yeslogic.com]
Sent: Monday, February 09, 2004 2:25 PM
To: Ernest Cline
Cc: W3C CSS List
Subject: Re: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example


Hi Ernest,

I see your point regarding the page "pseudo-classes"; in Prince we have
implemented them such that :first has higher specificity:

        any   = specific(0,0,0)
        left  = specific(0,0,1)
        right = specific(0,0,1)
        first = specific(0,1,0)
        named = specific(1,0,0)

However, the rule for regular element pseudo-classes is not so simple
either, due to the negated pseudo-class, whose specificity is the
specificity of the simple selector that it negates:

	*          = specific(0,0,0)
	foo        = specific(0,0,1)
	:link      = specific(0,1,0)
	#foo       = specific(1,0,0)
	:not(#foo) = specific(1,0,0)

Does this change anything?

Michael

--
YesLogic Prince prints XML!
http://yeslogic.com
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example

Your issue, shown below, has been rejected by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt;
&gt; The placing of the comments in the example is haphazard.  Sometimes
&gt; they are inside the declaration block, other times they are outside.
&gt; Either placement is justifiable, but the example would look better if
&gt; comment placement were consistent.
&gt;

The comments placed in outside versus inside the declaration blocks
have different purposes. Those within the declarations serve as
pseudo-code, albeit clumsily, while those outside the block are
explanations.

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue24" name="issue24">1.24  [24] Section 3.5
</a></h2><p><b>PROBLEM ID: 24</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Duplicate of #22
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [24] Section 3.5
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

As per [22], why does the page context have no notion of fonts?


</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 24 --  [24] Section 3.5
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 24.
&gt;
&gt; As per [22], why does the page context have no notion of fonts?
&gt;
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 24 -- [24] Section 3.5

Your issue, shown below, has been categorized as a duplicate of issue
22 by the editor.  If you have any further comment on this topic, you
have 7 days, until 16 February 2004, to respond.

&gt;
&gt; As per [22], why does the page context have no notion of fonts?
&gt;
&gt;


   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue25" name="issue25">1.25  [25] Section 3.6
</a></h2><p><b>PROBLEM ID: 25</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Rejected, comment on functionality outside scope of specification.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [25] Section 3.6
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

With :left and :right always being used even when printing
single-sided, how is an author supposed to be able to specify that he
wants one set of rules used when printing single-sided and a different
set of rules when printing double-sided?  The easiest solution seems
to be to specify two new media types for single-sided and double-sided
paged printing (and possibly a third for printing using a continuous
non-paged roll, altho that could be said to be outside the scope of
this module).

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 25 --  [25] Section 3.6
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 25.
&gt;
&gt; With :left and :right always being used even when printing
&gt; single-sided, how is an author supposed to be able to specify that he
&gt; wants one set of rules used when printing single-sided and a different
&gt; set of rules when printing double-sided?  The easiest solution seems
&gt; to be to specify two new media types for single-sided and double-sided
&gt; paged printing (and possibly a third for printing using a continuous
&gt; non-paged roll, altho that could be said to be outside the scope of
&gt; this module).
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Wednesday, January 07, 2004 5:29 PM
To: www-style@w3.org; ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 25 -- [25] Section 3.6


Ernest,

It seems to me that using Media Queries [1] provides the best way to
set one set of rules for duplex printer and another for simplex
devices.  As you say, I think it is outside the scope of this doc.

Jim
[1] http://www.w3.org/TR/css3-mediaqueries/

&gt; -----Original Message-----
&gt; From: James Bigelow [mailto:jhb@jhb.boi.hp.com]
&gt; Sent: Wednesday, January 07, 2004 4:44 PM
&gt; To: www-style@w3.org; ernestcline@mindspring.com
&gt; Subject: [css3-page] LCWD issue 25 -- [25] Section 3.6
&gt;
&gt;
&gt; Thank you for your comment on the CSS3 Paged Media Module,
&gt; archived in:
&gt; http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 25.
&gt;
&gt; With :left and :right always being used even when printing
&gt; single-sided, how is an author supposed to be able to specify that he
&gt; wants one set of rules used when printing single-sided and a different
&gt; set of rules when printing double-sided?  The easiest solution seems
&gt; to be to specify two new media types for single-sided and double-sided
&gt; paged printing (and possibly a third for printing using a continuous
&gt; non-paged roll, altho that could be said to be outside the scope of
&gt; this module).
&gt;

A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.

   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'; www-style@w3.org
Subject: RE: [css3-page] LCWD issue 25 -- [25] Section 3.6

Your issue, shown below, has been rejected by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; With :left and :right always being used even when printing
&gt; single-sided, how is an author supposed to be able to specify that he
&gt; wants one set of rules used when printing single-sided and a different
&gt; set of rules when printing double-sided?  The easiest solution seems
&gt; to be to specify two new media types for single-sided and double-sided
&gt; paged printing (and possibly a third for printing using a continuous
&gt; non-paged roll, altho that could be said to be outside the scope of
&gt; this module).
&gt;

The placement of page boxes on page sheets is outside the scope of
this specification. There is no direct mechanism to determine how a UA
is placing the page boxes and, therefore, no selectors or pseudo
classes based on this information.

It could be possible that use of Media queries for duplex printing
could let a UA use a style sheet that an author provided for this
purpose. However, this, also, is outside the scope of this document.

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue26" name="issue26">1.26  [26] Section 4.2 maximum width of the top center cell
</a></h2><p><b>PROBLEM ID: 26</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted and updated spec.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [26] Section 4.2 maximum width of the top center cell
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Shouldn't this be the width of the "page area" instead of the "page
sheet"?  The wording indicates that the corners play no part in
determining the width of the top-center cell.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 26 --  [26] Section 4.2 maximum width of the top center cell
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 26.
&gt;
&gt; Shouldn't this be the width of the "page area" instead of the "page
&gt; sheet"?  The wording indicates that the corners play no part in
&gt; determining the width of the top-center cell.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 26 -- [26] Section 4.2 maximum width
of the top center cell

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; Shouldn't this be the width of the "page area" instead of the "page
&gt; sheet"?  The wording indicates that the corners play no part in
&gt; determining the width of the top-center cell.
&gt;


   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue27" name="issue27">1.27  [27] Section 7
</a></h2><p><b>PROBLEM ID: 27</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted and updated spec.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [27] Section 7
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

It would be helpful if one or more links to the 'float' property in
the CSS3 Box Module were included here.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 27 --  [27] Section 7
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 27.
&gt;
&gt; It would be helpful if one or more links to the 'float' property in
&gt; the CSS3 Box Module were included here.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 27 -- [27] Section 7

The editor has accepted your issue, shown below. If you have further
comments on the topic, you have seven days, until February 21, 2004,
to reply.

&gt;
&gt; It would be helpful if one or more links to the 'float' property in
&gt; the CSS3 Box Module were included here.
&gt;

http://www.w3.org/TR/css3-box/#the-float is now referenced.

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue28" name="issue28">1.28  [28] Section 7.4
</a></h2><p><b>PROBLEM ID: 28</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted and updated spec.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [28] Section 7.4
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Where is "@float-area" formally defined?

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 28 --  [28] Section 7.4
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 28.
&gt;
&gt; Where is "@float-area" formally defined?
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 28 -- [28] Section 7.4

You issue, shown below, has been accepted by the editor. If you have
further comment, you have seven days, until February 21, to reply.

&gt;
&gt; Where is "@float-area" formally defined?
&gt;

The specification now contains a definition of "@float-area".

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue29" name="issue29">1.29  [29] Section 8
</a></h2><p><b>PROBLEM ID: 29</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted and updated spec.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [29] Section 8
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

What is the motivation for defining rotation as &lt;integer&gt; instead of
as an &lt;angle&gt;?  If the intent is to simplify the task for the UA,
limiting the potential values to "0", "90", "180" and "270" would be
much more useful than limiting the values to integer degrees.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 29 --  [29] Section 8
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 29.
&gt;
&gt; What is the motivation for defining rotation as &lt;integer&gt; instead of
&gt; as an &lt;angle&gt;?  If the intent is to simplify the task for the UA,
&gt; limiting the potential values to "0", "90", "180" and "270" would be
&gt; much more useful than limiting the values to integer degrees.
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Wednesday, January 07, 2004 5:33 PM
To: www-style@w3.org; ernestcline@mindspring.com
Subject: RE: [css3-page] LCWD issue 29 -- [29] Section 8


Ernest,

I agree that &lt;angle&gt; in the range of 0 to 260 is preferable to
&lt;integer&gt;.  I look to profiles such as the CSS Print Profile for low
cost printers to simplify the range to 0, 90, 270.  Starting at the
full range and allowing capable printers to implement to their ability
seems like a good idea to me.

Jim

&gt; -----Original Message-----
&gt; From: James Bigelow [mailto:jhb@jhb.boi.hp.com]
&gt; Sent: Wednesday, January 07, 2004 4:44 PM
&gt; To: www-style@w3.org; ernestcline@mindspring.com
&gt; Subject: [css3-page] LCWD issue 29 -- [29] Section 8
&gt;
&gt;
&gt; Thank you for your comment on the CSS3 Paged Media Module,
&gt; archived in:
&gt; http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html
&gt;
&gt; Your issue, shown below, has been assigned the number 29.
&gt;
&gt; What is the motivation for defining rotation as &lt;integer&gt; instead of
&gt; as an &lt;angle&gt;?  If the intent is to simplify the task for the UA,
&gt; limiting the potential values to "0", "90", "180" and "270" would be
&gt; much more useful than limiting the values to integer degrees.
&gt;

A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.

   -- Jim Bigelow, Editor
</pre>
<p><b>

   FOLLOWUP 02:

   </b></p><pre>
From: Ernest Cline [ernestcline@mindspring.com]
Sent: Wednesday, January 07, 2004 8:23 PM
To: BIGELOW,JIM (HP-Boise,ex1); www-style@w3.org
Subject: RE: [css3-page] LCWD issue 29 -- [29] Section 8


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; To: &lt;www-style@w3.org&gt;; &lt;ernestcline@mindspring.com&gt;
&gt; Date: 1/7/2004 8:32:42 PM
&gt; Subject: RE: [css3-page] LCWD issue 29 --  [29] Section 8
&gt;
&gt; Ernest,
&gt;
&gt; I agree that &lt;angle&gt; in the range of 0 to 260 is preferable to
&gt; &lt;integer&gt;.
I
&gt; look to profiles such as the CSS Print Profile for low cost printers
&gt; to simplify the range to 0, 90, 270.  Starting at the full range and
&gt; allowing capable printers to implement to their ability seems like a
&gt; good idea to
me.

Just to be clear, I was referring to the &lt;angle&gt; value type from CSS3
Values [1] not some new definition of &lt;angle&gt; that would allow only
degrees.

[1] http://www.w3.org/TR/2001/WD-css3-values-20010713/#angles

</pre>
<p><b>

   FOLLOWUP 03:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1)
Sent: Thursday, January 08, 2004 2:48 PM
To: 'ernestcline@mindspring.com'; www-style@w3.org
Subject: RE: [css3-page] LCWD issue 29 -- [29] Section 8

Earnest wrote:
&gt; &gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; &gt; I agree that &lt;angle&gt; in the range of 0 to 360 is preferable to
&gt; &gt; &lt;integer&gt;.
&gt;
&gt; Just to be clear, I was referring to the &lt;angle&gt; value type from
&gt; CSS3 Values [1] not some new definition of &lt;angle&gt; that would
&gt; allow only degrees.
&gt;
&gt; [1] http://www.w3.org/TR/2001/WD-css3-values-20010713/#angles
&gt;

Thanks for the clarification.  I like the suggestion, support degrees,
radians, and grads makes sense to me.

Jim
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 29 -- [29] Section 8

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; What is the motivation for defining rotation as &lt;integer&gt; instead of
&gt; as an &lt;angle&gt;?  If the intent is to simplify the task for the UA,
&gt; limiting the potential values to "0", "90", "180" and "270" would be
&gt; much more useful than limiting the values to integer degrees.
&gt; ...
&gt; I was referring to the &lt;angle&gt; value type from
&gt; CSS3 Values [1] not some new definition of &lt;angle&gt; that would allow
&gt; only degrees.
&gt;
&gt; [1] http://www.w3.org/TR/2001/WD-css3-values-20010713/#angles


   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue30" name="issue30">1.30  [30] Section 8
</a></h2><p><b>PROBLEM ID: 30</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted and updated spec.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, December 19, 2003 4:24 PM
To: W3C CSS List
Subject: [30] Section 8
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

"Tow values" should be "Two values".


</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 30 --  [30] Section 8
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0130.html

Your issue, shown below, has been assigned the number 30.
&gt;
&gt; "Tow values" should be "Two values".
&gt;
&gt;
&gt;
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 30 -- [30] Section 8

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; "Tow values" should be "Two values".
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue31" name="issue31">1.31  RE: [css-page] New, last draft of CSS3 Paged Media Module
</a></h2><p><b>PROBLEM ID: 31</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Duplicate of #14.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline [ernestcline@mindspring.com]
Sent: Thursday, December 18, 2003 10:06 PM
To: W3C CSS List
Subject: RE: [css-page] New, last draft of CSS3 Paged Media Module
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0128.html


The terminology of this module strongly assumes the usual Western book
binding practice of binding a book so that when closed with the cover
facing the reader, the spine is to the left.  However, as I understand
it, the usual Japanese practice is to bind a book so that the spine is
to the right, when the cover faces the reader and thus the odd
numbered pages appear on the left and the even numbered pages appear
on the right.

Might it not be better to instead of speaking of left pages
and right pages to speak of odd pages and even pages?

Even if at this date work has progressed to the point that it is not
practical to replace :left and :right with :odd and :even, at the very
least, the explanatory text needs to be rewritten so that it is not so
strongly left spine oriented as it is now.


</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, ernestcline@mindspring.com
Subject: [css3-page] LCWD issue 31 --  RE: [css-page] New, last draft of CSS3 Paged Media Module
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0128.html

Your issue, shown below, has been assigned the number 31.
&gt;
&gt;
&gt; The terminology of this module strongly assumes the usual Western book
&gt; binding practice of binding a book so that when closed with the cover
&gt; facing the reader, the spine is to the left.  However, as I understand
&gt; it, the usual Japanese practice is to bind a book so that the spine is
&gt; to the right, when the cover faces the reader and thus the odd
&gt; numbered pages appear on the left and the even numbered pages appear
&gt; on the right.
&gt;
&gt; Might it not be better to instead of speaking of left pages
&gt; and right pages to speak of odd pages and even pages?
&gt;
&gt; Even if at this date work has progressed to the point that it is not
&gt; practical to replace :left and :right with :odd and :even, at the very
&gt; least, the explanatory text needs to be rewritten so that it is not so
&gt; strongly left spine oriented as it is now.
&gt;
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.


   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1)
Sent: Monday, February 09, 2004 8:26 PM
To: 'ernestcline@mindspring.com'
Subject: RE: [css3-page] LCWD issue 31 -- RE: [css-page] New, last draft
of CSS3 Paged Media Module

Your issue, shown below, has been resolved as a duplicate of issue 14
[1] by the editor.  If you have any further comment on this topic, you
have 7 days, until 17 February 2004, to respond.

&gt; The terminology of this module strongly assumes the usual Western book
&gt; binding practice of binding a book so that when closed with the cover
&gt; facing the reader, the spine is to the left.  However, as I understand
&gt; it, the usual Japanese practice is to bind a book so that the spine is
&gt; to the right, when the cover faces the reader and thus the odd
&gt; numbered pages appear on the left and the even numbered pages appear
&gt; on the right.
&gt;
&gt; Might it not be better to instead of speaking of left pages and right
&gt; pages to speak of odd pages and even pages?
&gt;
&gt; Even if at this date work has progressed to the point that it is not
&gt; practical to replace :left and :right with :odd and :even, at the very
&gt; least, the explanatory text needs to be rewritten so that it is not so
&gt; strongly left spine oriented as it is now.
&gt;
&gt;


   -- Jim Bigelow, Editor

[1] http://lists.w3.org/Archives/Public/www-style/2004Jan/0072.html
</pre>
<h2><a id="issue32" name="issue32">1.32  [CSS3-Page] 3.3.2 Page Size Error
</a></h2><p><b>PROBLEM ID: 32</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted and changed spec.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: Lachlan Hunt [lachlan.hunt@iinet.net.au]
Date: Fri, 19 Dec 2003 15:36:10 +1100
Message-ID: &lt;3FE2803A.8020502@iinet.net.au&gt;
To: www-style@w3.org
Subject: [CSS3-Page] 3.3.2 Page Size Error
Extracted from: http://lists.w3.org/Archives/Public/www-style/2003Dec/0127.html


Hi,

In section "3.3.2. Page size: the 'size' property" [1], there is a
typographical error the definition of "A4"

"The page box will be set to the size of A4 media: 210 cm wide and 297
cm high..."

Last time I checked, an A4 page was not that big!  It should use the
units mm instead of cm.

"The page box will be set to the size of A4 media: 210 mm wide and 297
mm high..."

[1] http://www.w3.org/TR/2003/WD-css3-page-20031218/#page-size-prop

CYA
...Lachy!

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: www-style@w3.org, lachlan.hunt@iinet.net.au
Subject: [css3-page] LCWD issue 32 --  [CSS3-Page] 3.3.2 Page Size Error
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Thank you for your comment on the CSS3 Paged Media Module, archived in:
 http://lists.w3.org/Archives/Public/www-style/2003Dec/0127.html

Your issue, shown below, has been assigned the number 32.
&gt;
&gt;
&gt; Hi,
&gt;
&gt; In section "3.3.2. Page size: the 'size' property" [1], there is a
&gt; typographical error the definition of "A4"
&gt;
&gt; "The page box will be set to the size of A4 media: 210 cm wide and 297
&gt; cm high..."
&gt;
&gt; Last time I checked, an A4 page was not that big!  It should use the
&gt; units mm instead of cm.
&gt;
&gt; "The page box will be set to the size of A4 media: 210 mm wide and 297
&gt; mm high..."
&gt;
&gt; [1] http://www.w3.org/TR/2003/WD-css3-page-20031218/#page-size-prop
&gt;
&gt; CYA
&gt; ...Lachy!
&gt;


A further response will be forthcoming. Please address any replys to
www-style@w3.org with [css3-page] in the subject line.

   -- Jim Bigelow, Editor
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: lachlan.hunt@iinet.net.au
Subject: RE: [css3-page] LCWD issue 32 -- [CSS3-Page] 3.3.2 Page Size
Error

Your issue, shown below, has been accepted by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt; In section "3.3.2. Page size: the 'size' property" [1], there is a
&gt; typographical error the definition of "A4"
&gt;
&gt; "The page box will be set to the size of A4 media: 210 cm wide and 297
&gt; cm high..."
&gt;
&gt; Last time I checked, an A4 page was not that big!  It should use the
&gt; units mm instead of cm.
&gt;
&gt; "The page box will be set to the size of A4 media: 210 mm wide and 297
&gt; mm high..."
&gt;
&gt; [1] http://www.w3.org/TR/2003/WD-css3-page-20031218/#page-size-prop
&gt;

   -- Jim Bigelow, Editor
</pre>
<h2><a id="issue33" name="issue33">1.33  [css3-page] Comment on page counters
</a></h2><p><b>PROBLEM ID: 33</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted and changed spec by extending the page-policy to apply to counter-reset.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Werner Donn�
[werner.donne@re.be]
Sent: Tuesday, January 13, 2004 7:50 AM
To: www-style@w3.org
Subject: [css3-page] Comment on page counters


Hi,

I think it would be interesting to specify that the counter "page" can
be reset. This is useful when named pages are used. The element for
which the page property applies could then also cause a page number
reset. An example:

@page front
{
   @bottom-center
   {
     content: counter(page, lower-roman)
   }
}

@page main
{
   @bottom-center
   {
     content: counter(page, decimal)
   }
}

div.front, div.main
{
   counter-reset: page;
}

div.front
{
   page: front;
}

div.main
{
   page: main;
}

Regards,

Werner.
--
Werner Donn�  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Tuesday, January 13, 2004 2:33 PM
To: werner.donne@re.be; www-style@w3.org
Subject: RE: [css3-page] Comment on page counters


Werner,

Thank you for you comment. It has been assigned issue number 33.

You wrote:
&gt; I think it would be interesting to specify that the counter
&gt; "page" can be reset.

The CSS working group agrees.  While it is not specifically mentioned
in this document, there is a property, counter-reset, in CSS Level 2,
Level 2.1 and Level 3, that does as you suggest.

Best regards,

Jim
</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: Werner Donn� [werner.donne@re.be]
Sent: Wednesday, January 14, 2004 2:44 AM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: www-style@w3.org
Subject: Re: [css3-page] Comment on page counters

Jim,

For me, the reason for being more explicit about the page counter is
that it is not an ordinary counter. The scoping, for example, is not
the same as for elements. Therefore, the counter-reset property
doesn't necessarily mean the same when applied to the page
counter. What would it mean on a &lt;p&gt;-element for example? Would it
affect the page onto which the formatted result of the &lt;p&gt;-element
goes or the next one? According to the normal scoping rules it
couldn't affect anything, because it doesn't contain any pages. For a
block-level element that carries the page property one could argue
that it "contains" the set of pages that are generated for it and
hence resetting the page counter on it would affect these pages. But
that is merely interpretation.

Regards,

Werner.

BIGELOW,JIM (HP-Boise,ex1) wrote:
&gt; Werner,
&gt;
&gt; Thank you for you comment. It has been assigned issue number 33.
&gt;
&gt; You wrote:
&gt;
&gt;&gt;I think it would be interesting to specify that the counter
&gt;&gt;"page" can be reset.
&gt;
&gt;
&gt; The CSS working group agrees.  While it is not specifically mentioned
&gt; in this document, there is a property, counter-reset, in CSS Level 2,
&gt; Level 2.1 and Level 3, that does as you suggest.
&gt;
&gt; Best regards,
&gt;
&gt; Jim
&gt;
&gt;

--
Werner Donn�  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
</pre>
<p><b>

   FOLLOWUP 02:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Michael Day
[mikeday@yeslogic.com]
Sent: Friday, January 16, 2004 2:53 PM
To: Werner Donn�
Cc: BIGELOW,JIM (HP-Boise,ex1); www-style@w3.org
Subject: Re: [css3-page] Comment on page counters


Hi Werner and Jim,

Prince 3.0 supports counter-reset for the page counter by applying it
to the page on which the beginning of the element falls. So if the
property is set on a &lt;div&gt; that spans several pages, the page on which
the element begins will have the page counter reset.

This approach to scoping seems to match the intentions of the user, who
will usually want to restart the page counter from the beginning of a book
or section, not at the end or on every page of a book or section.

Best regards,

Michael

--
YesLogic Prince prints XML!
http://yeslogic.com
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: Michael Day; Werner Donn�
Cc: www-style@w3.org
Subject: RE: [css3-page] Comment on page counters

The editor proposes that resolution for your issue, number 33,
discussed below is to extend the page-policy [1] property to apply not
only to page counters but to the resetting of the counter. Thus when
the page-policy is set to start to counter takes a value at the start
of the page and is also reset at the start of a page -- before the
counter.  Similar actions occur for first and last.

&gt;
&gt; Hi Werner and Jim,
&gt;
&gt; Prince 3.0 supports counter-reset for the page counter by
&gt; applying it to the page on which the beginning of the element
&gt; falls. So if the property is set on a &lt;div&gt; that spans
&gt; several pages, the page on which the element begins will have
&gt; the page counter reset.
&gt;
&gt; This approach to scoping seems to match the intentions of the
&gt; user, who
&gt; will usually want to restart the page counter from the
&gt; beginning of a book
&gt; or section, not at the end or on every page of a book or section.
&gt;

 -- Jim Bigelow, editor

[1] http://www.w3.org/TR/css3-page/#page-policy-sec</pre>
<h2><a id="issue34" name="issue34">1.34  [css3-page] Section 3.4.2. Cascading in the page context
</a></h2><p><b>PROBLEM ID: 34</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted and updated spec.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Werner Donn�
[werner.donne@re.be]
Sent: Tuesday, January 13, 2004 8:07 AM
To: www-style@w3.org
Subject: [css3-page] Section 3.4.2. Cascading in the page context


Hi,

Shouldn't there also be a cascading relationship between "anonymous"
at-page rules and named at-page rules, where the latter would be
stronger then the former?

Regards,

Werner.
--
Werner Donn�  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Tuesday, January 13, 2004 2:46 PM
To: werner.donne@re.be; www-style@w3.org
Subject: RE: [css3-page] Section 3.4.2. Cascading in the page context


Werner,

Thank you for your comment, it has been assign the number 34.

You wrote:
&gt; Shouldn't there also be a cascading relationship between
&gt; "anonymous" at-page rules and named at-page rules, where the
&gt; latter would be stronger then the former?

I think the concept of specificity [1] already supplies the
relationship you describe.

Jim

[1] Item 3 of http://www.w3.org/TR/CSS21/cascade.html#cascading-order
</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: Werner Donn� [werner.donne@re.be]
Sent: Wednesday, January 14, 2004 2:13 AM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: www-style@w3.org
Subject: Re: [css3-page] Section 3.4.2. Cascading in the page context

Jim,

The specificity calculation is expressed in terms of selectors, which
in turn are expressed in terms of elements. It could indeed also apply
to at-page rules. But shouldn't the specification then say somewhere
that an "anonymous" at-page rule corresponds to the universal element
selector and a named at-page rule to a type selector?

Regards,

Werner.

BIGELOW,JIM (HP-Boise,ex1) wrote:
&gt; Werner,
&gt;
&gt; Thank you for your comment, it has been assign the number 34.
&gt;
&gt; You wrote:
&gt;
&gt;&gt;Shouldn't there also be a cascading relationship between
&gt;&gt;"anonymous" at-page rules and named at-page rules, where the
&gt;&gt;latter would be stronger then the former?
&gt;
&gt;
&gt; I think the concept of specificity [1] already supplies the
&gt; relationship you describe.
&gt;
&gt; Jim
&gt;
&gt; [1] Item 3 of http://www.w3.org/TR/CSS21/cascade.html#cascading-order
&gt;
&gt;

--
Werner Donn�  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
</pre>
<p><b>

   FOLLOWUP 02:

   </b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Wednesday, January 14, 2004 10:08 AM
To: werner.donne@re.be
Cc: www-style@w3.org
Subject: RE: [css3-page] Section 3.4.2. Cascading in the page context


Werner, you wrote
&gt; The specificity calculation is expressed in terms of
&gt; selectors, which in turn are expressed in terms of elements.
&gt; It could indeed also apply to at-page rules. But shouldn't
&gt; the specification then say somewhere that an "anonymous"
&gt; at-page rule corresponds to the universal element selector
&gt; and a named at-page rule to a type selector?
&gt;

 Werner, you make a good point. I'm inclined to expand Section
 3.4.2. "Cascading in the page context" to indicate that the
 properties in the named page override those in a page. Does this seem
 reasonable to you?

- Jim

[1] http://www.w3.org/TR/css3-page/#cascading-and-page-context


&gt;
&gt; BIGELOW,JIM (HP-Boise,ex1) wrote:
&gt; &gt; Werner,
&gt; &gt;
&gt; &gt; Thank you for your comment, it has been assign the number 34.
&gt; &gt;
&gt; &gt; You wrote:
&gt; &gt;
&gt; &gt;&gt;Shouldn't there also be a cascading relationship between "anonymous"
&gt; &gt;&gt;at-page rules and named at-page rules, where the latter would be
&gt; &gt;&gt;stronger then the former?
&gt; &gt;
&gt; &gt;
&gt; &gt; I think the concept of specificity [1] already supplies the
&gt; &gt; relationship you describe.
&gt; &gt; [1] Item 3 of
&gt; http://www.w3.org/TR/CSS21/cascade.html#cas&gt; cading-order
&gt; &gt;
</pre>
<p><b>

   FOLLOWUP 03:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Werner Donn�
[werner.donne@re.be]
Sent: Thursday, January 15, 2004 9:39 AM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: www-style@w3.org
Subject: Re: [css3-page] Section 3.4.2. Cascading in the page context


Jim,

That is perfect. Thank you very much.

Regards,

Werner.

BIGELOW,JIM (HP-Boise,ex1) wrote:
&gt; Werner, you wrote
&gt;
&gt;&gt;The specificity calculation is expressed in terms of
&gt;&gt;selectors, which in turn are expressed in terms of elements.
&gt;&gt;It could indeed also apply to at-page rules. But shouldn't
&gt;&gt;the specification then say somewhere that an "anonymous"
&gt;&gt;at-page rule corresponds to the universal element selector
&gt;&gt;and a named at-page rule to a type selector?
&gt;&gt;
&gt;
&gt;  Werner, you make a good point. I'm inclined to expand Section 3.4.2.
&gt; "Cascading in the page context" to indicate that the properties in the
&gt; named page override those in a page. Does this seem reasonable to you?
&gt;
&gt; - Jim
&gt;
&gt; [1] http://www.w3.org/TR/css3-page/#cascading-and-page-context
&gt;
&gt;
&gt;
&gt;
&gt;&gt;BIGELOW,JIM (HP-Boise,ex1) wrote:
&gt;&gt;
&gt;&gt;&gt;Werner,
&gt;&gt;&gt;
&gt;&gt;&gt;Thank you for your comment, it has been assign the number 34.
&gt;&gt;&gt;
&gt;&gt;&gt;You wrote:
&gt;&gt;&gt;
&gt;&gt;&gt;
&gt;&gt;&gt;&gt;Shouldn't there also be a cascading relationship between "anonymous"
&gt;&gt;&gt;&gt;at-page rules and named at-page rules, where the latter would be
&gt;&gt;&gt;&gt;stronger then the former?
&gt;&gt;&gt;
&gt;&gt;&gt;
&gt;&gt;&gt;I think the concept of specificity [1] already supplies the
&gt;&gt;&gt;relationship you describe.
&gt;&gt;&gt;[1] Item 3 of
&gt;&gt;
&gt;&gt;http://www.w3.org/TR/CSS21/cascade.html#cas&gt; cading-order
&gt;&gt;
&gt;
&gt;

--
Werner Donn�  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: werner.donne@re.be; www-style@w3.org
Subject: RE: [css3-page] Section 3.4.2. Cascading in the page context

Werner,

You issue (number 34) shown below has been accepted by the editor and
resolved as discussed in this email thread.

&gt; Shouldn't there also be a cascading relationship between
&gt; "anonymous" at-page rules and named at-page rules, where the
&gt; latter would be stronger then the former?
&gt;
 -- Jim Bigelow, editor</pre>
<h2><a id="issue35" name="issue35">1.35  [css3-page] Applicable properties in margin boxes
</a></h2><p><b>PROBLEM ID: 35</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Not an issue, behavior already part of CSS
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Werner Donn�
[werner.donne@re.be]
Sent: Tuesday, January 13, 2004 8:34 AM
To: www-style@w3.org
Subject: [css3-page] Applicable properties in margin boxes


Hi,

All properties that apply to inline elements should also apply to
margin boxes. Otherwise the style of these areas can only be
controlled through the UA, which is less portable.

Regards,

Werner.
--
Werner Donn�  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Tuesday, January 13, 2004 2:47 PM
To: werner.donne@re.be; www-style@w3.org
Subject: RE: [css3-page] Applicable properties in margin boxes


Werner,

Thank you for your comment, it has been assigned as issue number 35

Your wrote:
&gt;
&gt; All properties that apply to inline elements should also
&gt; apply to margin boxes. Otherwise the style of these areas can
&gt; only be controlled through the UA, which is less portable.
&gt;


Jim
</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Werner Donn�
[werner.donne@re.be]
Sent: Tuesday, January 13, 2004 8:51 AM
To: www-style@w3.org
Subject: Re: [css3-page] Applicable properties in margin boxes


On second thought this might already be the case if generated content
in margin boxes is the same as generated content elsewhere.

Regards,

Werner.
--
Werner Donn�  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: werner.donne@re.be
Subject: RE: [css3-page] Applicable properties in margin boxes

Werner,

You issue (number 35) as been resolved to not be an issue as the
behavior requested is already in CSS. If you have any further comment
on this topic, you have 7 days, until 16 February 2004, to respond.

&gt;
&gt; All properties that apply to inline elements should also
&gt; apply to margin boxes. Otherwise the style of these areas can
&gt; only be controlled through the UA, which is less portable.
&gt;
Jim Bigelow, editor</pre>
<h2><a id="issue36" name="issue36">1.36  [css3-page] examples in 3.3.2 (page size) are 'US-centric'(?)
</a></h2><p><b>PROBLEM ID: 36</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted and corrected units, added set of media names, and referenced PWG media names spec.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Jungshik Shin
[jshin@i18nl10n.com]
Sent: Sunday, January 18, 2004 4:35 AM
To: www-style@w3.org
Subject: [css3-page] examples in 3.3.2 (page size) are 'US-centric'(?)


Hello,

There are two examples (excluding the first example for 'auto') given
in section 3.3.2 and both of them refer to US letter. I think at least
one of them had better use ISO A4, instead given that virtually all
other countries use ISO A4. Besides, as already pointed out twice, A4
is only 21.0 cm wide and 29.7 cm high instead of 210cm and 297cm. It
might be a good idea to use 21.0 cm and 29.7 cm instead of 210 mm and
297 mm beceause numbers (21.0 and 29.7) are more comparable to 8.5 and
11 for US letter than 210 and 297.

Thanks for your consideration,

Jungshik
</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Monday, January 19, 2004 8:52 AM
To: Jungshik Shin; www-style@w3.org
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


Jungshik,

Thank you for your comment. It has been assigned issue number 36.

You wrote:
&gt;
&gt; There are two examples (excluding the first example for
&gt; 'auto') given in section 3.3.2 and both of them refer to US
&gt; letter. I think at least one of them had better use ISO A4,
&gt; instead given that virtually all other countries use ISO A4.
&gt; Besides, as already pointed out twice, A4 is only 21.0 cm
&gt; wide and 29.7 cm high instead of 210cm and 297cm. It might be
&gt; a good idea to use 21.0 cm and 29.7 cm instead of 210 mm and
&gt; 297 mm beceause numbers (21.0 and 29.7) are more comparable
&gt; to 8.5 and 11 for US letter than 210 and 297.
&gt;

 -- Jim Bigelow, editor
</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Sunday, January 18, 2004 7:39 AM
To: Jungshik Shin; www-style@w3.org
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt; [Original Message]
&gt; From: Jungshik Shin &lt;jshin@i18nl10n.com&gt;
&gt;
&gt; There are two examples (excluding the first example for 'auto') given
&gt; in section 3.3.2 and both of them refer to US letter. I think at least
&gt; one of them had better use ISO A4, instead given that virtually all
&gt; other countries use ISO A4. Besides, as already pointed out twice, A4
&gt; is only 21.0 cm wide and 29.7 cm high instead of 210cm and 297cm. It
&gt; might be a good idea to use 21.0 cm and 29.7 cm instead of 210 mm and
&gt; 297 mm because numbers (21.0 and 29.7) are more comparable to 8.5 and
&gt; 11 for US letter than 210 and 297.

I always applaud a call for more diversity in the examples, so I shall
second your call for an example using A4 paper.  However I must
strongly oppose your suggestion to use cm instead of mm.

There already exists a non-W3C international standard [1] for
specifying paper sizes, and the only units it uses are in and mm. I
would hope that this module would hew more closely to it and possibly
even include it by reference as other W3C standards do for specifying
languages and MIME types.  However, since that standard does not use
cm, I would prefer that even if W3C decides to roll its own that it
restrict its examples to using just in and mm.

[1] ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf

</pre>
<p><b>

   FOLLOWUP 02:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1)
Sent: Monday, January 19, 2004 10:24 AM
To: 'ernestcline@mindspring.com'; Jungshik Shin; www-style@w3.org
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)

Ernest wrote:
&gt; &gt; [Original Message]
&gt; &gt; From: Jungshik Shin &lt;jshin@i18nl10n.com&gt;
&gt; &gt;
&gt; &gt; There are two examples (excluding the first example for
&gt; &gt; 'auto') given in section 3.3.2 and both of them refer to
&gt; &gt; US letter. I think at least one of them had better use ISO A4,
&gt; &gt; instead given that virtually all other countries use ISO A4.
&gt; &gt; Besides, as already pointed out twice, A4
&gt; &gt; is only 21.0 cm wide and 29.7 cm high instead of 210cm and
&gt; &gt; 297cm. It might be a good idea to use 21.0 cm and 29.7 cm instead of
&gt; &gt; 210 mm and 297 mm because numbers (21.0 and 29.7) are more comparable
&gt; &gt; to 8.5 and 11 for US letter than 210 and 297.
&gt;
&gt; I always applaud a call for more diversity in the examples,
&gt; so I shall second your call for an example using A4 paper.
&gt; However I must strongly oppose your suggestion to use cm
&gt; instead of mm.
&gt;
&gt; There already exists a non-W3C international standard [1] for
&gt; specifying paper sizes, and the only units it uses are in and
&gt; mm. I would hope that this module would hew more closely to
&gt; it and possibly even include it by reference as other W3C
&gt; standards do for specifying languages and MIME types.
&gt; However, since that standard does not use cm, I would prefer
&gt; that even if W3C decides to roll its own that it restrict its
&gt; examples to using just in and mm.
&gt;
&gt; [1] ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf

I agree both commenters. When I update the spec later this month
or next, I will have examples using A4, the sizes will be correct
(when used) and in mm, in keeping with Ernest's comments.  I also,
will reference the PWG spec [1] on paper sizes and names.

However, I'm not so sure about requiring support for all the paper
names set forth in [1].  I still think that A4 and Letter will cover
most of the uses.  Of course, I can be convinced, otherwise, by
persuasive reasoning.  My purpose is user/document author convenience
and my feeling is that names are more accurate and readable than
sizes.  I don't think it is feasible to revise the spec, even
periodically, just to add new media names -- that's the argument for
use of sizes.

Is there a compromise that satisfies most of the people most of the time?

 - Jim Bigelow, editor
</pre>
<p><b>

   FOLLOWUP 03:

   </b></p><pre>
From: Ernest Cline [ernestcline@mindspring.com]
Sent: Monday, January 19, 2004 1:30 PM
To: BIGELOW,JIM (HP-Boise,ex1); www-style@w3.org
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt;
&gt; I agree you both commenters. When I update the spec later this month
&gt; or next, I will have examples using A4, the sizes will be correct
&gt; (when used) and in mm, in keeping with Ernest's comments.  I also,
&gt; will reference the PWG spec [1] on paper sizes and names.
&gt;
&gt; However, I'm not so sure about requiring support for all the paper
&gt; names set
&gt; forth in [1].  I still think that A4 and Letter will cover most of the
&gt; uses. Of course, I can be convinced, otherwise, by persuasive reasoning.
&gt; My purpose is user/document author convenience and my feeling is that
&gt; names are
&gt; more accurate and readable than sizes.  I don't think it is feasible
&gt; to revise the spec, even periodically, just to add new media names --
&gt; that's the argument for use of sizes.
&gt;
&gt; Is there a compromise that satisfies most of the people most of the
&gt; time?

I don't get your point.  W3C specs such as XHTML aren't revised
whenever another language is added to ISO 639 or another MIME type is
registered with the IETF.  Rather they just reference the standard and
mention where one can get the latest list of registered values. Why
then should CSS3 Page need to be revised when the IEEE PWG accepts a
new standard paper size?

Presumably, just as with languages and MIME types, a UA will
understand the ones that it can actually use and merely recognize as
valid the ones the it can't.  If it can handle printing to custom
paper sizes then it should be able to parse the full forms such as
"na_letter_8.5x11in" or "custom_pre-shredded_1x297mm" and get the size
information from the name.

As a side benefit, supporting the PWG self describing media sizes
would also mean that there would be no need to include &lt;length&gt; values
in the list of allowed values for 'size' as it would be able to get
them from page size values that use the full form. Since this would
enable the elimination of special casing what is allowed for &lt;length&gt;
I am in favor of this.  I am strongly against having to special case
general purpose values such as &lt;length&gt;, but I can see why it would
not be a good idea to allow page sizes to be described in terms of
units such as em and ex that are variable in size.

In any event, even if it is decided to not support IEEE-ISTO 5101.1 at
this time, I would strongly prefer that the keywords that CSS3 Page
uses follow the &lt;classname&gt; "_" &lt;sizename&gt; format (i.e., "na_letter"
not "letter" and "iso_a4" not "A4") so that it would be possible to
add support for all 5101.1 paper sizes in a later version such as CSS4
Page without having to also support keywords that do not conform to
that format in the name of backward compatibility.

 I am aware that "letter" and "a4" do conform to an even more
 permissive format allowed by the standard which allows for the use of
 just the &lt;sizename&gt;. However, as I have said earlier, [1] there is
 potential confusion between the ISO B-series sizes and the JIS
 B-series sizes which despite not being the same sizes, share common
 &lt;sizename&gt;s.  Thus they require the &lt;classname&gt; to know which is
 meant in a context where either could occur. Hence, using just the
 &lt;sizename&gt; portion of the full self describing name should not be
 done in an international standard such as CSS.

Since, as I understand it, the WG is also working with other standards
bodies on this module. (including hopefully the IEEE PWG) Perhaps you
should get some input from them before coming to a final decision on
this particular issue.

Just so that my position on this issue is clear, let me finish up by
stating it concisely.  I feel that for the 'size' property, a UA that
conforms to CSS 3 Page should be able to parse any media size
self-describing name as specified by Section 5 of IEEE-ISTO
5101.1-2002 or subsequent revisions. (This enables the UA to get the
page size from the dimensions included in such names, and eliminates
the need to include &lt;length&gt;{1,2} in the allowed values of 'size'.)  A
conforming UA could also recognize names of the form &lt;class-name&gt; "_"
&lt;size-name&gt; as allowed by Section 6 of that standard. (This would
permit use of the shorter names that Jim favors.) It might be
worthwhile to require that a conforming UA be able to recognize a few
common sizes such as "na_letter" or "iso_a4" when the UA is able to
print to those sizes so as to ensure that they can be used
interoperably,

[1] http://lists.w3.org/Archives/Public/www-style/2004Jan/0067.html

</pre>
<p><b>

   FOLLOWUP 04:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Bjoern Hoehrmann
[derhoermi@gmx.net]
Sent: Monday, January 19, 2004 2:27 PM
To: ernestcline@mindspring.com
Cc: www-style@w3.org
Subject: Re: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


* Ernest Cline wrote:
&gt;I don't get your point.  W3C specs such as XHTML aren't revised
&gt;whenever another language is added to ISO 639 or another MIME type is
&gt;registered with the IETF.  Rather they just reference the standard and
&gt;mention where one can get the latest list of registered values. Why
&gt;then should CSS3 Page need to be revised when the IEEE PWG accepts a
&gt;new standard paper size?

A CSS user agent would be expected to support new keywords out of the
box while a Voice Browser would not be expected to support speech
synthesis for a new language or a browser a new image format just
because of new registered language tags or MIME types. If the page
dimensions can be inferred from the keyword that would not be a
problem, but then I don't get the point of using

  size: na_letter_8.5x11in;

(a keyword I would probably have to look up first) instead of

  size: 8.5in 11in;

As an author, what's my benefit if this is added to css3-page?
</pre>
<p><b>

   FOLLOWUP 05:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Monday, January 19, 2004 9:43 PM
To: Bjoern Hoehrmann
Cc: www-style@w3.org
Subject: Re: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt; [Original Message]
&gt; From: Bjoern Hoehrmann &lt;derhoermi@gmx.net&gt;
&gt; To: &lt;ernestcline@mindspring.com&gt;
&gt; Cc: &lt;www-style@w3.org&gt;
&gt; Date: 1/19/2004 5:27:11 PM
&gt; Subject: Re: [css3-page] examples in 3.3.2 (page size) are
&gt; 'US-centric'(?)
&gt;
&gt; * Ernest Cline wrote:
&gt; &gt;I don't get your point.  W3C specs such as XHTML aren't revised
&gt; &gt;whenever another language is added to ISO 639 or another MIME type is
&gt; &gt;registered with
&gt; &gt;the IETF.  Rather they just reference the standard and mention where
&gt; &gt;one can get the latest list of registered values. Why then should
&gt; &gt;CSS3 Page need
&gt; &gt;to be revised when the IEEE PWG accepts a new standard paper size?
&gt;
&gt; A CSS user agent would be expected to support new keywords out of the
&gt; box while a Voice Browser would not be expected to support speech
&gt; synthesis for a new language or a browser a new image format just
&gt; because of new registered language tags or MIME types. If the page
&gt; dimensions can be inferred from the keyword that would not be a
&gt; problem, but then I don't get the point of using
&gt;
&gt;   size: na_letter_8.5x11in;
&gt;
&gt; (a keyword I would probably have to look up first) instead of
&gt;
&gt;   size: 8.5in 11in;
&gt;
&gt; As an author, what's my benefit if this is added to css3-page?

Well first off, you should be able to use just

size: na_letter ;

or if you can't remember the short name, then altho not strictly
kosher, a UA should be able to understand either:

size: custom_xyzzy_8.5x11in;

or:

size: us_letter_8.5x11in;

as referring to 8.5" x 11" paper.

The main one advantage this gives an author is that it uses a standard
way of referring to page sizes so that if you are also dealing with
other types of documents than CSS stylesheets, then if they also
follow that standard, you would only have to refer to one standard.

I will admit that given the sheer number of keywords (165 different
standard paper sizes in that standard if I counted correctly) it would
be unwieldy to require that all 165 short names (without the
dimensions) be supported by all UA's.  However, since there are only a
few common paper sizes, it should be practical to require a basic set
of keywords (or even restrict the list of allowed short keywords to
just those keywords.)

What follows is what I feel to be a likely maximum minimum:

na_invoice (5.5" x 8.5")
na_letter (8.5" x 11")
na_legal (8.5" x 14")
na_ledger (11" x 17")

iso_a5 (148mm x 210mm)
iso_b5 (176mm x 250mm)
iso_a4 (210mm x 297mm)
iso_b4 (250mm x 353mm)
iso_a3 (297mm x 420 mm)

For general printing, we probably don't need to have CSS support
keywords for envelope sizes, and I don't know how commonly the non-ISO
paper sizes used by China, Taiwan, or Japan that are referenced by the
IEEE standard are used with computers. As it is, with these nine I
probably have overkill for general use, as "na_letter" and "iso_a4"
are certainly the two most used sizes of computer paper.  "na_invoice"
and "iso_a5" are most likely to be used when a user has chosen to
print a document in a 2-up format.

In any event, as I have said, if the decision is made to only support
a few keywords instead of the full IEEE PWG standard for paper sizes,
I strongly want the keywords chosen to conform with the &lt;class-name&gt;
"_" &lt;size-name&gt; format so that if it should be decided in a future
version of the Paged Media Module to support this standard there would
not be any legacy keywords that don't follow that form that would have
to be supported as well.

</pre>
<p><b>

   FOLLOWUP 06:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Christoph P�per
[christoph.paeper@tu-clausthal.de]
Sent: Tuesday, January 20, 2004 12:42 AM
To: www-style@w3.org
Subject: Re: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


*Ernest Cline*:
&gt;&gt; From: Bjoern Hoehrmann &lt;derhoermi@gmx.net&gt;
&gt;&gt;
&gt;&gt; If the page dimensions can be inferred from the keyword that would
&gt;&gt; not be a problem, but then I don't get the point of using
&gt;&gt;
&gt;&gt;   size: na_letter_8.5x11in;
&gt;&gt;
&gt;&gt; (a keyword I would probably have to look up first) instead of
&gt;&gt;
&gt;&gt;   size: 8.5in 11in;

Exactly. Some people probably know the exact dimensions of A4, but
none of the other ISO sizes. I don't know about users of Letter etc. A
few years ago I myself hadn't even realized that virtually the whole
world uses our DIN sizes. Today I'm worried about that "virtually".

&gt;&gt; As an author, what's my benefit if this is added to css3-page?
&gt;
&gt; Well first off, you should be able to use just
&gt;
&gt; size: na_letter ;

I don't know one person IRL who'd knew what that meant. At best (or
worst) they'd wonder what "not available letter" has to do with a
property named 'size', not even knowing whether 'letter' means a piece
of mail or a character from some alphabet.

&gt; size: us_letter_8.5x11in;
&gt;
&gt; as referring to 8.5" x 11" paper.

The Media Size Self-Describing Name Format as described by IEEE-ISTO
5101.1-2002 is in my view clearly inferior to the alternate CSS way,
which would consist of two rules, the first with the explicit
dimensions written like CSS parsers would expect, the second one being
literal:

  size: 8.5in 11in;
  size: us-letter;

Of course this is overly informative.  CSS also doesn't require to
misuse the letter x as an multiplication sign (we have � and � for
that) and it has every number directly assigned to a dimension,
allowing to mix such (in theory).

&gt; The main one advantage this gives an author is that it uses  a
&gt; standard way of referring to page sizes so that if you are also
&gt; dealing with other types of documents than CSS stylesheets, then if
&gt; they also follow that standard, you would only have to refer to one
&gt; standard.

That's a benefit to just very few people, especially given the
machine-centered aim of that IEEE spec. It's not worth it.

&gt; I will admit that given the sheer number of keywords (165 different
&gt; standard paper sizes in that standard if I counted correctly) it would
&gt; be unwieldy to require that all 165 short names (without the
&gt; dimensions) be supported by all UA's.

I agree, although the sizes of the basic ISO series can be calculated
by an algorithm without a lookup table. JIS B too.

&gt; What follows is what I feel to be a likely maximum minimum:
&gt;
&gt; na_invoice (5.5" x 8.5")

I've never heard of that one, but then I'm not from the USA nor
Canada. From the sizes it looks like P5 from CAN 2-9.60M (140mm �
215mm).

&gt; na_letter (8.5" x 11")
&gt; na_legal (8.5" x 14")
&gt; na_ledger (11" x 17")
&gt;
&gt; iso_a5 (148mm x 210mm)
&gt; iso_b5 (176mm x 250mm)
&gt; iso_a4 (210mm x 297mm)
&gt; iso_b4 (250mm x 353mm)
&gt; iso_a3 (297mm x 420 mm)

With these only, there's absolutely no need for the prefix. There's
not much use for it with the full set either, except that JIS B has to
be distinguished from ISO B.

&gt; As it is, with these nine I probably have overkill for general use,

I've already printed to all A sizes from 2 to 6 and some of the B and
C sizes in that range, but anyhow never a webpage.

&gt; In any event, as I have said, if the decision is made to only support
&gt; a few keywords instead of the full IEEE PWG standard for  paper sizes,
&gt; I strongly want the keywords chosen to conform with the &lt;class-name&gt;
&gt; "_" &lt;size-name&gt; format so that if it should be decided in a future
&gt; version of the Paged Media Module to support this standard
&gt; there would not be any legacy keywords that don't follow
&gt; that form that would have to be supported as well.

Although being uncertain about named paper sizes in general, I
strongly oppose the underscore and general lowercase like you and the
IEEE-PWG suggest. All current CSS properties and values use the
hyphen-minus instead[1] and are case-insensitive (I certainly prefer
'A4').

A differing habit from an external standard should not be adopted
unchanged, IMO. Furthermore the pwg5101.1.pdf, referenced earlier in
this thread, says in chapter 6 "Conformance Requirements":

| Other referencing standards may impose case sensitive rules if
| necessary.

and

| It is also acceptable to replace the underscore separator between the
| "class" and "size-name" with a hyphen.

[1] A while ago I even requested to treat literal properties and
values the same with removed hyphens, i.e. 'pre-wrap' == 'prewrap' ==
'p-r-e-w-r-a-p'.
</pre>
<p><b>

   FOLLOWUP 07:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Tuesday, January 20, 2004 11:36 AM
To: Christoph P�per; www-style@w3.org
Subject: Re: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt; [Original Message]
&gt; From: Christoph P�per &lt;christoph.paeper@tu-clausthal.de&gt;
&gt;
&gt;
&gt; *Ernest Cline*:
&gt; &gt;&gt; From: Bjoern Hoehrmann &lt;derhoermi@gmx.net&gt;
&gt; &gt;&gt;
&gt; &gt;&gt; If the page dimensions can be inferred from the keyword that would
&gt; &gt;&gt; not be a problem, but then I don't get the point of using
&gt; &gt;&gt;
&gt; &gt;&gt;   size: na_letter_8.5x11in;
&gt; &gt;&gt;
&gt; &gt;&gt; (a keyword I would probably have to look up first) instead of
&gt; &gt;&gt;
&gt; &gt;&gt;   size: 8.5in 11in;
&gt;
&gt; Exactly. Some people probably know the exact dimensions of A4, but
&gt; none of the
&gt; other ISO sizes. I don't know about users of Letter etc. A few years
&gt; ago I myself hadn't even realized that virtually the whole world uses
&gt; our DIN sizes.
&gt; Today I'm worried about that "virtually".
&gt;
&gt; &gt;&gt; As an author, what's my benefit if this is added to css3-page?
&gt; &gt;
&gt; &gt; Well first off, you should be able to use just
&gt; &gt;
&gt; &gt; size: na_letter ;
&gt;
&gt; I don't know one person IRL who'd knew what that meant. At best (or
&gt; worst) they'd wonder what "not available letter" has to do with a
&gt; property named 'size', not even knowing whether 'letter' means a piece
&gt; of mail or a character
&gt; from some alphabet.

That's in part beacuse you come from a sensible part of the world that
uses the ISO sizes.  Over here in North America, most people would
have no problem understanding what was meant by letter size paper
(altho they might not know from memory the dimensions) They'd likely
have to be told the first time that "na" stood for North America. It's
no worse that having to tell people that

vertical-align:center;

isn't valid.  Anyone who will be using this will be likely be
referring to some form of documentation.  (Not necessarily the
official standard, it could be The Idiot's Guide to CSS 3, for all
I care.)  The people who try to use this without using any sort of
documentation, are also going to be the same people who will try to
use any of:

size: legal;
size: dl;
size: envelope;

etc.

You can't make CSS idiot proof.

&gt; &gt; size: us_letter_8.5x11in;
&gt; &gt;
&gt; &gt; as referring to 8.5" x 11" paper.
&gt;
&gt; The Media Size Self-Describing Name Format as described by IEEE-ISTO
&gt; 5101.1-2002 is in my view clearly inferior to the alternate CSS way,
&gt; which would consist of two rules, the first with the explicit
&gt; dimensions written like CSS parsers would expect, the second one being
&gt; literal:
&gt;
&gt;   size: 8.5in 11in;
&gt;   size: us-letter;
&gt;
&gt; Of course this is overly informative.
&gt; CSS also doesn't require to misuse the letter x as an multiplication
&gt; sign (we
&gt; have � and � for that) and it has every number directly assigned to a
&gt; dimension, allowing to mix such (in theory).

Well, I can't see any benefit in mixing units for paper sizes since
either they'll both be mm or both be in.

As for x being misused, I presume that IEEE had as one of its design
goals that the keywords would all fit in the ISO 646 invariant set (or
at least within the ISO 646 IRV aka ASCII)

&gt; &gt; The main one advantage this gives an author is that it uses  a
&gt; &gt; standard way of referring to page sizes so that if you are also
&gt; &gt; dealing with other
&gt; &gt; types of documents than CSS stylesheets, then if they also follow
&gt; &gt; that standard, you would only have to refer to one standard.
&gt;
&gt; That's a benefit to just very few people, especially given the
&gt; machine-centered aim of that IEEE spec. It's not worth it.
&gt;
&gt; &gt; I will admit that given the sheer number of keywords (165 different
&gt; &gt; standard paper sizes in that standard if I counted correctly) it
&gt; &gt; would be unwieldy to require that all 165 short names (without the
&gt; &gt; dimensions) be supported by all UA's.
&gt;
&gt; I agree, although the sizes of the basic ISO series can be calculated
&gt; by an
&gt; algorithm without a lookup table. JIS B too.
&gt;
&gt; &gt; What follows is what I feel to be a likely maximum minimum:
&gt; &gt;
&gt; &gt; na_invoice (5.5" x 8.5")
&gt;
&gt; I've never heard of that one, but then I'm not from the USA nor
&gt; Canada. From
&gt; the sizes it looks like P5 from CAN 2-9.60M (140mm � 215mm).

Yup, half of na_letter aka Canadian P4 (215mm x 280mm).

Not really available, but it is the logical size for doing 2-up
printing on "na-letter" and unlike you Europeans who have it easy with
those ISO paper sizes that all have the same aspect ratio, if you want
to support 2-up (or 8-up printing) you can't just scale the document
and rotate over here in North America.  Still, I wouldn't mind not
having that keyword, as 2-up printing probably won't be that common
either.

The three sizes that are commonly available are letter, legal, and
ledger. You can get A4 over here on this side of the Atlantic without
too much difficulty, altho it typically is slightly more expensive
than letter sized paper, even taking into account the fact that A4 is
slightly larger as well. Other ISO sizes require more work to acquire,
but it can be done.

&gt; &gt; na_letter (8.5" x 11")
&gt; &gt; na_legal (8.5" x 14")
&gt; &gt; na_ledger (11" x 17")
&gt; &gt;
&gt; &gt; iso_a5 (148mm x 210mm)
&gt; &gt; iso_b5 (176mm x 250mm)
&gt; &gt; iso_a4 (210mm x 297mm)
&gt; &gt; iso_b4 (250mm x 353mm)
&gt; &gt; iso_a3 (297mm x 420 mm)
&gt;
&gt; With these only, there's absolutely no need for the prefix. There's
&gt; not much
&gt; use for it with the full set either, except that JIS B has to be
&gt; distinguished from ISO B.

Only if you assume that the list will never be expanded to include
other page sizes that share the same &lt;sizename&gt; part. I am not in
favor of making that assumption.

There are also two different c5's and two different f's in the
IEEE-PWG standard.

&gt; &gt; As it is, with these nine I probably have overkill for general use,
&gt;
&gt; I've already printed to all A sizes from 2 to 6 and some of the B and
&gt; C sizes
&gt; in that range, but anyhow never a webpage.
&gt;
&gt; &gt; In any event, as I have said, if the decision is made to only
&gt; &gt; support a few keywords instead of the full IEEE PWG standard for
&gt; &gt; paper sizes, I strongly want the keywords chosen to conform with the
&gt; &gt; &lt;class-name&gt; "_" &lt;size-name&gt; format so that if it should be decided
&gt; &gt; in a future version of the Paged Media Module to support this
&gt; &gt; standard there would not be any legacy keywords that don't follow
&gt; &gt; that form that would have to be supported as well.
&gt;
&gt; Although being uncertain about named paper sizes in general, I
&gt; strongly oppose
&gt; the underscore and general lowercase like you and the IEEE-PWG
&gt; suggest. All
&gt; current CSS properties and values use the hyphen-minus instead[1] and
&gt; are case-insensitive (I certainly prefer 'A4').
&gt;
&gt; A differing habit from an external standard should not be adopted
&gt; unchanged, IMO. Furthermore the pwg5101.1.pdf, referenced earlier
&gt; in this thread, says in chapter 6 "Conformance Requirements":
&gt;
&gt; | Other referencing standards may impose case sensitive rules if
&gt; necessary.

Well, as far as case sensitivity is concerned, the IEEE standard is
case insensitive, just like CSS keywords so both standards treat
"iso_a4" "ISO_A4", and "iso_A4" as all being identical.  All that
clause does is give standards that are case sensitive the freedom to
pick a case as might be the case if we were discussing an XSL version
of the Paged Media Module.

&gt; and
&gt;
&gt; | It is also acceptable to replace the underscore separator between
&gt; | the "class" and "size-name" with a hyphen.

True, and I wouldn't raise a fuss if the underscore were replaced by
the hyphen-minus.  I also wouldn't mind the underscore remaining
either.

&gt; [1] A while ago I even requested to treat literal properties and
&gt; values the
&gt; same with removed hyphens, i.e. 'pre-wrap' == 'prewrap' ==
'p-r-e-w-r-a-p'.

While that might work for all existing CSS keywords, it certainly
wouldn't work for the IEEE keywords (if underscore were replaced by
hyphen-minus) because of the significance of the separating character
between the end of a &lt;size-name&gt; that ends in a digit and the
dimension part of a self- describing media name.


</pre>
<p><b>

   FOLLOWUP 08:

   </b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Thursday, January 22, 2004 1:49 PM
To: www-style@w3.org
Cc: Michael Day
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


Hello,

Ernest wrote:
&gt; Sent: Monday, January 19, 2004 9:43 PM
&gt; What follows is what I feel to be a likely maximum minimum:
&gt;
&gt; na_invoice (5.5" x 8.5")
&gt; na_letter (8.5" x 11")
&gt; na_legal (8.5" x 14")
&gt; na_ledger (11" x 17")
&gt;
&gt; iso_a5 (148mm x 210mm)
&gt; iso_b5 (176mm x 250mm)
&gt; iso_a4 (210mm x 297mm)
&gt; iso_b4 (250mm x 353mm)
&gt; iso_a3 (297mm x 420 mm)
&gt;

What if we use a '-' for '_'?
 na-invoice
 na-letter
 na-legal
 na-ledger

 iso-a5
 iso-b5
 iso-a4
 iso-b4
 iso-a3

Is this an acceptable subset of all possible media names?

Jim Bigelow, Editor
</pre>
<p><b>

   FOLLOWUP 09:

   </b></p><pre>
From: Ernest Cline [ernestcline@mindspring.com]
Sent: Thursday, January 22, 2004 2:30 PM
To: BIGELOW,JIM (HP-Boise,ex1); www-style@w3.org
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt;
&gt; Ernest wrote:
&gt; &gt; Sent: Monday, January 19, 2004 9:43 PM
&gt; &gt; What follows is what I feel to be a likely maximum minimum:
&gt; &gt;
&gt; &gt; na_invoice (5.5" x 8.5")
&gt; &gt; na_letter (8.5" x 11")
&gt; &gt; na_legal (8.5" x 14")
&gt; &gt; na_ledger (11" x 17")
&gt; &gt;
&gt; &gt; iso_a5 (148mm x 210mm)
&gt; &gt; iso_b5 (176mm x 250mm)
&gt; &gt; iso_a4 (210mm x 297mm)
&gt; &gt; iso_b4 (250mm x 353mm)
&gt; &gt; iso_a3 (297mm x 420 mm)
&gt;
&gt; What if we use a '-' for '_'?
&gt;  na-invoice
&gt;  na-letter
&gt;  na-legal
&gt;  na-ledger
&gt;
&gt;  iso-a5
&gt;  iso-b5
&gt;  iso-a4
&gt;  iso-b4
&gt;  iso-a3
&gt;
&gt; Is this an acceptable subset of all possible media names?

For the North American paper sizes,  I'd say that
na-letter
na-legal
na-ledger
is probably the practical minimum with
na-invoice
being a possibility depending upon how important it is to support a
keyword that will mostly be used for 2-up printing on na-letter or
4-up printing on na-ledger..

For the ISO sizes, it probably would be best to ask a European, (I
just chose the A and B sizes that corresponded to roughly the same
range as the common North American sizes.  Since I have seen A3, A4,
and A5 for sale in the US for computer/copier needs, I'd imagine that
those three sizes see common use, but I'm not as certain about B5 and
B4.

If it is at all practical, I'd also want some input from Japanese and
Chinese users about how commonly their national paper sizes are used
by computer printers there. That IEEE-PWG standard included several
sizes that were formerly, but no longer in common use in North America
such as the old US government letter and legal sizes that the
government hasn't used since the early 80's, so just because it's in
there doesn't mean that people use it today.


</pre>
<p><b>

   FOLLOWUP 10:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Bjoern Hoehrmann
[derhoermi@gmx.net]
Sent: Thursday, January 22, 2004 6:18 PM
To: ernestcline@mindspring.com
Cc: www-style@w3.org
Subject: Re: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


* Ernest Cline wrote:
&gt;For the North American paper sizes,  I'd say that
&gt;na-letter
&gt;na-legal
&gt;na-ledger
&gt;is probably the practical minimum with
&gt;na-invoice
&gt;being a possibility depending upon how important it is to support a
&gt;keyword that will mostly be used for 2-up printing on na-letter or 4-up
&gt;printing on na-ledger..

I would rather question the importance of page size keywords in
general. If I would print web pages, they would be printed to A4 no
matter what a style sheet might specify; with this in mind, I have
little reason to suggest or even request specific paper in my style
sheets, I am certain the user knows better what paper sizes are
available and how he would like to print my page. To me its much like

  @window { size: 1024px 768px full-screen }

something I would not suggest either. I guess the same applies to most
authors aswell. What I fear is that the more convenient it is to
specify a specific paper size, the more people would specify it just
for "completeness" and probably rely on the specification when
defining page margins etc. which would probably complicate printing
with to a different page size; probably even annyoing if my user agent
pre-selects "letter" as paper size or throws an error message if I
attempt to print to A4 while the style sheet requests "letter". Also,
the more keywords are available, the less likely that authors would
remember what keywords are allowed, so they would likely specify
keywords that are not allowed.

I believe that the page size descriptor should only be used to specify
page dimensions if you are certain that the medium you request is
available and I believe that if you are in such a position you would
probably know the phyiscal dimensions of that paper aswell; using a
keyword instead would thus be of little benefit for a small number of
authors.

I prefer the Media Queries approch, you suggest specific layout for
specific page dimensions. If this were about a MQ extension to allow

  @media print and (page-size: A4) { ... }

in place of

  @media print and (width: 21cm) and (height: 29.7cm) { ... }

I would be in favour of additional keywords, but for the page size
descriptor I believe the fewer keywords the better. I can live with A4
and letter though and I would not mind if these were renamed to iso-a4
and na-letter for consistency, but I am opposed to additional
keywords.
</pre>
<p><b>

   FOLLOWUP 11:

   </b></p><pre>
From: Michael Day [mikeday@yeslogic.com]
Sent: Thursday, January 22, 2004 11:00 PM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: www-style@w3.org
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt;  na-invoice
&gt;  na-letter
&gt;  na-legal
&gt;  na-ledger
&gt;
&gt;  iso-a5
&gt;  iso-b5
&gt;  iso-a4
&gt;  iso-b4
&gt;  iso-a3
&gt;
&gt; Is this an acceptable subset of all possible media names?

No; we will continue to support the "a4" keyword, as millions of
people are familiar with A4 paper sizes and have never heard of ISO.

Best regards,

Michael

--
YesLogic Prince prints XML!
http://yeslogic.com
</pre>
<p><b>

   FOLLOWUP 12:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Christoph P�per
[christoph.paeper@tu-clausthal.de]
Sent: Friday, January 23, 2004 8:12 AM
To: www-style@w3.org
Subject: Re: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


*Michael Day*:
&gt;
&gt; No; we will continue to support the "a4" keyword, as millions of
&gt; people are familiar with A4 paper sizes and have never heard of ISO.

JFTR, in Germany nobody says "ISO A4", few just "A4", most "DIN A4".
</pre>
<p><b>

   FOLLOWUP 13:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Tantek �elik
[tantek@cs.stanford.edu]
Sent: Friday, January 23, 2004 8:52 AM
To: www-style@w3.org
Subject: Re: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


On 1/23/04 8:04 AM, "Christoph P�per" &lt;christoph.paeper@tu-clausthal.de&gt;
wrote:

&gt;
&gt; *Michael Day*:
&gt;&gt;
&gt;&gt; No; we will continue to support the "a4" keyword, as millions of
&gt;&gt; people are familiar with A4 paper sizes and have never heard of ISO.
&gt;
&gt; JFTR, in Germany nobody says "ISO A4", few just "A4", most "DIN A4".

And nobody in the US says "NA Letter", most just "letter".

Given that none of the nine suggested minimal keyword value conflict
with each other without a prefix, why is a prefix necessary?

The spec is going to precisely define what each keyword means anyway.

It appears such prefixes are just "codeJunk" (with apologies to E. Tufte).

Tantek
</pre>
<p><b>

   FOLLOWUP 14:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Friday, January 23, 2004 9:36 AM
To: Michael Day
Cc: www-style@w3.org
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt; [Original Message]
&gt; From: Michael Day &lt;mikeday@yeslogic.com&gt;
&gt;
&gt; &gt;  na-invoice
&gt; &gt;  na-letter
&gt; &gt;  na-legal
&gt; &gt;  na-ledger
&gt; &gt;
&gt; &gt;  iso-a5
&gt; &gt;  iso-b5
&gt; &gt;  iso-a4
&gt; &gt;  iso-b4
&gt; &gt;  iso-a3
&gt; &gt;
&gt; &gt; Is this an acceptable subset of all possible media names?
&gt;
&gt; No; we will continue to support the "a4" keyword, as millions of
&gt; people are familiar with A4 paper sizes and have never heard of ISO.

Is this because you truly feel that "a4" is the superior keyword or
because you jumped the gun and have a product that supports a draft
version of this module that was clearly announced as being subject to
change, so you don't want any changes.  Unfortunately, given that
product, I would have to discount your concerns, altho those of others
such as Christoph and Tantek I would still consider as those I have no
reason to believe that their views may be biased by commercial
considerations in this case.

However, now that I've gotten that rant out of my system, the question
to me becomes: "Is it a reasonable possibility that this or a future
version of the Paged Media module would support either the ISO B sizes
or the JIS B sizes by keyword?"  If the answer is yes, then I feel
strongly that the "iso-" prefix (and thus for consistency the "na-"
prefix as well) should be used in the standard.  If not, while I would
still prefer the prefixed versions despite it being codeJunkish, I
would have no objection to using a simple "A4" keyword as at that
point it is clearly a matter of style and not substance.

What scant information I have seen indicates that the Japanese use the
JIS B series in preference to the ISO B series. (I have seen supplies
imported from Japan intended for use in drawing comic books that use
the JIS A and JIS B series for sizes.  (JIS A = ISO A so that's not a
problem.)  However, as I have said, I lack knowledge of the paper
normally used with computers in Japan, and comic books are not
computers.

Since I lack that knowledge, I have asked for more info on the USENET
group soc.culture.japan.  I'll let the list know what response (if
any) I get, or you can look for it yourself.


</pre>
<p><b>

   FOLLOWUP 15:

   </b></p><pre>
From: www-style-request@w3.org on behalf of David Woolley
[david@djwhome.demon.co.uk]
Sent: Friday, January 23, 2004 2:07 PM
To: www-style@w3.org
Subject: Re: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt; I would rather question the importance of page size keywords in
&gt; general. If I would print web pages, they would be printed to A4 no
&gt; matter what a style sheet might specify; with this in mind, I have
&gt; little reason to

Most commercial web designers seem to want to specify layouts in
absolute units (including pixels, which tend to be treated as being at
specific pitches, more closely related to display values than printer
values, when printing).  This is in spite of accessibility guidelines
that discourage them.

Knowing the author's expectations of paper size can allow the print
formatter to scale the image so as to not break the layout.

Whilst my impression is that very few authors even consider printing,
I often have problems with layouts that are forced to be wider than,
at least, portrait A4, and get cropped when printed [1].  If, maybe,
the more aware authors could be given the opportunity of specifying a
print size, they could avoid this problem even if the client still
insisted on a layout that was too wide and wasn't prepared to pay for
detailed styling for a printer layout.  One implication of this is
that the logical print size for such documents will typically not be a
standard paper size.

PDF is a much better tool for producing predictable printer layouts,
but you are not going to stop HTML authors trying to do so (or at
least to produce predictable, high resolution, screen layouts that,
nevertheless, get printed).

Page descriptions languages have the advantage that there is a well
defined bounding box that can be used to calculate the scaling factor
needed to fit the page, whereas trying to do this on HTML might result
in unreaonable column widths.

[1] Sometimes selecting just the real content can avoid the need to
switch to landscape or change the scale factor manually.
</pre>
<p><b>

   FOLLOWUP 16:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Michael Day
[mikeday@yeslogic.com]
Sent: Friday, January 23, 2004 2:24 PM
To: Ernest Cline
Cc: www-style@w3.org
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


Hi Ernest,

My preference for "a4" over "iso-a4" is exactly as I stated: the A4
paper size is known and widely used. If you specify ISO A4, many
people will be confused and think you mean some variant non-standard
size, as people don't know (and don't *need* to know) that A4 is an
ISO standard.

I know that the ISO B sizes and the JIS B sizes conflict. However, the
A sizes don't, and they are in more common use. It makes sense to
support shorthand keywords for the most commonly used ISO sizes.

As to jumping the gun... you will find that we implemented page size
keywords before they were added to the Paged Media draft, and then
proposed them for inclusion back in April 2003 [1]. Discounting the
view of every CSS implementor may give you satisfaction, but I doubt
that it will lead to an improved CSS standard.

[1] http://lists.w3.org/Archives/Public/www-style/2003Apr/0072.html

Best regards,

Michael

--
YesLogic Prince prints XML!
http://yeslogic.com

</pre>
<p><b>

   FOLLOWUP 17:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Friday, January 23, 2004 4:39 PM
To: Michael Day
Cc: W3C CSS List
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt; [Original Message]
&gt; From: Michael Day &lt;mikeday@yeslogic.com&gt;
&gt;
&gt; My preference for "a4" over "iso-a4" is exactly as I stated: the A4
&gt; paper size is known and widely used. If you specify ISO A4, many
&gt; people will be confused and think you mean some variant non-standard
&gt; size, as people don't know (and don't *need* to know) that A4 is an
&gt; ISO standard.
&gt;
&gt; I know that the ISO B sizes and the JIS B sizes conflict. However, the
&gt; A sizes don't, and they are in more common use. It makes sense to
&gt; support shorthand keywords for the most commonly used ISO sizes.
&gt;
&gt; As to jumping the gun... you will find that we implemented page size
&gt; keywords before they were added to the Paged Media draft, and then
&gt; proposed them for inclusion back in April 2003 [1]. Discounting the
&gt; view of every CSS implementor may give you satisfaction, but I doubt
&gt; that it will lead to an improved CSS standard.
&gt;
&gt; [1] http://lists.w3.org/Archives/Public/www-style/2003Apr/0072.html

I said discount, not ignore.  You have a vested interest in seeing
that the CR follows what you have already implemented which raises the
possibility of a conflict of interest.  That is one reason why it is
suggested that private extensions to CSS such as those that Yes Logic
uses have a vendor specific prefix.  That suggestion has been pointed
out to you before IIRC,

If the module goes beyond just A4 and letter, I am of the firm opinion
that the B sizes should be included as well, and that means that a
prefix is needed to indicate whether iso-b4 or jis-b4 is intended.

Quite frankly, I fail to see what is so difficult about iso-a4.  It is
four extra characters to type.  Anyone who will be using this property
will need to refer to some form of documentation. As for the
possibility of doing something like this for the metric sizes:

a5
iso-b5
jis-b5
a4
iso-b4
jis-b4
a3

which would allow one to use a shorter form in those contexts where
the classname prefix is not needed; I think that would be more
confusing than to always use the classname prefix.

In short, I stand by what I said in my previous post.  If there is a
reasonable possibility that keywords for either or both of the B
series of paper sizes would be present in either this version or a
future version of the module, then the classname should be used.  Only
if they are not used and it is made explicit that they will not be
added should using non prefixed keywords even be considered.  The
problem is that I don't believe that if we introduce keywords for
paper size that the list will not be extended to cover at least B4 and
B5.

In an oblique way, you have made my point for me, Michael, Suppose
that, as in the current draft, only the keywords "a4" and "letter" are
supported.  What is there to stop a German company from developing a
user agent that adds "b4" as a keyword as a shorthand for ISO/DIN B4
and a Japanese company from developing a user agent that adds "b4" as
a keyword as a shorthand for JIS B4?  As Yes Logic has shown, the
request of W3C that proprietary CSS extensions use a vendor specific
prefix will be ignored by some.  In that light it would be far better
for the standard to say that all current and future keywords relating
to paper size will follow the &lt;classname&gt; "-" &lt;sizename&gt; form from the
IEEE PWG standard, even if the chosen keywords could be expressed
uniquely by just the &lt;sizename&gt;.  That way when those extensions are
made, and they are likely to be made, at least they will be likelier
to be interoperable and consistent, The alternative would be to not
use keywords at all.  That would cause much more problems for the ISO
sizes than for the North American sizes, but it would be better than
having a standard that would encourage conflicting extensions to the
standard.

I still think that keywords are a good idea, but given the likelihood
of extension to cover the B-series (either officially or unofficially)
I would much prefer the use of "iso-A4" to just "A4".

Note: I have noticed one more IEEE PWG sizename that requires the use
of the class name to distinguish the sizes.  Unlike the two c5's or
the two f's I noted in an earlier post, this might involve a common
size.  It seems that the PRC and the ROC have two different versions
of a size named 16K.  Furthermore, it looks like that size sees some
reasonably common use as I have come across a printer spec that
mentions the 8K and 16K paper sizes by name (along with ISO A3-A5 and
JIS B4-B5, but not ISO B4 or B5 strangely enough) in its list of
supported sizes.

</pre>
<p><b>

   FOLLOWUP 18:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Michael Day
[mikeday@yeslogic.com]
Sent: Friday, January 23, 2004 5:20 PM
To: Ernest Cline
Cc: W3C CSS List
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


Hi Ernest,

&gt; I said discount, not ignore.  You have a vested interest in seeing
&gt; that the CR follows what you have already implemented which raises the
&gt; possibility of a conflict of interest.  That is one reason why it is
&gt; suggested that private extensions to CSS such as those that Yes Logic
&gt; uses have a vendor specific prefix.  That suggestion has been pointed
&gt; out to you before IIRC,

Are you serious?

@page { size: yeslogic-a4 }
@page { size: microsoft-a4 }
@page { size: moz-a4 }
@page { size: -o-a4 }

Of course we will not introduce a vendor specific keyword to represent
the A4 paper size. It is an international standard (!) and hardly
likely to change on a whim. Vendor specific prefixes are not necessary
for things that can only be implemented in one possible way. The
following example is so perfectly obvious and idiomatic that it would
be crazy to remove it:

@page { size: A4 }

I strongly believe that this should be in the standard, not because we
have already implemented it, but because it is a good idea. You are
putting the cart before the horse: we implemented it *because* we
believe that it is a good idea, and we wish to see it in the standard
for the same reason.

If iso-a4 is added to the standard we will definitely support it.
However, we will not remove support for "a4", as the good reasons for
having it remain valid. Our implementation of this keyword without a
vendor prefix is also valid, as the standard will never give the "a4"
keyword a meaning other than ISO A4 paper size.

&gt; If the module goes beyond just A4 and letter, I am of the firm opinion
&gt; that the B sizes should be included as well, and that means that a
&gt; prefix is needed to indicate whether iso-b4 or jis-b4 is intended.

We do not currently support the JIS paper sizes, but if they are
widely used we would be happy to add iso-b* and jis-b* keywords.

Best regards,

Michael

--
YesLogic Prince prints XML!
http://yeslogic.com
</pre>
<p><b>

   FOLLOWUP 19:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Friday, January 23, 2004 7:25 PM
To: Michael Day
Cc: W3C CSS List
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt; [Original Message]
&gt; From: Michael Day &lt;mikeday@yeslogic.com&gt;
&gt; To: Ernest Cline &lt;ernestcline@mindspring.com&gt;
&gt; Cc: W3C CSS List &lt;www-style@w3.org&gt;
&gt; Date: 1/24/2004 5:13:15 PM
&gt; Subject: RE: [css3-page] examples in 3.3.2 (page size) are
&gt; 'US-centric'(?)
&gt;
&gt;
&gt; Hi Ernest,
&gt;
&gt; &gt; I said discount, not ignore.  You have a vested interest in seeing
&gt; &gt; that the CR follows what you have already implemented which raises
&gt; &gt; the possibility of a conflict of interest.  That is one reason why
&gt; &gt; it is suggested that private extensions to CSS such as those that
&gt; &gt; Yes Logic uses have a vendor specific prefix.  That suggestion has
&gt; &gt; been pointed out to you before IIRC,
&gt;
&gt; Are you serious?
&gt;
&gt; @page { size: yeslogic-a4 }
&gt; @page { size: microsoft-a4 }
&gt; @page { size: moz-a4 }
&gt; @page { size: -o-a4 }
&gt;
&gt; Of course we will not introduce a vendor specific keyword to represent
&gt; the A4 paper size. It is an international standard (!) and hardly
&gt; likely to change on a whim. Vendor specific prefixes are not necessary
&gt; for things that can only be implemented in one possible way. The
&gt; following example is so perfectly obvious and idiomatic that it would
&gt; be crazy to remove it:
&gt;
&gt; @page { size: A4 }
&gt;
&gt; I strongly believe that this should be in the standard, not because we
&gt; have already implemented it, but because it is a good idea. You are
&gt; putting the cart before the horse: we implemented it *because* we
&gt; believe that it is a good idea, and we wish to see it in the standard
&gt; for the same reason.

Just because you think "A4" is obvious does not mean that others will
think so, or that it will turn out to be the best solution.  "A4" is
certainly an obvious choice to consider, but for the reasons I have
already given, I don't think that it is the best choice.

Had you followed the recommendation in this case it would have been:

@page {size: -yeslogic-a4 }

(Note the extra - in front.)  Yes, the recommendation does put an
extra burden on those who seek to extend the standards beyond the
current recommendations, but I can't fault the reasoning behind it.

&gt; If iso-a4 is added to the standard we will definitely support it.
&gt; However, we will not remove support for "a4", as the good reasons for
&gt; having it remain valid. Our implementation of this keyword without a
&gt; vendor prefix is also valid, as the standard will never give the "a4"
&gt; keyword a meaning other than ISO A4 paper size.

I'll grant you that it is extremely unlikely that the keyword "a4"
would be used in any other meaning in the context of paper size, if
only because any new standards would likely seek to avoid confusion
with the ISO standards.  The JIS B series was adopted before the DIN
476 standard was adopted as ISO 216 in 1975.  Given that it is only
slightly larger than the ISO B series, I can understand why they never
made the switch.

As for "letter" it was just over 20 years ago that we had two letter
sizes over here in the States, the more commonly used size of 8.5" x
11" and a second size that was used mainly by the government of 8" x
10.5" until as one of the first acts of the Reagan administration, the
sizes used mainly by the government were finally phased out. (Just
think!  If they had instead switched to the ISO standard, we might be
using sane paper sizes here as well.  Certainly the ISO sizes would be
more commonplace in the States than they currently are.)

&gt; &gt; If the module goes beyond just A4 and letter, I am of the firm
&gt; &gt; opinion that the B sizes should be included as well, and that means
&gt; &gt; that a prefix is needed to indicate whether iso-b4 or jis-b4 is
&gt; &gt; intended.
&gt;
&gt; We do not currently support the JIS paper sizes, but if they are
&gt; widely used we would be happy to add iso-b* and jis-b* keywords.

Given your product's current lack of support of East Asian scripts
(according to your website) I can understand the lack of JIS paper
support.  I wish I knew more about the paper sizes used in China and
Japan.  What information I have been able to find suggests that they
have some non-ISO sizes that are in common use there, (probably at
least as common as 11" x 17 " is here in the States) but nothing to
indicate how common.


</pre>
<p><b>

   FOLLOWUP 20:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Michael Day
[mikeday@yeslogic.com]
Sent: Friday, January 23, 2004 7:54 PM
To: Ernest Cline
Cc: W3C CSS List
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


Hi Ernest,

&gt; Just because you think "A4" is obvious does not mean that others will
&gt; think so, or that it will turn out to be the best solution.  "A4" is
&gt; certainly an obvious choice to consider, but for the reasons I have
&gt; already given, I don't think that it is the best choice.

It is not that *I* think that it is obvious, it is that A4 paper is
commonly referred to as such by the wider user community. It is
marketed and sold as being "A4 paper" and printers and photocopiers
offer "A4" paper trays and folders are sold as "A4 folders" for
holding A4 paper and so on and so on. The ISO acronym never comes up
outside of forums devoted to standardisation such as this one.

Allowing the ISO prefix is fine and consistent. But *requiring* it is
unnecessary, redundant, pedantic and confusing for ordinary users.

&gt; Had you followed the recommendation in this case it would have been:
&gt;
&gt; @page {size: -yeslogic-a4 }

One look at this monstrosity makes it pretty obvious why we did not
implement it this way. Not to mention that identifiers cannot begin
with a hyphen-minus in CSS 2, the highest level of CSS that is
currently a W3C Recommendation (and has not been deprecated). Only the
Working Draft of CSS 2 Revision 1 allows this syntax.

If we were implementing a new property that was likely to conflict
with an existing or future property from another vendor, then we would
need to qualify it appropriately to avoid conflicts. But as I said
before, qualifying "A4" in this manner is ridiculous.

Similarly with the extension in the usage of the portrait and landscape
keywords:

@page { size: A4 landscape }

It would be difficult to keep a straight face while documenting this:

@page { size: -yeslogic-A4 -yeslogic-landscape }

&gt; (Note the extra - in front.)  Yes, the recommendation does put an
&gt; extra burden on those who seek to extend the standards beyond the
&gt; current recommendations, but I can't fault the reasoning behind it.

Standardisation follows implementation, not the other way around.

Best regards,

Michael

--
YesLogic Prince prints XML!
http://yeslogic.com
</pre>
<p><b>

   FOLLOWUP 21:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Tantek �elik
[tantek@cs.stanford.edu]
Sent: Friday, January 23, 2004 8:41 PM
To: Michael Day; Ernest Cline
Cc: www-style@w3.org
Subject: Re: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


On 1/23/04 6:52 PM, "Michael Day" &lt;mikeday@yeslogic.com&gt; wrote:

&gt;
&gt;
&gt; Hi Ernest,
&gt;
&gt;&gt; Just because you think "A4" is obvious does not mean that others will
&gt;&gt; think so, or that it will turn out to be the best solution.  "A4" is
&gt;&gt; certainly an obvious choice to consider, but for the reasons I have
&gt;&gt; already given, I don't think that it is the best choice.
&gt;
&gt; It is not that *I* think that it is obvious, it is that A4 paper is
&gt; commonly referred to as such by the wider user community. It is
&gt; marketed and sold as being "A4 paper" and printers and photocopiers
&gt; offer "A4" paper trays and folders are sold as "A4 folders" for
&gt; holding A4 paper and so on and so on. The ISO acronym never comes up
&gt; outside of forums devoted to standardisation such as this one.
&gt;
&gt; Allowing the ISO prefix is fine and consistent. But *requiring* it is
&gt; unnecessary, redundant, pedantic and confusing for ordinary users.

I agree with this sentence 100%.  Too often it seems standards
committees add extra codeJunk to technologies for some sort of
theoretical fear without considering the practical inconvenience
multiplied thousand/million-fold for users.


&gt;&gt; Had you followed the recommendation in this case it would have been:
&gt;&gt;
&gt;&gt; @page {size: -yeslogic-a4 }
&gt;
&gt; One look at this monstrosity makes it pretty obvious why we did not
&gt; implement it this way.

Nothing says you have to use your fullname.  You could have used

 -yl-a4

or even:

 -y-a4 (no one is using the -y- prefix yet AFAIK, and Opera chose to
use -o- so why not?  and if there are eventual collisions it doesn't
matter because folks are not supposed to depend on these eventually
anyway).


&gt; Not to mention that identifiers cannot begin with a hyphen-minus in
&gt; CSS 2, the highest level of CSS that is currently a W3C Recommendation
&gt; (and has not been deprecated). Only the Working Draft of CSS 2
&gt; Revision 1 allows this syntax.

True, but if that was your concern, you could have used a y-

And thanks for the reminder that the CSS WG needs to hurry up and
deliver the CSS2.1 CR so that this excuse can no longer be used :)


&gt; If we were implementing a new property that was likely to conflict
&gt; with an existing or future property from another vendor, then we would
&gt; need to qualify it appropriately to avoid conflicts. But as I said
&gt; before, qualifying "A4" in this manner is ridiculous.

Agreed, but is this good practice for an implementer of standards? (


&gt; Similarly with the extension in the usage of the portrait and
&gt; landscape
&gt; keywords:
&gt;
&gt; @page { size: A4 landscape }
&gt;
&gt; It would be difficult to keep a straight face while documenting this:
&gt;
&gt; @page { size: -yeslogic-A4 -yeslogic-landscape }
&gt;
&gt;&gt; (Note the extra - in front.)  Yes, the recommendation does put an
&gt;&gt; extra burden on those who seek to extend the standards beyond the
&gt;&gt; current recommendations, but I can't fault the reasoning behind it.
&gt;
&gt; Standardisation follows implementation, not the other way around.

I am of two opinions about that.

In general I agree that standardization should follow implementation,
rather than having committees of folks (most of whom may not even have
pragmatic interests in the technologies involved) invent a bunch of
theoretical stuff that no one ends up using.

OTOH, if implementers see an area that needs development, it may make
sense for them to cooperate in a standards committee to establish a
common format rather than experimenting with different incompatible
variants first, and then later having to potentially change and have
all their customers change etc.

Regards,

Tantek
</pre>
<p><b>

   FOLLOWUP 22:

   </b></p><pre>
From: www-style-request@w3.org on behalf of David Woolley
[david@djwhome.demon.co.uk]
Sent: Saturday, January 24, 2004 1:44 AM
To: www-style@w3.org
Subject: Re: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt; Is this because you truly feel that "a4" is the superior keyword or
&gt; because you jumped the gun and have a product that supports a draft
&gt; version of

From the UK point of view, I think most people who understood the ISO
reference would also know the actual size and not need the keyword.
</pre>
<p><b>

   FOLLOWUP 23:

   </b></p><pre>
From: www-style-request@w3.org on behalf of David Woolley
[david@djwhome.demon.co.uk]
Sent: Saturday, January 24, 2004 3:05 AM
To: www-style@w3.org
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt; is confusing.  Either the author will have access to the documentation

In which case they will also have access to the wrappers on the reams
of paper or a table of common paper sizes in the documentation.

&gt; or he will using an authoring tool that hides that detail from him.

In which case the tool can just as easily use the actual size.

&gt; Assuming that he is writing his own CSS by hand how would he know
&gt; without consulting documentation that he needs to know to use:

(Most authors seem to do it by copying code from other pages, rather
than reading documentation.  Very few read source documents, as
against books claiming to make technology understandable to the
masses.)

From my point of view, named paper sizes exist purely as a convenience
to authors, to allow them to use the terms they would use
normally. Authors in the UK say "A4".

One point that seems to have been overlooked here is that it is not
just the paper size but also the printable area that matters.  Paper
size is only important in as much as white margins on a document may
allow the document to be printed without exceeding the printable area
(except for professional book printing, but that is very much page
description territory, where printing is on oversized paper that is
then cropped, and for, more or less obsolete, fan fold paper with tear
off sprockets).

Some batch mode typesetting programs actually define variant "paper
sizes" to allow for printers, e.g. HP DeskJet, that have significant
non-printable areas.

With WYSIWYG programs, named paper sizes are not really absolute but
represent the printable area on the currently selected printer. That
can actually have quite unfortunate results when Word users fix up
their awkward page breaks by adding blank lines, or hard page breaks,
rather than careful use of "keep with next", etc.  The WYSIWYG
paradigm breaks down when the recipient of a document prints it on a
different printer model than the one for which it was layed out.
</pre>
<p><b>

   FOLLOWUP 24:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Bjoern Hoehrmann
[derhoermi@gmx.net]
Sent: Saturday, January 24, 2004 6:43 AM
To: Michael Day
Cc: www-style@w3.org
Subject: Re: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


* Michael Day wrote:
&gt;It is not that *I* think that it is obvious, it is that A4 paper is
&gt;commonly referred to as such by the wider user community. It is
&gt;marketed and sold as being "A4 paper" and printers and photocopiers offer "A4"
&gt;paper trays and folders are sold as "A4 folders" for holding A4 paper and
&gt;so on and so on. The ISO acronym never comes up outside of forums devoted
&gt;to standardisation such as this one.

In Germany you will virtually always encounter "DIN A4"; omitting the
DIN prefix seems thus just wrong and is rather confusing to me.
</pre>
<p><b>

   FOLLOWUP 25:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1)
Sent: Friday, January 30, 2004 10:23 AM
To: 'www-style@w3.org'
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)

Hello,

After reading all the posts on this subject, I'm included to have the
CSS3 Page Media and CSS Print Profile specification require the
following names be recognized as media names, all other media would
have to be selected by width and height:

letter, legal, ledger,
a5, b5, a4, b4, a3

Where the names are not case sensitive.

Jim Bigelow,
Editor of CSS Print Profile and CSS3 Pages Media

&gt; -----Original Message-----
&gt; From: BIGELOW,JIM (HP-Boise,ex1)
&gt; Sent: Thursday, January 22, 2004 1:47 PM
&gt; To: www-style@w3.org
&gt; Cc: 'Michael Day'
&gt; Subject: RE: [css3-page] examples in 3.3.2 (page size) are
&gt; 'US-centric'(?)
&gt;
&gt;
&gt; Hello,
&gt;
&gt; Ernest wrote:
&gt; &gt; Sent: Monday, January 19, 2004 9:43 PM
&gt; &gt; What follows is what I feel to be a likely maximum minimum:
&gt; &gt;
&gt; &gt; na_invoice (5.5" x 8.5")
&gt; &gt; na_letter (8.5" x 11")
&gt; &gt; na_legal (8.5" x 14")
&gt; &gt; na_ledger (11" x 17")
&gt; &gt;
&gt; &gt; iso_a5 (148mm x 210mm)
&gt; &gt; iso_b5 (176mm x 250mm)
&gt; &gt; iso_a4 (210mm x 297mm)
&gt; &gt; iso_b4 (250mm x 353mm)
&gt; &gt; iso_a3 (297mm x 420 mm)
&gt; &gt;
&gt;
&gt; What if we use a '-' for '_'?
&gt;  na-invoice
&gt;  na-letter
&gt;  na-legal
&gt;  na-ledger
&gt;
&gt;  iso-a5
&gt;  iso-b5
&gt;  iso-a4
&gt;  iso-b4
&gt;  iso-a3
&gt;
&gt; Is this an acceptable subset of all possible media names?
&gt;
&gt; Jim Bigelow, Editor
&gt;
</pre>
<p><b>

   FOLLOWUP 26:

   </b></p><pre>
From: Ernest Cline [ernestcline@mindspring.com]
Sent: Friday, January 30, 2004 12:18 PM
To: BIGELOW,JIM (HP-Boise,ex1); www-style@w3.org
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt;
&gt; After reading all the posts on this subject, I'm included to have the
&gt; CSS3 Page Media and CSS Print Profile specification require the
&gt; following names be recognized as media names, all other media would
&gt; have to be selected by width and height:
&gt;
&gt; letter, legal, ledger,
&gt; a5, b5, a4, b4, a3
&gt;
&gt; Where the names are not case sensitive.

For non-East Asian uses this should be both sufficient and
acceptable. I still think that b5 and b4 will be a source of confusion
for Japanese users. However, since jis-b5 is just slightly larger than
iso-b5 and jis-b4 is just slightly larger than iso-b4, it shouldn't be
a source of major usability problems.  If at all feasible, I still
think it would be a good idea to consult with someone more
knowledgeable than I am about East Asian printing practices to make
certain that we aren't ignoring commonly used Japanese or Chinese
paper sizes.  I know enough to be concerned, but not enough to know
how concerned the WG should be.

Asking about paper sizes in soc.culture.japan turned out to be a total
waste of time.  A more useless, troll-filled newsgroup I have never
seen.

Since there is precedent for describing keywords using uppercase, even
tho all CSS keywords are case insignificant, it might be preferable to
give the ISO sizes as A5, B5, A4, B4, and A3. since that is the usual
form they take outside of technical specs since it has been decided to
use keywords that are less technical looking.


</pre>
<p><b>

   FOLLOWUP 27:

   </b></p><pre>
From: Christoph P�per [christoph.paeper@tu-clausthal.de]
Sent: Tuesday, February 10, 2004 6:06 PM
To: www-style@w3.org
Cc: BIGELOW,JIM (HP-Boise,ex1)
Subject: Re: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)

*BIGELOW,JIM (HP-Boise,ex1)*:
&gt;
&gt; This issue, number 36,
&gt;
&gt; 3. the following media names must be supported by Use Agents as
&gt; keywords in the size property: letter, legal, ledger, A5, B5, A4, B4,
&gt; A3

B* being from the ISO, not the JIS series, obviously.  Note that while
'legal' and 'letter' are legacy names in PWG 5101.1, 'ledger' and the
short ISO size names are aliases. Not that it did matter in any way.

*May* UAs recognize any self-chosen subset of alias and legacy names
 from that spec as long as it includes the eight keywords above? I
 suppose yes.

&gt; 4.  ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf will be
&gt; referenced as the definitive specification for media names

It's also available as .doc (MS Word, I assume) and .rtf, JFTR. I
think that specifications is good for use as a definite collection,
but not so much for general normative reference, because of its custom
and self-describing names.
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: www-style@w3.org
Subject: RE: [css3-page] examples in 3.3.2 (page size) are
'US-centric'(?)

This issue, number 36, has been resolved by the editor, who wishes to
thank all those who have taken the time to add to this discussion:
Jungshik Shin, Ernest Cline, Don Wright, Bjoern Hoehrmann, Christoph
P�per, Michael Day, Tantek �elik, David Woolley.

&gt;
&gt; There are two examples (excluding the first example for
&gt; 'auto') given in section 3.3.2 and both of them refer to US
&gt; letter. I think at least one of them had better use ISO A4,
&gt; instead given that virtually all other countries use ISO A4.
&gt; Besides, as already pointed out twice, A4 is only 21.0 cm
&gt; wide and 29.7 cm high instead of 210cm and 297cm. It might be
&gt; a good idea to use 21.0 cm and 29.7 cm instead of 210 mm and
&gt; 297 mm because numbers (21.0 and 29.7) are more comparable
&gt; to 8.5 and 11 for US letter than 210 and 297.

The resolution is:
1. there will be an example use the size a4

2. the units will be in mm

3. the following media names must be supported by Use Agents as
   keywords in the size property: letter, legal, ledger, A5, B5, A4,
   B4, A3

4.  ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf will be
    referenced as the definitive specification for media names


 -- Jim Bigelow, editor
</pre>
<h2><a id="issue37" name="issue37">1.37  XSL FO SG comment on css3-page spec
</a></h2><p><b>PROBLEM ID: 37</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Not an issue, no change proposed.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Paul Grosso
[pgrosso@arbortext.com]
Sent: Tuesday, February 03, 2004 12:19 PM
To: www-style@w3.org
Subject: XSL FO SG comment on css3-page spec


Regarding:  CSS3 Paged Media Module
    http://www.w3.org/TR/2003/WD-css3-page-20031218

The XSL FO SG &lt;w3c-xsl-fo-sg@w3.org&gt; notes that the model described in
this draft differs from that in the XSL spec [1].

Specifically, the areas that correspond to XSL's region-before, etc.,
appear to fall outside the page margins whereas in XSL, they lie
within the page margins.

We have not had a chance to evaluate this more closely, so we have no
more details at this time, but we wanted to get this comment in before
it gets any later.

Paul Grosso
for the XSL FO SubGroup of the XSL WG

[1] http://www.w3.org/TR/xsl/slice6.html#fo_simple-page-master
</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: Paul Grosso; www-style@w3.org
Subject: RE: XSL FO SG comment on css3-page spec

Paul,

Thank you for your comment. It has been assigned issue number 37.

You wrote:
&gt; Regarding:  CSS3 Paged Media Module
&gt;     http://www.w3.org/TR/2003/WD-css3-page-20031218
&gt;
&gt; The XSL FO SG &lt;w3c-xsl-fo-sg@w3.org&gt; notes that the model
&gt; described in this draft differs from that in the XSL spec [1].
&gt;
&gt; Specifically, the areas that correspond to XSL's
&gt; region-before, etc., appear to fall outside the page margins
&gt; whereas in XSL, they lie within the page margins.
&gt;
&gt; We have not had a chance to evaluate this more closely, so we
&gt; have no more details at this time, but we wanted to get this
&gt; comment in before it gets any later.
&gt;
&gt; Paul Grosso
&gt; for the XSL FO SubGroup of the XSL WG
&gt;
&gt; [1] http://www.w3.org/TR/xsl/slice6.html#fo_simple-page-master
&gt;
 -- Jim Bigelow, Editor</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Paul Grosso
[pgrosso@arbortext.com]
Sent: Tuesday, February 17, 2004 12:39 PM
To: www-style@w3.org
Subject: RE: XSL FO SG comment on css3-page spec


The XSL FO SG's understanding is that an important goal for
W3C style-related specifications is to maintain consistency
across the various models.

The XSL FO SG developed the XSL simple page master model based on the
recommendations of the CSS WG at the time, and we expected that the
CSS model would be consistent with this.

Therefore, the XSL FO SG does not accept this disposition of our Last
Call comment on CSS3 Paged Media Module.

Paul Grosso for the XSL FO SubGroup of the XSL WG

At 01:02 2004 02 14 -0500, BIGELOW,JIM (HP-Boise,ex1) wrote:
&gt;Paul,
&gt;
&gt;Thank you for your comment of the CSS3 Paged Media Module. I agree that
&gt;the finer-grained page margin box model in this specification appears
&gt;to differ from the model referenced in you comment. There are no
&gt;changes planned at this  to address this issue.  If you have further
&gt;comment on this topic, you have seven days to reply, until February 20,
&gt;2004.
&gt;
&gt;You comment (#37):
&gt;&gt;
&gt;&gt; Regarding:  CSS3 Paged Media Module
&gt;&gt;     http://www.w3.org/TR/2003/WD-css3-page-20031218
&gt;&gt;
&gt;&gt; The XSL FO SG &lt;w3c-xsl-fo-sg@w3.org&gt; notes that the model
&gt;&gt; described in this draft differs from that in the XSL spec [1].
&gt;&gt;
&gt;&gt; Specifically, the areas that correspond to XSL's
&gt;&gt; region-before, etc., appear to fall outside the page margins
&gt;&gt; whereas in XSL, they lie within the page margins.
&gt;&gt;
&gt;&gt; We have not had a chance to evaluate this more closely, so we
&gt;&gt; have no more details at this time, but we wanted to get this
&gt;&gt; comment in before it gets any later.
&gt;&gt;
&gt;&gt; Paul Grosso
&gt;&gt; for the XSL FO SubGroup of the XSL WG
&gt;&gt;
&gt;&gt; [1] http://www.w3.org/TR/xsl/slice6.html#fo_simple-page-master
&gt;&gt;
&gt;
&gt;  -- Jim Bigelow, editor
</pre>
<p><b>

   FOLLOWUP 02:

   </b></p><pre>
To: Paul Grosso; www-style@w3.org
Subject: RE: XSL FO SG comment on css3-page spec

Paul,

You wrote:
&gt; The XSL FO SG's understanding is that an important goal for
&gt; W3C style-related specifications is to maintain consistency
&gt; across the various models.
&gt;

XSL [1] and CSS3 Paged Media Module [2] appear to have essentially the
same page model:

1. a rectangular area for content with
2. an area in the center for document content and surrounding this,
3. two areas at the top and bottom of the area for page headers and
   footers, and
4. two areas at the left and right of the area for marginalia.

The mapping of XSL to CSS3 Paged Media Module appears to be:

fo:region-body formatting object &lt;--&gt; @page

&gt; The XSL FO SG developed the XSL simple page master model
&gt; based on the recommendations of the CSS WG at the time, and
&gt; we expected that the CSS model would be consistent with this.

The CSS WG published Paged Media Properties for CSS3, W3C Working
Draft 28 September 1999 [3] with it's page model.  The current draft
[2] is merely an elaboration in the basic model proposed in [3].

The XSL Working Group published Extensible Stylesheet Language (XSL),
Version 1.0. W3C Working Draft 12 January 2000 [4] which contained a
definition of fo:simple-page-master [5] that is congruent with the CSS
WG's page model. However, the Working Draft of 1 March 2000 [6] can be
consider as departing from the CSS page model with the introduction of
it's current model [7].  If there are inconsistencies, which I don�t
think are since the models are essentially the same, it appears that
the XSL draft [6] introduced a perceived inconsistency and not the
current CSS draft [2].

For these reasons, the CSS WG declines to make changes to address what
it does not perceive as inconsistencies between CSS and XSL.

-- Jim Bigelow, editor

[1] http://www.w3.org/TR/xsl/slice6.html#fo_simple-page-master
[2] http://www.w3.org/TR/css3-page/#page-model
[3] http://www.w3.org/TR/1999/WD-css3-page-19990928
[4] http://www.w3.org/TR/2000/WD-xsl-20000112/
[5] http://www.w3.org/TR/2000/WD-xsl-20000112/#fo_simple-page-master
[6] http://www.w3.org/TR/2000/WD-xsl-20000301/
[7] http://www.w3.org/TR/2000/WD-xsl-20000301/#fo_simple-page-master</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: Paul Grosso
Cc: www-style@w3.org
Subject: RE: XSL FO SG comment on css3-page spec

Paul,

Thank you for your comment of the CSS3 Paged Media Module. I agree
that the finer-grained page margin box model in this specification
appears to differ from the model referenced in you comment. There are
no changes planned at this to address this issue.  If you have further
comment on this topic, you have seven days to reply, until February
20, 2004.

You comment (#37):
&gt;
&gt; Regarding:  CSS3 Paged Media Module
&gt;     http://www.w3.org/TR/2003/WD-css3-page-20031218
&gt;
&gt; The XSL FO SG &lt;w3c-xsl-fo-sg@w3.org&gt; notes that the model
&gt; described in this draft differs from that in the XSL spec [1].
&gt;
&gt; Specifically, the areas that correspond to XSL's
&gt; region-before, etc., appear to fall outside the page margins
&gt; whereas in XSL, they lie within the page margins.
&gt;
&gt; We have not had a chance to evaluate this more closely, so we
&gt; have no more details at this time, but we wanted to get this
&gt; comment in before it gets any later.
&gt;
&gt; Paul Grosso
&gt; for the XSL FO SubGroup of the XSL WG
&gt;
&gt; [1] http://www.w3.org/TR/xsl/slice6.html#fo_simple-page-master
&gt;

  -- Jim Bigelow, editor</pre>
<h2><a id="issue38" name="issue38">1.38  [css3-page] Last Call Comments on CSS3 Paged Media Module
    FW: [css-page] New, last draft of CSS3 Paged Media Module
Thursday, December 18, 2003 12:37 PM To: www-style@w3.org
</a></h2><p><b>PROBLEM ID: 38</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted, referenced specification and media names.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of don@lexmark.com
Sent: Friday, January 30, 2004 9:48 AM
To: www-style@w3.org
Subject: [css3-page] Last Call Comments on CSS3 Paged Media Module


In section 3.3.2, paper sizes may be specified by dimensions or by two
key words "A4" and "letter."

I would suggest that this document use and reference the PWG Standard
5101.1-2001 entitled "Media Standardized Names" available from
ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf

I am not suggesting that all the media sizes listed there be allowed
but that those required to be allowed be drawn from that standard's
list and any extensions be compliant with that standard.

**********************************************
 Don Wright                 don@lexmark.com

 Chair,  IEEE SA Standards Board
 Member, IEEE-ISTO Board of Directors
 f.wright@ieee.org / f.wright@computer.org

 Director, Alliances & Standards
 Lexmark International
 740 New Circle Rd
 Lexington, Ky 40550
 859-825-4808 (phone) 603-963-8352 (fax)
**********************************************


---------------------- Forwarded by Don Wright/Lex/Lexmark on
                       01/30/2004 12:41 PM ---------------------------

"BIGELOW,JIM (HP-Boise,ex1)" &lt;jim.bigelow@hp.com&gt; on 12/18/2003 05:45:27 PM

To:    don@lexmark.com, elliott.bradshaw@zoran.com,
       Lee.Farrell@cda.canon.com
cc:
Subject:    FW: [css-page] New, last draft of CSS3 Paged Media Module


Hello,

The latest draft of the W3C's CSS3 Paged Media (see the announcement
below) contains a section on image-orientation that is based on the
discussions at the PWG.  I hope that you could look at this a send
comments as you see fit.

Best regards,

Jim

-----Original Message-----
From: www-style-request@w3.org
[mailto:www-style-request@w3.org] On Behalf Of Bert Bos Sent:
Thursday, December 18, 2003 12:37 PM To: www-style@w3.org Subject:
[css-page] New, last draft of CSS3 Paged Media Module


This is the (hopefully) last call for comments on the draft "CSS3
Paged Media Module":

    http://www.w3.org/TR/2003/WD-css3-page-20031218

It contains properties and @-rules that deal with pagination: running
headers, page numbers, page margins, etc.

The deadline for comments is January 31. The next step after that
should is a W3C Candidate Recommendation (unless the comments uncover
problems).

Please send comments to this mailing list. To help the working group
find them, please prefix any message with "[css3-page]", as in the
subject line of this message.


Bert
--
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France


</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: don@lexmark.com; www-style@w3.org
Subject: RE: [css3-page] Last Call Comments on CSS3 Paged Media Module

Don,

Thank you for you comment. It has been assigned issue number 38.

You wrote:
&gt; In section 3.3.2, paper sizes may be specified by dimensions
&gt; or by two key words "A4" and "letter."
&gt;
&gt; I would suggest that this document use and reference the PWG
&gt; Standard 5101.1-2001 entitled "Media Standardized Names"
&gt; available from ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf
&gt;
&gt; I am not suggesting that all the media sizes listed there be
&gt; allowed but that those required to be allowed be drawn from
&gt; that standard's list and any extensions be compliant with
&gt; that standard.
&gt;

As editor, it is my intention to reference the PWG Standard "Media
Standardized Names" in the CSS3 Page Media Module. However, I have a
concern that this standard limits itself as follows and therefore, may
not be directly applicable to use for potentially human authored
documents:

 "The intent of the names defined in this standard is for program to
 program communication, not for internal use within a program or
 for program to human display." [1]

In the case of potentially human authored CSS style sheets where a CSS
keyword is used to represent a media size, the current proposal (as of
4 February 2004) is to use the following new CSS keywords that are
defined with Media Size Self-Describing Name from the PWG standard:

Keyword    Media Size Self-Describing Name
 letter	na_letter_8.5x11in
 legal      na_legal_8.5x14in
 ledger     na_ledger_11x17in
 a5         iso_a5_148x210mm
 a4         iso_a4_210x297mm
 a3         iso_a3_297x420mm
 b5         iso_b5_176x250mm
 b4         iso_b4_250x353mm

The new keywords were chosen for readability, clarity, and
conciseness--all import attributes of potentially human authored
documents.  The following is an example usage:

@page { size: a4 }

This example seems preferable to "@page { size: iso_a4_210x297mm }" as
the characters "iso_" and "_210x297mm" do not seem to lead to an
improvement in any of the characteristics mentioned above.

Further comments on this issue are both encouraged and
welcomed. Please respond within seven days, i.e., by 11 February
2004. No response will be considered tacit approval.

 -- Jim Bigelow, editor

[1] Section 1.1 Scope, ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf
</pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: don@lexmark.com
Sent: Wednesday, February 04, 2004 4:04 PM
To: BIGELOW,JIM (HP-Boise,ex1)
Subject: RE: [css3-page] Last Call Comments on CSS3 Paged Media Module


Jim:

I would suggest that rather than using the self-describing names list
in the standard you mandate the use of the common aliases listed there
and force a direct correlation between those aliases and the physical
characteristics listed.  I don't have the standards here right now but
the only problem might be if the same alias was used to describe two
difference sizes of paper.  I don't think that's the case with any of
the common sizes.

*******************************************
Don Wright                 don@lexmark.com

Chair,  IEEE SA Standards Board
Member, IEEE-ISTO Board of Directors
f.wright@ieee.org / f.wright@computer.org

Director, Alliances and Standards
Lexmark International
740 New Circle Rd C14/082-3
Lexington, Ky 40550
859-825-4808 (phone) 603-963-8352 (fax)
*******************************************


"BIGELOW,JIM (HP-Boise,ex1)" &lt;jim.bigelow@hp.com&gt; on 02/04/2004 05:10:11 PM

To:    don@lexmark.com, www-style@w3.org
cc:
Subject:    RE: [css3-page] Last Call Comments on CSS3 Paged Media Module


Don,

Thank you for you comment. It has been assigned issue number 38.

You wrote:
&gt; In section 3.3.2, paper sizes may be specified by dimensions or by two
&gt; key words "A4" and "letter."
&gt;
&gt; I would suggest that this document use and reference the PWG Standard
&gt; 5101.1-2001 entitled "Media Standardized Names" available from
&gt; ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf
&gt;
&gt; I am not suggesting that all the media sizes listed there be allowed
&gt; but that those required to be allowed be drawn from that standard's
&gt; list and any extensions be compliant with that standard.
&gt;

As editor, it is my intention to reference the PWG Standard "Media
Standardized Names" in the CSS3 Page Media Module. However, I have a
concern that this standard limits itself as follows and therefore, may
not be directly applicable to use for potentially human authored
documents:

 "The intent of the names defined in this standard is for program to
 program communication, not for internal use within a program or for
 program to human display." [1]

In the case of potentially human authored CSS style sheets where a CSS
keyword is used to represent a media size, the current proposal (as of
4 February 2004) is to use the following new CSS keywords that are
defined with Media Size Self-Describing Name from the PWG standard:

Keyword    Media Size Self-Describing Name
 letter     na_letter_8.5x11in
 legal      na_legal_8.5x14in
 ledger     na_ledger_11x17in
 a5         iso_a5_148x210mm
 a4         iso_a4_210x297mm
 a3         iso_a3_297x420mm
 b5         iso_b5_176x250mm
 b4         iso_b4_250x353mm

The new keywords were chosen for readability, clarity, and
conciseness--all import attributes of potentially human authored
documents.  The following is an example usage:

@page { size: a4 }

This example seems preferable to "@page { size: iso_a4_210x297mm }" as
the characters "iso_" and "_210x297mm" do not seem to lead to an
improvement in any of the characteristics mentioned above.

Further comments on this issue are both encouraged and
welcomed. Please respond within seven days, i.e., by 11 February
2004. No response will be considered tacit approval.

 -- Jim Bigelow, editor

 [1] Section 1.1 Scope, ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf


</pre>
<p><b>

   FOLLOWUP 02:

   </b></p><pre>
From: don@lexmark.com
Sent: Wednesday, February 11, 2004 5:59 AM
To: BIGELOW,JIM (HP-Boise,ex1)
Subject: RE: [css3-page] Last Call Comments on CSS3 Paged Media Module


Jim:

Isn't there now a reference to the PWG Media Standard in the document as well?

If so, I'm happy with the resolution.

**********************************************
Don Wright don@lexmark.com
Chair, IEEE SA Standards Board
Member, IEEE-ISTO Board of Directors
f.wright@ieee.org / f.wright@computer.org
Director, Alliances & Standards
Lexmark International
740 New Circle Rd
Lexington, Ky 40550
859-825-4808 (phone) 603-963-8352 (fax)
**********************************************


"BIGELOW,JIM (HP-Boise,ex1)" &lt;jim.bigelow@hp.com&gt; on 02/10/2004 10:47:55 PM

To:    don@lexmark.com, www-style@w3.org
cc:
Subject:    RE: [css3-page] Last Call Comments on CSS3 Paged Media Module


Don,

You comment, which was given issue number 38, has been resolved in the
following way:

The legacy names letter and legal will be used as well as the aliases
ledger, A5, B5, A4, B4, and A3.

If you have further comment on this issue you have 7 days until Feb
17, 2004 to reply.

 -- Jim Bigelow, editor

Your comment:
&gt; In section 3.3.2, paper sizes may be specified by dimensions or by two
&gt; key words "A4" and "letter."
&gt;
&gt; I would suggest that this document use and reference the PWG Standard
&gt; 5101.1-2001 entitled "Media Standardized Names" available from
&gt; ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf
&gt;
&gt; I am not suggesting that all the media sizes listed there be allowed
&gt; but that those required to be allowed be drawn from that standard's
&gt; list and any extensions be compliant with that standard.
 &gt;


</pre>
<p><b>

   FOLLOWUP 03:

   </b></p><pre>
To: don@lexmark.com
Subject: RE: [css3-page] Last Call Comments on CSS3 Paged Media Module

Don,

You wrote about issue 38:
&gt;
&gt; Isn't there now a reference to the PWG Media Standard in the
&gt; document as well?
&gt;
&gt; If so, I'm happy with the resolution.
&gt;

Yes, the Media Standardized Names standard is referenced during the
discussion of media names.

Best regards,

Jim
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: don@lexmark.com; www-style@w3.org
Subject: RE: [css3-page] Last Call Comments on CSS3 Paged Media Module

Don,

You comment, which was given issue number 38, has been resolved in the
following way:

The legacy names letter and legal will be used as well as the aliases
ledger, A5, B5, A4, B4, and A3.

If you have further comment on this issue you have 7 days until Feb
17, 2004 to reply.

 -- Jim Bigelow, editor

Your comment:
&gt; In section 3.3.2, paper sizes may be specified by dimensions
&gt; or by two key words "A4" and "letter."
&gt;
&gt; I would suggest that this document use and reference the PWG
&gt; Standard 5101.1-2001 entitled "Media Standardized Names"
&gt; available from ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf
&gt;
&gt; I am not suggesting that all the media sizes listed there be
&gt; allowed but that those required to be allowed be drawn from
&gt; that standard's list and any extensions be compliant with
&gt; that standard.
&gt;
</pre>
<h2><a id="issue39" name="issue39">1.39  RE: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example
>  RE: [css3-page] LCWD issue 23 --  [23] Section 3.4.1 Example
</a></h2><p><b>PROBLEM ID: 39</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted comment and changed example.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Saturday, February 07, 2004 6:31 PM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: W3C CSS List
Subject: RE: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; To: &lt;ernestcline@mindspring.com&gt;
&gt; Date: 2/7/2004 8:30:01 PM
&gt; Subject: RE: [css3-page] LCWD issue 23 --  [23] Section 3.4.1 Example
&gt;
&gt; Your issue, shown below, has been rejected by the editor.  If you have
&gt; any further comment on this topic, you have 7 days, until 14 February
&gt; 2004, to respond.
&gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; The placing of the comments in the example is haphazard.  Sometimes
&gt; &gt; they are inside the declaration block, other times they are outside.
&gt; &gt; Either placement is justifiable, but the example would look better if
&gt; &gt; comment placement were consistent.
&gt; &gt;
&gt;
&gt; The comments placed in outside versus inside the declaration blocks
&gt; have different purposes. Those within the declarations serve as
&gt; pseudo-code, albeit clumsily, while those outside the block are
&gt; explanations.

While looking over that section to see if I wished to make any comment
on your rejection of this issue, (I decided on making no comment) I
noticed a pair of more serious problems.

1) The last four @page rules in the example box are missing the second '}'.

***

2)The last example in the example block is faulty:

@page :left { @bottom-left-corner { ... /* left page numbers */ }}
@page :right { @bottom-right-corner { ... /* right page numbers */ }}
@page :first { @bottom-right-corner { ... /* empty footer on 1st page */ }}

This will only produce an empty footer if the first page is a right
page. As noted in Section 3.6,

"Whether the first page of a document is ':left' or ':right' depends
on the major writing direction of the document and is outside the
scope of this document. "

Thus, the example either needs an @bottom-left-corner rule added to
the last declaration block or the comment needs to be changed, for
that rule will not produce an empty footer if the first page is a left
page.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: W3C CSS List
Subject: RE: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example

Your issue, shown below, has been given the number 39

&gt; 2)The last example in the example block is faulty:
&gt;
&gt; @page :left { @bottom-left-corner { ... /* left page numbers
&gt; */ }} @page :right { @bottom-right-corner { ... /* right page
&gt; numbers */ }} @page :first { @bottom-right-corner { ... /*
&gt; empty footer on 1st page */ }}
&gt;
&gt; This will only produce an empty footer if the first page is a
&gt; right page. As noted in Section 3.6,
&gt;
&gt; "Whether the first page of a document is ':left' or ':right'
&gt; depends on the major writing direction of the document and is
&gt; outside the scope of this document. "
&gt;
&gt; Thus, the example either needs an @bottom-left-corner rule
&gt; added to the last declaration block or the comment needs to
&gt; be changed, for that rule will not produce an empty footer if
&gt; the first page is a left page.
&gt;
&gt;

I plan to amend the specification say that the UA MUST use the
declarations of the :first pseudo-class, if it exists, rather than
either the :left or :right declarations

 -- Jim Bigelow</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: W3C CSS List
Subject: RE: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example

Ernest,

You wrote:
&gt; &gt; Thus, the example either needs an @bottom-left-corner rule
&gt; &gt; added to the last declaration block or the comment needs to
&gt; &gt; be changed, for that rule will not produce an empty footer if
&gt; &gt; the first page is a left page.
&gt; &gt;
&gt; &gt;
&gt; I plan to amend the specification say that the UA MUST use
&gt; the declarations of the :first pseudo-class, if it exists,
&gt; rather than either the :left or :right declarations
&gt;

I understand you point, now.  If the document's first page is left,
since the declarations in the :first pseudo-class do not override
those in the :left, there would be a page number on the first page.  I
will amend the example as you suggest.

@page :left { @bottom-left-corner { ... /* left page numbers */ }}
@page :right { @bottom-right-corner { ... /* right page numbers */ }}
@page :first { @bottom-right-corner { ... /* empty footer on 1st page */ }
		   @bottom-left-corner { ... } }

If you have any further comment on this topic, you have 7 days, until
14 February 2004, to respond.

 -- Jim Bigelow</pre>
<h2><a id="issue40" name="issue40">1.40  [CSS3-page]: Comments on pages media
</a></h2><p><b>PROBLEM ID: 40</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Rejected, proposed redesign header and footer areas not accepted.
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: Werner Donn� [werner.donne@re.be]
Sent: Thursday, September 25, 2003 3:14 AM
To: www-style@w3.org
Subject: [CSS3-page]: Comments on pages media


Hi,

These are some comments on the recent draft.

1) Printable and non-printable areas

The size of the non-printable area is user agent defined. In some
cases this will cause text to really stick to the edge of the
paper. It does in any case make the page layout less portable.

I think that the margin boxes should not be in the page margin. The
margin boxes should be region boxes and what is now the page-area
should be the body region. The page-area would then contain all the
regions and the margins would be around it.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Saturday, February 07, 2004 9:09 PM
To: werner.donne@re.be
Cc: W3C CSS List
Subject: RE: [css3-page]: Comments on pages media -- issues 40, 41, 32,
an d 43


Werner,

The following comments that you wrote in [1] have been assigned issue
numbers 40 - 43 and will be addressed in the coming days:

 -- Jim Bigelow, Editor

[1] http://lists.w3.org/Archives/Public/www-style/2003Sep/0114.html

Issue 40:
&gt; 1) Printable and non-printable areas
&gt;
&gt; The size of the non-printable area is user agent defined. In
&gt; some cases this will cause text to really stick to the edge
&gt; of the paper. It does in any case make the page layout less portable.
&gt;
&gt; I think that the margin boxes should not be in the page
&gt; margin. The margin boxes should be region boxes and what is
&gt; now the page-area should be the body region. The page-area
&gt; would then contain all the regions and the margins would be around it.
&gt;

</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: werner.donne@re.be
Cc: W3C CSS List
Subject: RE: [css3-page]: Comments on pages media -- issues 40,

Your issue, shown below, has been rejected by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt; 1) Printable and non-printable areas
&gt;
&gt; The size of the non-printable area is user agent defined. In
&gt; some cases this will cause text to really stick to the edge
&gt; of the paper. It does in any case make the page layout less
&gt; portable.
&gt;

The non-printable area is that part of the paper that a printer cannot
print on.  In effect, it creates minimum margin that cannot be
avoided. Since this non-printable area varies from printer to printer
it is the responsibility of the printer to adjust the content. The
specification says, "Printing devices MUST adjust the layout of the
document so that content is not lost. How this adjustment is
accomplished is device dependent within the constraints expressed
below in the sections Rendering page boxes that do not fit a page
sheet and Content outside the page box."

Authors can attempt to isolate their documents from changes in the
non-printable area by using a margin large enough to leave their
document unaffected.

&gt; I think that the margin boxes should not be in the page
&gt; margin. The margin boxes should be region boxes and what is
&gt; now the page-area should be the body region. The page-area
&gt; would then contain all the regions and the margins would be
&gt; around it.
&gt;

The net affect of you scheme seems to be the same as the current
scheme of margin boxes. Your scheme's page margin is the composite of
the outer margins of all the margin boxes in the current scheme. I
admit it is tedious to write declarations for all the margin boxes.
However, I don't think that few page designs will use all of the
margin boxes. Most page designs will probably only use three or four
margin boxes for things like page number, date, document name, and
author name.

The current scheme of margin boxes has a history and I have not heard
an alternate proposal yet with persuasive enough reasons to warrant a
change.

 -- Jim Bigelow, editor

</pre>
<h2><a id="issue41" name="issue41">1.41  [CSS3-page]: Comments on pages media
</a></h2><p><b>PROBLEM ID: 41</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Rejected, extension outside the scope of specification
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: Werner Donn� [werner.donne@re.be]
Sent: Thursday, September 25, 2003 3:14 AM
To: www-style@w3.org
Subject: [CSS3-page]: Comments on pages media


2) Media Queries

I'm not sure if expressing page layout in terms of a conditional page
size has so much added value. I assume this is for page sizes which
are set from outside by the user agent. One can cope with that using
relative values. The cases where this is not good enough are, in my
opinion, locale related. Wouldn't it therefore be more useful to
combine this with the pseudo class :lang for @page rules?

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Saturday, February 07, 2004 9:09 PM
To: werner.donne@re.be
Cc: W3C CSS List
Subject: RE: [css3-page]: Comments on pages media -- issues 40, 41, 32,
an d 43


Werner,

The following comments that you wrote in [1] have been assigned issue
numbers 40 - 43 and will be addressed in the coming days:
  -- Jim Bigelow, Editor

[1] http://lists.w3.org/Archives/Public/www-style/2003Sep/0114.html


Issue 41
&gt; 2) Media Queries
&gt;
&gt; I'm not sure if expressing page layout in terms of a
&gt; conditional page size has so much added value. I assume this
&gt; is for page sizes which are set from outside by the user
&gt; agent. One can cope with that using relative values. The
&gt; cases where this is not good enough are, in my opinion,
&gt; locale related. Wouldn't it therefore be more useful to
&gt; combine this with the pseudo class :lang for @page rules?
&gt;

</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'werner.donne@re.be'
Cc: W3C CSS List
Subject: RE: [css3-page]: Comments on pages media -- issues 41


Your issue, shown below, has been rejected by the editor.  If you have
any further comment on this topic, you have 7 days, until 14 February
2004, to respond.

&gt;
&gt; Issue 41
&gt; &gt; 2) Media Queries
&gt; &gt;
&gt; &gt; I'm not sure if expressing page layout in terms of a
&gt; &gt; conditional page size has so much added value. I assume this
&gt; &gt; is for page sizes which are set from outside by the user
&gt; &gt; agent. One can cope with that using relative values. The
&gt; &gt; cases where this is not good enough are, in my opinion,
&gt; &gt; locale related. Wouldn't it therefore be more useful to
&gt; &gt; combine this with the pseudo class :lang for @page rules?
&gt; &gt;
&gt;

Media Queries are design to work with style sheets that implement a
the graphic design of a page that may shift or change depending on the
capabilities of the UA.  A particular media query is, in effect, a
conditional statement that when true will instruct the UA to load and
process a style sheet. Extensions to the Media Query mechanism are
outside the scope of this document.

Style sheets that are intended to be effective in UA's having a
particular combination of capabilities can include the :lang()
pseudo-classes, attribute selectors and @page rules as appropriate for
a specific page design.

 -- Jim Bigelow, editor</pre>
<h2><a id="issue42" name="issue42">1.42  [CSS3-page]: Comments on pages media
</a></h2><p><b>PROBLEM ID: 42</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Accepted without changes
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: Werner Donn� [werner.donne@re.be]
Sent: Thursday, September 25, 2003 3:14 AM
To: www-style@w3.org
Subject: [CSS3-page]: Comments on pages media


3) Margin at-rules

It is not clear to me which are the properties that apply to these
rules. The examples seem to suggest that only the content property is
allowed. This is confirmed by the way the margin box sizes are
determined. As I understand it this is driven by the actual content of
the boxes. This is a bottom-up approach. Wouldn't it be useful to also
provide top-down constraints such as the width for top-boxes? How else
can one deal with situations where the pieces of text are somewhat
longer and might overlap?

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Saturday, February 07, 2004 9:09 PM
To: werner.donne@re.be
Cc: W3C CSS List
Subject: RE: [css3-page]: Comments on pages media -- issues 40, 41, 32,
an d 43


Werner,

The following comments that you wrote in [1] have been assigned issue
numbers 40 - 43 and will be addressed in the coming days:

 -- Jim Bigelow, Editor

[1] http://lists.w3.org/Archives/Public/www-style/2003Sep/0114.html


Issue 42
&gt; 3) Margin at-rules
&gt;
&gt; It is not clear to me which are the properties that apply to
&gt; these rules. The examples seem to suggest that only the
&gt; content property is allowed. This is confirmed by the way the
&gt; margin box sizes are determined. As I understand it this is
&gt; driven by the actual content of the boxes. This is a
&gt; bottom-up approach. Wouldn't it be useful to also provide
&gt; top-down constraints such as the width for top-boxes? How
&gt; else can one deal with situations where the pieces of text
&gt; are somewhat longer and might overlap?
&gt;

</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: 'werner.donne@re.be'
Cc: W3C CSS List
Subject: RE: [css3-page]: Comments on pages media -- issues 42

Your issue, shown below, has been accepted without changes to the
specification by the editor.  If you have any further comment on this
topic, you have 7 days, until 14 February 2004, to respond.

&gt; Issue 42
&gt; &gt; 3) Margin at-rules
&gt; &gt;
&gt; &gt; It is not clear to me which are the properties that apply to
&gt; &gt; these rules. The examples seem to suggest that only the
&gt; &gt; content property is allowed. This is confirmed by the way the
&gt; &gt; margin box sizes are determined. As I understand it this is
&gt; &gt; driven by the actual content of the boxes. This is a
&gt; &gt; bottom-up approach. Wouldn't it be useful to also provide
&gt; &gt; top-down constraints such as the width for top-boxes? How
&gt; &gt; else can one deal with situations where the pieces of text
&gt; &gt; are somewhat longer and might overlap?
&gt; &gt;
&gt;

The specification does not make any restrictions on the properties
that can be used within the margin box context. The content property
is suggested as a way that UA's may derive the maximum size allocated
to a given box in proportion to other boxes. However, the UA is given
complete freedom to calculate the maximum size of the margin boxes
with the following constraints

1. the margin box cannot spill out of the margin

2. the top center, bottom center, left middle, and right middle boxes
   must be centered.

The author may use values of the height and width properties to size
the boxes but they will be constrained by the UA's enforcement of the
two constraints shown above.

 -- Jim Bigelow, editor</pre>
<h2><a id="issue43" name="issue43">1.43  [CSS3-page]: Comments on pages media
</a></h2><p><b>PROBLEM ID: 43</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Rejected, no need for new formatting property, existing properties can be used
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: Werner Donn� [werner.donne@re.be]
Sent: Thursday, September 25, 2003 3:14 AM
To: www-style@w3.org
Subject: [CSS3-page]: Comments on pages media


4) Populating margin boxes

The string-set property, combined with the page-policy, can be used to
provide content for the margin boxes coming from the document
itself. The content function, which is available in the string-set
property, is however not specified. My understanding is that it can
capture text from within an element. This is not enough for the margin
boxes, because then it is impossible to say how this text should layed
out in the margin boxes. It is also not an option to take over the
properties that apply to the text which was captured, because very
often the style is different in the running headers and footers from
the style in the document itself.

I propose to introduce the formatted-set property. It could be applied
to any element. The effect would be that it would be set with the
formatted result of that element, even if its display type is "none",
which would be the case in practice if the destination is a margin
box. In the latter case the element would not be visible in the
document flow, but would contribute to formatting elsewhere. The
"formatted" function would produce the formatted result, just like the
string function produces the captured string. In this proposal the
string-set property and string function would remain very useful to
populate these special elements.

</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
From: www-style-request@w3.org on behalf of BIGELOW,JIM (HP-Boise,ex1)
[jim.bigelow@hp.com]
Sent: Saturday, February 07, 2004 9:09 PM
To: werner.donne@re.be
Cc: W3C CSS List
Subject: RE: [css3-page]: Comments on pages media -- issues 40, 41, 32,
an d 43


Werner,

The following comments that you wrote in [1] have been assigned issue
numbers 40 - 43 and will be addressed in the coming days:
  -- Jim Bigelow, Editor

[1] http://lists.w3.org/Archives/Public/www-style/2003Sep/0114.html


Issue 43
&gt; 4) Populating margin boxes
&gt;
&gt; The string-set property, combined with the page-policy, can
&gt; be used to provide content for the margin boxes coming from
&gt; the document itself. The content function, which is available
&gt; in the string-set property, is however not specified. My
&gt; understanding is that it can capture text from within an
&gt; element. This is not enough for the margin boxes, because
&gt; then it is impossible to say how this text should layed out
&gt; in the margin boxes. It is also not an option to take over
&gt; the properties that apply to the text which was captured,
&gt; because very often the style is different in the running
&gt; headers and footers from the style in the document itself.
&gt;
&gt; I propose to introduce the formatted-set property. It could
&gt; be applied to any element. The effect would be that it would
&gt; be set with the formatted result of that element, even if its
&gt; display type is "none", which would be the case in practice
&gt; if the destination is a margin box. In the latter case the
&gt; element would not be visible in the document flow, but would
&gt; contribute to formatting elsewhere. The "formatted" function
&gt; would produce the formatted result, just like the string
&gt; function produces the captured string. In this proposal the
&gt; string-set property and string function would remain very
&gt; useful to populate these special elements.
&gt;
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
From: BIGELOW,JIM (HP-Boise,ex1)
Sent: Saturday, February 14, 2004 5:00 PM
To: 'werner.donne@re.be'
Cc: 'W3C CSS List'
Subject: RE: [css3-page]: Comments on pages media -- issue 43

Werner,

Your issue (#43 from [1]) shown below, has not been accepted by the
editor. There are no restrictions on the properties that can be used
within the margin context and therefore, no need for a new property to
apply formatting to the content on a margin box. Please see [2] for an
example usage.

If you have more comments on this issue, you have seven days, until
February 21, 2004, to reply.

 -- Jim Bigelow, editor

[2] http://www.w3.org/TR/css3-page/#page-based-counters

&gt;
&gt; [1] http://lists.w3.org/Archives/Public/www-style/2003Sep/0114.html
&gt;
&gt; Issue 43
&gt; &gt; 4) Populating margin boxes
&gt; &gt;
&gt; &gt; The string-set property, combined with the page-policy, can
&gt; &gt; be used to provide content for the margin boxes coming from
&gt; &gt; the document itself. The content function, which is available
&gt; &gt; in the string-set property, is however not specified. My
&gt; &gt; understanding is that it can capture text from within an
&gt; &gt; element. This is not enough for the margin boxes, because
&gt; &gt; then it is impossible to say how this text should layed out
&gt; &gt; in the margin boxes. It is also not an option to take over
&gt; &gt; the properties that apply to the text which was captured,
&gt; &gt; because very often the style is different in the running
&gt; &gt; headers and footers from the style in the document itself.
&gt; &gt;
&gt; &gt; I propose to introduce the formatted-set property. It could
&gt; &gt; be applied to any element. The effect would be that it would
&gt; &gt; be set with the formatted result of that element, even if its
&gt; &gt; display type is "none", which would be the case in practice
&gt; &gt; if the destination is a margin box. In the latter case the
&gt; &gt; element would not be visible in the document flow, but would
&gt; &gt; contribute to formatting elsewhere. The "formatted" function
&gt; &gt; would produce the formatted result, just like the string
&gt; &gt; function produces the captured string. In this proposal the
&gt; &gt; string-set property and string function would remain very
&gt; &gt; useful to populate these special elements.
&gt; &gt;
&gt;
</pre>
<h2><a id="issue44" name="issue44">1.44  [css3-page] Is auto a page identifier or not?
</a></h2><p><b>PROBLEM ID: 44</b></p>
<p><b>STATE: closed
<br />RESOLUTION:Rejected since auto is a special identifier
<br />USER POSITION:
Agree
</b></p>
<p><b>

ORIGINAL MESSAGE:

</b></p><pre>
From: www-style-request@w3.org on behalf of Ernest Cline
[ernestcline@mindspring.com]
Sent: Monday, February 09, 2004 1:31 PM
To: W3C CSS List
Subject: [css3-page] Is auto a page identifier or not?


One more thought.

In the 'page' property is the value of "auto" to be treated as
identifier or not?  In other words, given the following:

@page auto { /*A set of rules for unnamed pages */}

Will it apply as the comment indicates or will it not apply
to anything since "auto" is not an identifier?

If it is an identifier, might it not be best to change 5.2
so that:

Name: 	page
Value: 	auto | &lt;identifier&gt;
Initial: 	auto

becomes:

Name: 	page
Value: 	&lt;identifier&gt;
Initial: 	auto

?

Personally, I think it would be best if "auto" here was
treated the same as any other identifier.   This is
because CSS2 and the WD  call for a  forced page break
whenever two adjacent elements have different values
of 'page'.

 If it weren't for a forced page break in CSS 2,
it would be worth considering  to allow placing both
of the paragraphs in the following HTML fragment
on the same page..

&lt;div&gt;
&lt;p style="page:landscape"&gt;...&lt;/p&gt;
&lt;p style="page:auto"&gt;...&lt;/p&gt;
&lt;/div&gt;

Of course, even if a page break wasn't forced between the two
paragraphs by the different values of the 'page' property, a UA might
still decide to choose to break there for any number of reasons
including that it doesn't want to go to the bother of trying to decide
whether the second paragraph could fit with the first.  However, even
if this behavior be desirable, it would be a departure from CSS2, so I
can't see making that change.  Thus it probably would be best if
"auto" was treated as an ordinary identifier for the 'page' property
that just happens to be the initial value for 'page'.

Ernest Cline
ernestcline@mindspring.com


</pre><P><b>

ACKNOWLEDGED:

</b></p><pre>
To: ernestcline@mindspring.com
Subject: RE: [css3-page]Isssue 44: Is auto a page identifier or not?

You issue has been given the number 44

&gt;
&gt; In the 'page' property is the value of "auto" to be treated
&gt; as identifier or not?  In other words, given the following:
&gt;
&gt; @page auto { /*A set of rules for unnamed pages */}
&gt;
&gt; Will it apply as the comment indicates or will it not apply
&gt; to anything since "auto" is not an identifier?
&gt;
&gt; If it is an identifier, might it not be best to change 5.2
&gt; so that:
&gt;
&gt; Name: 	page
&gt; Value: 	auto | &lt;identifier&gt;
&gt; Initial: 	auto
&gt;
&gt; becomes:
&gt;
&gt; Name: 	page
&gt; Value: 	&lt;identifier&gt;
&gt; Initial: 	auto
&gt;
&gt; ?
&gt;
&gt; Personally, I think it would be best if "auto" here was
&gt; treated the same as any other identifier.   This is
&gt; because CSS2 and the WD  call for a  forced page break
&gt; whenever two adjacent elements have different values
&gt; of 'page'.
&gt;
&gt;  If it weren't for a forced page break in CSS 2,
&gt; it would be worth considering  to allow placing both
&gt; of the paragraphs in the following HTML fragment
&gt; on the same page..
&gt;
&gt; &lt;div&gt;
&gt; &lt;p style="page:landscape"&gt;...&lt;/p&gt;
&gt; &lt;p style="page:auto"&gt;...&lt;/p&gt;
&gt; &lt;/div&gt;
&gt;
&gt; Of course, even if a page break wasn't forced between the
&gt; two paragraphs by the different values of the 'page'
&gt; property, a UA might still decide to choose to break there
&gt; for any number of reasons including that it doesn't want to
&gt; go to the bother of trying to decide whether the second
&gt; paragraph could fit with the first.  However, even if this
&gt; behavior be desirable, it would be a departure from CSS2, so
&gt; I can't see making that change.  Thus it probably would be
&gt; best if "auto" was treated as an ordinary identifier for the
&gt; 'page' property that just happens to be the initial value for 'page'.
&gt;

 -- Jim Bigelow, editor </pre>
<p><b>

   FOLLOWUP 01:

   </b></p><pre>
From: Ernest Cline [ernestcline@mindspring.com]
Sent: Wednesday, February 11, 2004 8:28 AM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: W3C CSS List
Subject: RE: [css3-page] Is auto a page identifier or not?


&gt; [Original Message]
&gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;

Whoa there!  I can see the reason (altho I disagree with it) for
rejecting "auto" as an identifier, but not ALL keywords.  Whether
something that fits the production for an identifier happens to be a
keyword will depend upon what portions of CSS it implements. Do you
really want a standard that would require an as yet undefined keyword
from a future CSS recommendation to be invalid?  That is sure to lead
to problems with interoperability.

&gt; Your issue (#44) shown below has been rejected.  There are many uses
&gt; of "auto" in the CSS specification as a unique keyword that assumes
&gt; specific values and meanings that are unique to the property. So I
&gt; don't think it is
&gt; right to, in this instance, say it is an identifier.  However, it
&gt; keeping with the way the auto assumes property specific means, when
&gt; used as a keyword it could take on the meaning of the unnamed page
&gt; context when used with the page property.  In keeping with "auto"
&gt; being a polymorphic keyword
&gt; and not an identifier "@page auto" should be a syntax error in the
&gt; same way
&gt; that "@page table-row" should be an error since auto or table-row are
&gt; keywords and not identifiers.
&gt;
&gt; If you have further comment on this issue, you have seven days, until
&gt; Feb. 17, 2004 to reply.
&gt;
&gt;  -- Jim Bigelow, editor
&gt;
&gt; Your issue:
&gt; &gt; In the 'page' property is the value of "auto" to be treated
&gt; &gt; as identifier or not?

</pre>
<p><b>

   FOLLOWUP 02:

   </b></p><pre>
To: ernestcline@mindspring.com
Cc: W3C CSS List
Subject: RE: [css3-page] Is auto a page identifier or not?

Ernest wrote:
&gt;
&gt; Whoa there!  I can see the reason (altho I disagree with it)
&gt; for rejecting "auto" as an identifier, but not ALL keywords.
&gt; Whether something that fits the production for an identifier
&gt; happens to be a keyword will depend upon what portions of CSS
&gt; it implements. Do you really want a standard that would
&gt; require an as yet undefined keyword from a future CSS
&gt; recommendation to be invalid?  That is sure to lead to
&gt; problems with interoperability.
&gt;
&gt; &gt; [Original Message]
&gt; &gt; From: BIGELOW,JIM (HP-Boise,ex1) &lt;jim.bigelow@hp.com&gt;
&gt; &gt; ...  In keeping with "auto"
&gt; &gt; being a polymorphic keyword
&gt; &gt; and not an identifier "@page auto" should be a syntax error in the
&gt; &gt; same  way that "@page table-row" should be an error since auto or
&gt; &gt; table-row are keywords and not identifiers.
&gt; &gt;

From a grammar/syntax view keywords are not identifiers--they're
separate tokens. The grammar of the @page rule says that page names
are identifiers not keywords or identifiers.  I'm sensitive to the
problem of foreseeing future keywords.  Perhaps I'm being too strict
and violating the CSS resilience to new constructs.

I'm certainly willing to be quiet about what should happen if an @page
statement contains a keyword, e.g., @page table-row or @page display,
etc.

-- Jim</pre>
<p><b>

   FOLLOWUP 03:

   </b></p><pre>
From: www-style-request@w3.org on behalf of L. David Baron
[dbaron@dbaron.org]
Sent: Wednesday, February 11, 2004 12:09 PM
To: www-style@w3.org
Subject: Re: [css3-page] Is auto a page identifier or not?


On Wednesday 2004-02-11 10:50 -0500, BIGELOW,JIM (HP-Boise,ex1) wrote:
&gt; From a grammar/syntax view keywords are not identifiers--they're
&gt; separate tokens. The grammar of the @page rule says that page names
&gt; are identifiers

Not as far as I know.  Keywords are identifiers -- they're just
identifiers that are known in advance and have special meaning for
some properties.

Anything else would be a complete disaster for forward-compatibility.

-David

--
L. David Baron                                &lt;URL: http://dbaron.org/ &gt;
</pre>
<p><b>

   FOLLOWUP 04:

   </b></p><pre>
To: www-style@w3.org
Subject: RE: [css3-page] Is auto a page identifier or not?

L. David Baron wrote:

&gt; Not as far as I know.  Keywords are identifiers -- they're
&gt; just identifiers that are known in advance and have special
&gt; meaning for some properties.
&gt;
&gt; Anything else would be a complete disaster for forward-compatibility.
&gt;

Okay, so the page name in the @page is an identifier and auto is an
identifier. I still think it the description of the @page rule should
remain as it is now and not as Ernest suggested:

Ernest wrote:
&gt; [ current description ]
&gt; Name: 	page
&gt; Value: 	auto | &lt;identifier&gt;
&gt; Initial: 	auto
&gt;
&gt; becomes:
&gt;
&gt; Name: 	page
&gt; Value: 	&lt;identifier&gt;
&gt; Initial: 	auto

Apparently auto is a polymorphic (I had to slip that word it)
keyword/identifier that, as you suggest is a synonym for the unnamed
page context.  This allows you to say "page: auto" instead of "page: "

It would appear that

1. any well-formed identifier can be used a page name.

2. the identifier auto means when used in the page property the
   unknown page name.

3. you can say something like "@page display" and "page: display"
   without any ill effects

So where does that leave the original issue?
Ernest wrote:

&gt; @page auto { /*A set of rules for unnamed pages */}
&gt;
&gt; Will it apply as the comment indicates or will it not apply
&gt; to anything since "auto" is not an identifier?

The answer depends on how auto is interpreted in the page command.
@page auto defines a page named auto that cannot be referenced since
page: auto is the unnamed page.

We could say that auto, when used in the context of "@page auto"
references the unnamed page, or we could say it references the page
"auto" that cannot be otherwise used--this seems wasteful and
unusable.

I vote for making "@page auto" reference the unnamed page.

 -- Jim Bigelow</pre>
<p><b>

   FOLLOWUP 05:

   </b></p><pre>
From: Boris Zbarsky [bzbarsky@MIT.EDU]
Sent: Wednesday, February 11, 2004 6:29 PM
To: BIGELOW,JIM (HP-Boise,ex1)
Cc: www-style@w3.org
Subject: Re: [css3-page] Is auto a page identifier or not?

BIGELOW,JIM (HP-Boise,ex1) wrote:
&gt; Okay, so the page name in the @page is an identifier and auto is an
&gt; identifier. I still think it the description of the @page rule should
&gt; remain as it is now and not as Ernest suggested:
 &gt;
&gt;&gt;Value: 	&lt;identifier&gt;
&gt;&gt;Initial: 	auto

So if in the future you introduce a meaningful (in that it has special
semantics) identifier other than "auto" here, pages that use that as a
page name break?

Is there a reason not to just use strings for page names and auto be an
identifier?  That is:

page:  auto | &lt;string&gt;

That would be much more future-proof.

-Boris
</pre>
<p><b>

   FOLLOWUP 06:

   </b></p><pre>
From: Ernest Cline [ernestcline@mindspring.com]
Sent: Wednesday, February 11, 2004 7:54 PM
To: Boris Zbarsky; BIGELOW,JIM (HP-Boise,ex1)
Cc: www-style@w3.org; Michael Day
Subject: Re: [css3-page] Is auto a page identifier or not?


&gt; [Original Message]
&gt; From: Boris Zbarsky &lt;bzbarsky@MIT.EDU&gt;
&gt;
&gt; So if in the future you introduce a meaningful (in that it has special
&gt; semantics) identifier other than "auto" here, pages that use that as a
&gt; page name break?
&gt;
&gt; Is there a reason not to just use strings for page names and auto be
&gt; an
&gt; identifier?  That is:
&gt;
&gt; page:  auto | &lt;string&gt;
&gt;
&gt; That would be much more future-proof.

Agreed, but the 'page' property while not part of CSS2.1 is part of
CSS2. If the list of allowable values were switched as Boris suggested
we would need to do one of the following

1) Use a kludge like that used with the 'font-family' property.
2) Deprecate page and use a different property name such as 'page-name'.
3) Make a break with CSS2.

I don't like kludges.

Deprecating 'page' won't affect any of the major browsers AFAIK, but
there is at least one UA that is using 'page' already.

Ditto for making a break with CSS 2.

If there wasn't at least one implementation, I could see doing as
Boris suggests and change &lt;identifier&gt; to something else, but there is
one. Unless you can think of a better reason than there might be
another keyword that would be useful without a suggestion of what it
might be, I think it would be best to keep 'page' as either "auto |
&lt;identifier&gt;" or "&lt;identifier&gt;" for now and reserve option 2 above for
when someone can come up with a good keyword. that only makes sense
for the 'page' property.


</pre>
<p><b>

   FOLLOWUP 07:

   </b></p><pre>
From: www-style-request@w3.org on behalf of Boris Zbarsky
[bzbarsky@MIT.EDU]
Sent: Wednesday, February 11, 2004 8:49 PM
To: ernestcline@mindspring.com
Cc: www-style@w3.org
Subject: Re: [css3-page] Is auto a page identifier or not?


Ernest Cline wrote:
&gt; Unless you can think of a better reason than there might be another
&gt; keyword that would be useful without a suggestion of what it might be,

Not offhand, but I've now spent a grand total of about 10 minutes
looking at the CSS2 spec's section on paged content.... perhaps someone
who has more experience with the problem space the spec is targeting
would be someone to ask.

I just pointed out that given that "auto" is in fact an identifier,
"auto | &lt;identifier&gt;" is somewhat meaningless.  It could be simplified
to "&lt;identifier&gt;", as someone suggested, with default value remaining
and the normative text explaining that the "auto" identifier is magic
for this particular property in a particular way remaining.

It's too bad that CSS2 completely shut out all future possibilities of
extension here.

-Boris
</pre>
<p><b>

   RESOLUTION:

   </b></p><pre>
To: ernestcline@mindspring.com
Cc: W3C CSS List
Subject: RE: [css3-page] Is auto a page identifier or not?

Ernest,

Your issue (#44) shown below has been rejected.  There are many uses
of "auto" in the CSS specification as a unique keyword that assumes
specific values and meanings that are unique to the property. So I
don't think it is right to, in this instance, say it is an identifier.
However, it keeping with the way the auto assumes property specific
means, when used as a keyword it could take on the meaning of the
unnamed page context when used with the page property.  In keeping
with "auto" being a polymorphic keyword and not an identifier "@page
auto" should be a syntax error in the same way that "@page table-row"
should be an error since auto or table-row are keywords and not
identifiers.

If you have further comment on this issue, you have seven days, until
Feb. 17, 2004 to reply.

 -- Jim Bigelow, editor

Your issue:
&gt; In the 'page' property is the value of "auto" to be treated
&gt; as identifier or not?  In other words, given the following:
&gt;
&gt; @page auto { /*A set of rules for unnamed pages */}
&gt;
&gt; Will it apply as the comment indicates or will it not apply
&gt; to anything since "auto" is not an identifier?
&gt;
&gt; If it is an identifier, might it not be best to change 5.2
&gt; so that:
&gt;
&gt; Name: 	page
&gt; Value: 	auto | &lt;identifier&gt;
&gt; Initial: 	auto
&gt;
&gt; becomes:
&gt;
&gt; Name: 	page
&gt; Value: 	&lt;identifier&gt;
&gt; Initial: 	auto
&gt;
</pre>
</body>
</html>