# CSS3 Paged Media Module Last Call Working Draft review Disposition of Comments

## 20 February 2004

This version:
  http://www.w3.org/Style/Group/css3-src/css3-page/lc-doc-20040215.htm
Editors:
  Jim Bigelow, Hewlett-Packard Co.

Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

## Abstract

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.

## Status of this document

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.

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.

This document is a product of the W3C's CSS Working Group as part of the Style activity (see summary). 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 W3C membership.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

## Table of Contents

# 1. CSS3 Page Media Module

## 1.01 [1] Section 1:

PROBLEM ID: 01

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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.
    >
    > The link for "Generated content module" should be to
    > http://www.w3.org/TR/css3-content and not to a specific working draft.
    >

    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

RESOLUTION:

    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.

    >
    > 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.
    >
    > The link for "Generated content module" should be to
    > http://www.w3.org/TR/css3-content and not to a specific working draft.
    >

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

       -- Jim Bigelow, Editor

## 1.02 [2] Section 1:

PROBLEM ID: 02

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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".

ACKNOWLEDGED:

    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.
    >
    > In the item "the Generated content module which this module extents"
    > "extents" should be "extends".
    >

    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

RESOLUTION:

    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.

    >
    >
    > 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.
    >
    > In the item "the Generated content module which this module extents"
    > "extents" should be "extends".
    >

       -- Jim Bigelow, Editor

## 1.03 [3] Section 2:

PROBLEM ID: 03

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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.
    >
    > 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.
    >

    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

RESOLUTION:

    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.

    >
    > 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.
    >

       -- Jim Bigelow, Editor

## 1.04 [4] Section 2:

PROBLEM ID: 04

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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".

ACKNOWLEDGED:

    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.
    >
    > 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".
    >

    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

RESOLUTION:

    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.

    >
    > 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".
    >
       -- Jim Bigelow, Editor

## 1.05 [5] Section 3.1:

PROBLEM ID: 05

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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.
    >
    > 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.
    >

    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

RESOLUTION:

    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.

    >
    > 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.
    >

       -- Jim Bigelow, Editor

## 1.06 [6] Section 3.1 "Page Box":

PROBLEM ID: 06

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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/ .

ACKNOWLEDGED:

    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.
    >
    > 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/ .
    >

    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

RESOLUTION:

    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.

    >
    > 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/ .
    >

       -- Jim Bigelow, Editor

## 1.07 [7] Section 3.1 "Page Box":

PROBLEM ID: 07

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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".

ACKNOWLEDGED:

    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.
    >
    > In the clause "there are more complex uses cases", the word "uses"
    > should be "use".
    >

    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

RESOLUTION:

    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.

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

       -- Jim Bigelow, Editor

## 1.08 [8] Section 3.1 "Margin box"

PROBLEM ID: 08

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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?

ACKNOWLEDGED:

    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.
    >
    > 'top' and 'bottom' are mentioned as being present for compatibility
    > with previous versions of the document.  Could references for those be
    > provided?
    >

    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

RESOLUTION:

    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.

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

       -- Jim Bigelow, Editor

## 1.09 [9] Section 3.1 "Margin box"

PROBLEM ID: 09

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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?

ACKNOWLEDGED:

    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.
    >
    > Was having 'left-center', 'left-top', etc. rejected because they were
    > too kitchen sinkish, or were they not considered?
    >

    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

FOLLOWUP 01:

    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.
    >
    > Was having 'left-center', 'left-top', etc. rejected because they were
    > too kitchen sinkish, or were they not considered?
    >

    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

FOLLOWUP 02:

    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"

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    > To: <www-style@w3.org>
    > Date: 1/7/2004 7:57:41 PM
    > 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

    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.

FOLLOWUP 03:

    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:
    > > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    > > I didn't consider left-center, left-top, etc.. What is your
    > > suggestion?
    >
    > 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.
    >

    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

FOLLOWUP 04:

    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"

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    >
    > 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.

    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.

RESOLUTION:

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

    Ernest wrote:
    >
    > [define three left margin boxes] @left-top',
    > '@left-center', and '@left-bottom'. ...
    >
    > 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 ra[n]ges 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.  ... @left and @right
    > could be simply dropped instead of deprecated.
    >

    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

## 1.10 [10] Section 3.1 "Margin box"

PROBLEM ID: 10

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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 <th>'s.

ACKNOWLEDGED:

    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.
    >
    > The table of margin box definitions should be changed either so that
    > it is a definition list, or the first column contains <th>'s.
    >

    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

RESOLUTION:

    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.

    >
    > The table of margin box definitions should be changed either so that
    > it is a definition list, or the first column contains <th>'s.
    >
       -- Jim Bigelow, Editor

## 1.11 [11] Section 3.1 diagram

PROBLEM ID: 11

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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 <note-box> area with no definition or reference
    given in this section.

ACKNOWLEDGED:

    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.
    >
    > The diagram contains a <note-box> area with no definition or reference
    > given in this section.
    >

    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

RESOLUTION:

    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.

    >
    > The diagram contains a <note-box> area with no definition or reference
    > given in this section.
    >

       -- Jim Bigelow, Editor

## 1.12 [12] Section 3.1 diagram

PROBLEM ID: 12

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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.
    >
    > The pointer for "top box" should be moved so that the text is not
    > obscured by the vertical lines.
    >

    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

RESOLUTION:

    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.

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

       -- Jim Bigelow, Editor

## 1.13 [13] Section 3.1 diagram

PROBLEM ID: 13

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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 <page-box>
    border and the <page-box> padding.  Those not familiar with the CSS
    box properties could conclude from this diagram that they are supposed
    to be the same thing.

ACKNOWLEDGED:

    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.
    >
    > The diagram contains no visual distinction between the <page-box>
    > border and the <page-box> padding.  Those not familiar with the CSS
    > box properties could conclude from this diagram that they are supposed
    > to be the same thing.
    >

    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

RESOLUTION:

    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.

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

       -- Jim Bigelow, Editor

## 1.14 [14] Section 3.2

PROBLEM ID: 14

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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.
    >
    > 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.
    >

    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

FOLLOWUP 01:

    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:
    >
    > 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.

    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.
    >
    > 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.
    >

    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

FOLLOWUP 02:

    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

    > -----Original Message-----
    > From: www-style-request@w3.org
    > [mailto:www-style-request@w3.org] On Behalf Of Ernest Cline
    > 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
    >
    >
    >
    >
    >
    >
    > > [Original Message]
    > > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    > > To: <ernestcline@mindspring.com>
    > > Cc: <www-style@w3.org>
    > > Date: 2/8/2004 2:43:04 PM
    > > 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.
    > >
    > > >
    > > > 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 pseudo-classes, but the
    > > > explanatory material should be rewritten so as to be
    > supportive of
    > > > Japanese binding.
    > > >
    > >
    > > 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.
    >
    > 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.
    >
    >

RESOLUTION:

    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.

    >
    > 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.
    >

    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.

RESOLUTION:

    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

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    > To: <ernestcline@mindspring.com>
    > Cc: <www-style@w3.org>
    > Date: 2/8/2004 2:43:04 PM
    > 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.
    >
    > >
    > > 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 pseudo-classes, but the
    > > explanatory material should be rewritten so as to be supportive of
    > > Japanese binding.
    > >
    >
    > 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.

    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.

## 1.15 [15] Section 3.2 "Back side"

PROBLEM ID: 15

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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".

ACKNOWLEDGED:

    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.
    >
    > 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".
    >

    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

RESOLUTION:

    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.

    >
    > 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".
    >

       -- Jim Bigelow, Editor

## 1.16 [16] Section 3.2 "First page"

PROBLEM ID: 16

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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".

ACKNOWLEDGED:

    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.
    >
    > 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".
    >

    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

RESOLUTION:

    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.

    >
    > 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".
    >

       -- Jim Bigelow, Editor

## 1.17 [17] Section 3.2 "Left page"

PROBLEM ID: 17

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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.
    >
    > 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.
    >

    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

RESOLUTION:

    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.

    >
    > 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.
    >

       -- Jim Bigelow, Editor

## 1.18 [18] Section 3.2 "Right page"

PROBLEM ID: 18

STATE: closed
RESOLUTION:Accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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.
    >
    > 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.
    >

    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

RESOLUTION:

    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.

    >
    > 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.
    >

       -- Jim Bigelow, Editor

## 1.19 [19] Section 3.3

PROBLEM ID: 19

STATE: closed
RESOLUTION:accepted, spec updated
USER POSITION: Agree

ORIGINAL MESSAGE:

    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".

ACKNOWLEDGED:

    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.
    >
    > In the sentence "Different parts of the world uses different paper
    > sizes." the verb "uses" should be in the singular form, "use".
    >

    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

RESOLUTION:

    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.

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

       -- Jim Bigelow, Editor

## 1.20 [20] Section 3.3.1 Example

PROBLEM ID: 20

STATE: closed
RESOLUTION:accepted, spec updated.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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.
    >
    > As Lachlan Hunt has already pointed out, the "cm"s for the A4 paper
    > size need to be changed to "mm"s.
    >

    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

RESOLUTION:

    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.

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

       -- Jim Bigelow, Editor

## 1.21 [21] Section 3.3.2

PROBLEM ID: 21

STATE: closed
RESOLUTION:duplicate of #36
USER POSITION: Agree

ORIGINAL MESSAGE:

    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:
    <country-code> "-" <name> Thus, we could have "us-letter" "ca-p4" or
    "ja-b4" if including keywords for national standard paper sizes be
    deemed necessary.

ACKNOWLEDGED:

    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.
    >
    > 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:
    > <country-code> "-" <name> Thus, we could have "us-letter" "ca-p4" or
    > "ja-b4" if including keywords for national standard paper sizes be
    > deemed necessary.
    >

    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

FOLLOWUP 01:

    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

    > -----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 21 -- [21] Section 3.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.htm
    l

    Your issue, shown below, has been assigned the number 21.
    >
    > 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:
    > <country-code> "-" <name> Thus, we could have "us-letter" "ca-p4" or
    > "ja-b4" if including keywords for national standard paper sizes be
    > deemed necessary.
    >

    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

FOLLOWUP 02:

    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.

    > [Original Message]
    > From: Ernest Cline <ernestcline@mindspring.com>
    > To: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    > Date: 1/7/2004 11:21:43 PM
    > Subject: RE: [css3-page] LCWD issue 21 --  [21] Section 3.3.2
    >
    >
    >
    >
    > > [Original Message]
    > > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    > > To: <www-style@w3.org>; <ernestcline@mindspring.com>
    > > Date: 1/7/2004 8:19:51 PM
    > > 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
    >
    > The worry about size and bounds could also be said to apply to
    > MIME types and languages.  In this case, since there already exists
    > an organization which is defining labels for paper sizes and allows
    > free access to those labels, why not just go ahead and use them?
    >
    > If you are worried about overexactness or name length, that standard
    > allows the size information to be dropped and to use only the
    > class-name and the size-name.  (Given the possibility of confusion
    > between the ISO B# sizes and the JIS B# sizes, I would not recommend
    > the allowed usage of just size name.) So, we could have iso_b4 or
    > na_letter or even om_juuro-ku-kai and let the UA decide which sizes it
    > can or will support.
    >
    >  Add in support for the self-describing names and then by using names
    > such as custom_pre-shredded_1x297mm the standard could support custom
    > page sizes without having to use a <length> unit that is different
    > from any other usage of <length> in the standard. Having  exceptions
    > to standard values is not a good idea.  Handling custom sizes this way
    > allows the standard to avoid the use of  em and ex and how often will
    > someone really want to specify a paper size in px or pt?
    >
    > For a non-technical user, they would be able to specify just
    > "na_letter" or "na_legal" or "iso_a4" for the common sizes, while
    > technical users would probably use the full descriptive names for the
    > uncommonly used paper sizes assuming that they bother to write
    > specific rules for them, while increasing the chance that the UA would
    > be able to understand what they mean.  It might be worth including
    > required support for certain common sizes such as "na_letter",
    > "na_legal", "na_tabloid", "iso_a4", etc. But I don't think it is
    > essential.  If a UA supports printing to a common paper size it will
    > almost certainly be able to understand the short form of the name,
    > while a user who wishes to use an unusual paper size will almost
    > certainly be aware that it would be a good idea to include the
    > official dimensions.

RESOLUTION:

    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.

    >
    > 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:
    > <country-code> "-" <name> Thus, we could have "us-letter" "ca-p4" or
    > "ja-b4" if including keywords for national standard paper sizes be
    > deemed necessary.
    >

       -- Jim Bigelow, Editor

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

## 1.22 [22] Section 3.3.2

PROBLEM ID: 22

STATE: closed
RESOLUTION:accepted, spec updated.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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 <length>
    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.

ACKNOWLEDGED:

    To: www-style@w3.org, ernestcline@mindspring.com
    Subject: [css3-page] LCWD issue 22 --  [22] Section 3.3.2 <length>
    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.
    >
    > 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.
    >

    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

FOLLOWUP 01:

    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 <length>

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    >
    > You issue (#22) shown below has been rejected.
    >
    > >
    > > 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.
    >
    > 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.

    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 <html>)
    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

FOLLOWUP 02:

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

    Ernest wrote [1]:
    > ... 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?"

    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.

FOLLOWUP 03:

    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 <length>

    > 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.

    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.

FOLLOWUP 04:

    To: Boris Zbarsky
    Cc: W3C CSS List
    Subject: RE: [css3-page] LCWD issue 22 -- [22] Section 3.3.2 <length>

    Boris wrote:
    > 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).
    >
     Thank you, I stand corrected.
      - Jim

FOLLOWUP 05:

    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 <length>

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    > To: <ernestcline@mindspring.com>
    > Cc: W3C CSS List <www-style@w3.org>
    > Date: 2/17/2004 3:23:01 PM
    > Subject: RE: [css3-page] LCWD issue 22 --  [22] Section 3.3.2 <length>
    >
    >
    > Ernest wrote [1]:
    > > ... 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?"
    >
    > 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.

    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.

    > 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.

    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".

    > 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.

    The main benefit is actually to an implementer of a UA, in that the
    definition of <length> 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.

    > 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.

    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.

    > [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.

FOLLOWUP 06:

    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 <length>

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    > To: Boris Zbarsky <bzbarsky@MIT.EDU>
    >
    > Boris wrote:
    > > 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).
    >
    >  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.

FOLLOWUP 07:

    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 <length>

    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 <length>

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    > To: <ernestcline@mindspring.com>
    > Cc: W3C CSS List <www-style@w3.org>
    > Date: 2/17/2004 3:23:01 PM
    > Subject: RE: [css3-page] LCWD issue 22 --  [22] Section 3.3.2 <length>
    >
    >
    > Ernest wrote [1]:
    > > ... 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?"
    >
    > 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.

    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.

    > 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.

    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".

    > 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.

    The main benefit is actually to an implementer of a UA, in that the
    definition of <length> 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.

    > 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.

    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.

    > [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.

FOLLOWUP 08:

    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
    <length>

    On Tue, 17 Feb 2004, BIGELOW,JIM (HP-Boise,ex1) wrote:
    >
    > 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.

    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/                         `._.-(,_..'--(,_..'`-.;.'

FOLLOWUP 09:

    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
    <length>

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

    > 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.

    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

FOLLOWUP 10:

    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
    <length>

    Bert wrote:
    > On Tue, 17 Feb 2004, BIGELOW,JIM (HP-Boise,ex1) wrote:
    >
    > > 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.
    >
    > 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.

    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

RESOLUTION:

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

    Ernest,

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

    >
    > 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.
    >

    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

RESOLUTION:

    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 <length>

    Ernest,

    Your issue, shown below, has been accepted by the editor.
    > >
    > > 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.
    > >

    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

## 1.23 [23] Section 3.4.1 Example

PROBLEM ID: 23

STATE: closed
RESOLUTION:Rejected, editorial comment, not change needed.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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.
    >
    >
    > 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.
    >

    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

FOLLOWUP 01:

    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

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    >
    > > 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

    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.

FOLLOWUP 02:

    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:
    > > 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.
    > >
    > >
    > 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
    >

    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

FOLLOWUP 03:

    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:
    > 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

    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                                <URL: http://dbaron.org/ >

FOLLOWUP 04:

    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

    > [Original Message]
    > From: L. David Baron <dbaron@dbaron.org>
    >
    > 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.

    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 <span> 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.

FOLLOWUP 05:

    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

    > @page :first {span {color:blue}}
    > @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

FOLLOWUP 06:

    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

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

FOLLOWUP 07:

    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

RESOLUTION:

    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.

    >
    >
    > 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.
    >

    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

## 1.24 [24] Section 3.5

PROBLEM ID: 24

STATE: closed
RESOLUTION:Duplicate of #22
USER POSITION: Agree

ORIGINAL MESSAGE:

    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?

ACKNOWLEDGED:

    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.
    >
    > As per [22], why does the page context have no notion of fonts?
    >
    >

    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

RESOLUTION:

    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.

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

       -- Jim Bigelow, Editor

## 1.25 [25] Section 3.6

PROBLEM ID: 25

STATE: closed
RESOLUTION:Rejected, comment on functionality outside scope of specification.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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).

ACKNOWLEDGED:

    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.
    >
    > 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).
    >

    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

FOLLOWUP 01:

    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/

    > -----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 25 -- [25] Section 3.6
    >
    >
    > 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.
    >
    > 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).
    >

    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

RESOLUTION:

    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.

    >
    > 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).
    >

    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

## 1.26 [26] Section 4.2 maximum width of the top center cell

PROBLEM ID: 26

STATE: closed
RESOLUTION:Accepted and updated spec.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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.
    >
    > 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.
    >

    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

RESOLUTION:

    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.

    >
    > 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.
    >

       -- Jim Bigelow, Editor

## 1.27 [27] Section 7

PROBLEM ID: 27

STATE: closed
RESOLUTION:Accepted and updated spec.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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.
    >
    > It would be helpful if one or more links to the 'float' property in
    > the CSS3 Box Module were included here.
    >

    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

RESOLUTION:

    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.

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

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

       -- Jim Bigelow, Editor

## 1.28 [28] Section 7.4

PROBLEM ID: 28

STATE: closed
RESOLUTION:Accepted and updated spec.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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?

ACKNOWLEDGED:

    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.
    >
    > Where is "@float-area" formally defined?
    >

    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

RESOLUTION:

    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.

    >
    > Where is "@float-area" formally defined?
    >

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

       -- Jim Bigelow, Editor

## 1.29 [29] Section 8

PROBLEM ID: 29

STATE: closed
RESOLUTION:Accepted and updated spec.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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 <integer> instead of
    as an <angle>?  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.

ACKNOWLEDGED:

    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.
    >
    > What is the motivation for defining rotation as <integer> instead of
    > as an <angle>?  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.
    >

    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

FOLLOWUP 01:

    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 <angle> in the range of 0 to 260 is preferable to
    <integer>.  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

    > -----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 29 -- [29] Section 8
    >
    >
    > 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.
    >
    > What is the motivation for defining rotation as <integer> instead of
    > as an <angle>?  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.
    >

    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

FOLLOWUP 02:

    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

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    > To: <www-style@w3.org>; <ernestcline@mindspring.com>
    > Date: 1/7/2004 8:32:42 PM
    > Subject: RE: [css3-page] LCWD issue 29 --  [29] Section 8
    >
    > Ernest,
    >
    > I agree that <angle> in the range of 0 to 260 is preferable to
    > <integer>.
    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.

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

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

FOLLOWUP 03:

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

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

    Jim

RESOLUTION:

    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.

    >
    > What is the motivation for defining rotation as <integer> instead of
    > as an <angle>?  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.
    > ...
    > I was referring to the <angle> value type from
    > CSS3 Values [1] not some new definition of <angle> that would allow
    > only degrees.
    >
    > [1] http://www.w3.org/TR/2001/WD-css3-values-20010713/#angles

       -- Jim Bigelow, Editor

## 1.30 [30] Section 8

PROBLEM ID: 30

STATE: closed
RESOLUTION:Accepted and updated spec.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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".

ACKNOWLEDGED:

    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.
    >
    > "Tow values" should be "Two values".
    >
    >
    >
    >

    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

RESOLUTION:

    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.

    >
    > "Tow values" should be "Two values".
    >

       -- Jim Bigelow, Editor

## 1.31 RE: [css-page] New, last draft of CSS3 Paged Media Module

PROBLEM ID: 31

STATE: closed
RESOLUTION:Duplicate of #14.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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.
    >
    >
    > 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.
    >
    >

    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

RESOLUTION:

    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.

    > 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.
    >
    >

       -- Jim Bigelow, Editor

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

## 1.32 [CSS3-Page] 3.3.2 Page Size Error

PROBLEM ID: 32

STATE: closed
RESOLUTION:Accepted and changed spec.
USER POSITION: Agree

ORIGINAL MESSAGE:

    From: Lachlan Hunt [lachlan.hunt@iinet.net.au]
    Date: Fri, 19 Dec 2003 15:36:10 +1100
    Message-ID: <3FE2803A.8020502@iinet.net.au>
    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!

ACKNOWLEDGED:

    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.
    >
    >
    > 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!
    >

    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

RESOLUTION:

    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.

    > 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
    >

       -- Jim Bigelow, Editor

## 1.33 [css3-page] Comment on page counters

PROBLEM ID: 33

STATE: closed
RESOLUTION:Accepted and changed spec by extending the page-policy to apply to counter-reset.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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

ACKNOWLEDGED:

    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:
    > I think it would be interesting to specify that the counter
    > "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

FOLLOWUP 01:

    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 <p>-element for example? Would it
    affect the page onto which the formatted result of the <p>-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:
    > Werner,
    >
    > Thank you for you comment. It has been assigned issue number 33.
    >
    > You wrote:
    >
    >>I think it would be interesting to specify that the counter
    >>"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
    >
    >

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

FOLLOWUP 02:

    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 <div> 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

RESOLUTION:

    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.

    >
    > 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 <div> 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.
    >

     -- Jim Bigelow, editor

    [1] http://www.w3.org/TR/css3-page/#page-policy-sec

## 1.34 [css3-page] Section 3.4.2. Cascading in the page context

PROBLEM ID: 34

STATE: closed
RESOLUTION:Accepted and updated spec.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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

ACKNOWLEDGED:

    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:
    > 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?

    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

FOLLOWUP 01:

    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:
    > Werner,
    >
    > Thank you for your comment, it has been assign the number 34.
    >
    > You wrote:
    >
    >>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?
    >
    >
    > 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
    >
    >

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

FOLLOWUP 02:

    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
    > 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?
    >

     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

    >
    > BIGELOW,JIM (HP-Boise,ex1) wrote:
    > > Werner,
    > >
    > > Thank you for your comment, it has been assign the number 34.
    > >
    > > You wrote:
    > >
    > >>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?
    > >
    > >
    > > I think the concept of specificity [1] already supplies the
    > > relationship you describe.
    > > [1] Item 3 of
    > http://www.w3.org/TR/CSS21/cascade.html#cas> cading-order
    > >

FOLLOWUP 03:

    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:
    > Werner, you wrote
    >
    >>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?
    >>
    >
    >  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
    >
    >
    >
    >
    >>BIGELOW,JIM (HP-Boise,ex1) wrote:
    >>
    >>>Werner,
    >>>
    >>>Thank you for your comment, it has been assign the number 34.
    >>>
    >>>You wrote:
    >>>
    >>>
    >>>>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?
    >>>
    >>>
    >>>I think the concept of specificity [1] already supplies the
    >>>relationship you describe.
    >>>[1] Item 3 of
    >>
    >>http://www.w3.org/TR/CSS21/cascade.html#cas> cading-order
    >>
    >
    >

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

RESOLUTION:

    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.

    > 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?
    >
     -- Jim Bigelow, editor

## 1.35 [css3-page] Applicable properties in margin boxes

PROBLEM ID: 35

STATE: closed
RESOLUTION:Not an issue, behavior already part of CSS
USER POSITION: Agree

ORIGINAL MESSAGE:

    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

ACKNOWLEDGED:

    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:
    >
    > 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.
    >

    Jim

FOLLOWUP 01:

    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

RESOLUTION:

    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.

    >
    > 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.
    >
    Jim Bigelow, editor

## 1.36 [css3-page] examples in 3.3.2 (page size) are 'US-centric'(?)

PROBLEM ID: 36

STATE: closed
RESOLUTION:Accepted and corrected units, added set of media names, and referenced PWG media names spec.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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

ACKNOWLEDGED:

    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:
    >
    > 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.
    >

     -- Jim Bigelow, editor

FOLLOWUP 01:

    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'(?)

    > [Original Message]
    > From: Jungshik Shin <jshin@i18nl10n.com>
    >
    > 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 because numbers (21.0 and 29.7) are more comparable to 8.5 and
    > 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

FOLLOWUP 02:

    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:
    > > [Original Message]
    > > From: Jungshik Shin <jshin@i18nl10n.com>
    > >
    > > 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 because numbers (21.0 and 29.7) are more comparable
    > > to 8.5 and 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

    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

FOLLOWUP 03:

    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'(?)

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    >
    > I agree you 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?

    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 <length> 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 <length>
    I am in favor of this.  I am strongly against having to special case
    general purpose values such as <length>, 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 <classname> "_" <sizename> 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 <sizename>. 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
     <sizename>s.  Thus they require the <classname> to know which is
     meant in a context where either could occur. Hence, using just the
     <sizename> 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 <length>{1,2} in the allowed values of 'size'.)  A
    conforming UA could also recognize names of the form <class-name> "_"
    <size-name> 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

FOLLOWUP 04:

    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:
    >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?

    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?

FOLLOWUP 05:

    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'(?)

    > [Original Message]
    > From: Bjoern Hoehrmann <derhoermi@gmx.net>
    > To: <ernestcline@mindspring.com>
    > Cc: <www-style@w3.org>
    > Date: 1/19/2004 5:27:11 PM
    > Subject: Re: [css3-page] examples in 3.3.2 (page size) are
    > 'US-centric'(?)
    >
    > * Ernest Cline wrote:
    > >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?
    >
    > 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?

    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 <class-name>
    "_" <size-name> 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.

FOLLOWUP 06:

    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*:
    >> From: Bjoern Hoehrmann <derhoermi@gmx.net>
    >>
    >> 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;

    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".

    >> 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 ;

    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.

    > size: us_letter_8.5x11in;
    >
    > 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).

    > 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.

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

    > 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.

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

    > What follows is what I feel to be a likely maximum minimum:
    >
    > 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).

    > 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)

    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.

    > 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.

    > 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 <class-name>
    > "_" <size-name> 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.

    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'.

FOLLOWUP 07:

    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'(?)

    > [Original Message]
    > From: Christoph P�per <christoph.paeper@tu-clausthal.de>
    >
    >
    > *Ernest Cline*:
    > >> From: Bjoern Hoehrmann <derhoermi@gmx.net>
    > >>
    > >> 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;
    >
    > 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".
    >
    > >> 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 ;
    >
    > 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.

    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.

    > > size: us_letter_8.5x11in;
    > >
    > > 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).

    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)

    > > 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.
    >
    > That's a benefit to just very few people, especially given the
    > machine-centered aim of that IEEE spec. It's not worth it.
    >
    > > 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.
    >
    > I agree, although the sizes of the basic ISO series can be calculated
    > by an
    > algorithm without a lookup table. JIS B too.
    >
    > > What follows is what I feel to be a likely maximum minimum:
    > >
    > > 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).

    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.

    > > 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)
    >
    > 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.

    Only if you assume that the list will never be expanded to include
    other page sizes that share the same <sizename> 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.

    > > 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.
    >
    > > 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
    > > <class-name> "_" <size-name> 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.
    >
    > 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.

    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.

    > and
    >
    > | It is also acceptable to replace the underscore separator between
    > | 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.

    > [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'.

    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 <size-name> that ends in a digit and the
    dimension part of a self- describing media name.

FOLLOWUP 08:

    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:
    > Sent: Monday, January 19, 2004 9:43 PM
    > 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)
    >

    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

FOLLOWUP 09:

    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'(?)

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    >
    > Ernest wrote:
    > > Sent: Monday, January 19, 2004 9:43 PM
    > > 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)
    >
    > 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?

    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.

FOLLOWUP 10:

    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:
    >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..

    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.

FOLLOWUP 11:

    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'(?)

    >  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?

    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

FOLLOWUP 12:

    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*:
    >
    > 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.

    JFTR, in Germany nobody says "ISO A4", few just "A4", most "DIN A4".

FOLLOWUP 13:

    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" <christoph.paeper@tu-clausthal.de>
    wrote:

    >
    > *Michael Day*:
    >>
    >> 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.
    >
    > 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

FOLLOWUP 14:

    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'(?)

    > [Original Message]
    > From: Michael Day <mikeday@yeslogic.com>
    >
    > >  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?
    >
    > 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.

    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.

FOLLOWUP 15:

    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'(?)

    > 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

    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.

FOLLOWUP 16:

    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

FOLLOWUP 17:

    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'(?)

    > [Original Message]
    > From: Michael Day <mikeday@yeslogic.com>
    >
    > 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

    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 <classname> "-" <sizename> form from the
    IEEE PWG standard, even if the chosen keywords could be expressed
    uniquely by just the <sizename>.  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.

FOLLOWUP 18:

    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,

    > 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,

    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.

    > 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.

    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

FOLLOWUP 19:

    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'(?)

    > [Original Message]
    > From: Michael Day <mikeday@yeslogic.com>
    > To: Ernest Cline <ernestcline@mindspring.com>
    > Cc: W3C CSS List <www-style@w3.org>
    > Date: 1/24/2004 5:13:15 PM
    > Subject: RE: [css3-page] examples in 3.3.2 (page size) are
    > 'US-centric'(?)
    >
    >
    > Hi Ernest,
    >
    > > 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,
    >
    > 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.

    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.

    > 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.

    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.)

    > > 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.
    >
    > 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.

    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.

FOLLOWUP 20:

    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,

    > 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.

    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.

    > Had you followed the recommendation in this case it would have been:
    >
    > @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 }

    > (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.

    Standardisation follows implementation, not the other way around.

    Best regards,

    Michael

    --
    YesLogic Prince prints XML!
    http://yeslogic.com

FOLLOWUP 21:

    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" <mikeday@yeslogic.com> wrote:

    >
    >
    > Hi Ernest,
    >
    >> 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.
    >
    > 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.

    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.

    >> Had you followed the recommendation in this case it would have been:
    >>
    >> @page {size: -yeslogic-a4 }
    >
    > One look at this monstrosity makes it pretty obvious why we did not
    > 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).

    > 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.

    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 :)

    > 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.

    Agreed, but is this good practice for an implementer of standards? (

    > 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 }
    >
    >> (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.
    >
    > 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

FOLLOWUP 22:

    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'(?)

    > 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

    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.

FOLLOWUP 23:

    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'(?)

    > 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.

    > 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.

    > Assuming that he is writing his own CSS by hand how would he know
    > 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.

FOLLOWUP 24:

    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:
    >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.

    In Germany you will virtually always encounter "DIN A4"; omitting the
    DIN prefix seems thus just wrong and is rather confusing to me.

FOLLOWUP 25:

    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

    > -----Original Message-----
    > From: BIGELOW,JIM (HP-Boise,ex1)
    > Sent: Thursday, January 22, 2004 1:47 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:
    > > Sent: Monday, January 19, 2004 9:43 PM
    > > 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)
    > >
    >
    > 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
    >

FOLLOWUP 26:

    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'(?)

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    >
    > 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.

    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.

FOLLOWUP 27:

    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)*:
    >
    > This issue, number 36,
    >
    > 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

    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.

    > 4.  ftp://ftp.pwg.org/pub/pwg/standards/pwg5101.1.pdf will be
    > 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.

RESOLUTION:

    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.

    >
    > 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 because numbers (21.0 and 29.7) are more comparable
    > 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

## 1.37 XSL FO SG comment on css3-page spec

PROBLEM ID: 37

STATE: closed
RESOLUTION:Not an issue, no change proposed.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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 <w3c-xsl-fo-sg@w3.org> 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

ACKNOWLEDGED:

    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:
    > Regarding:  CSS3 Paged Media Module
    >     http://www.w3.org/TR/2003/WD-css3-page-20031218
    >
    > The XSL FO SG <w3c-xsl-fo-sg@w3.org> 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
    >
     -- Jim Bigelow, Editor

FOLLOWUP 01:

    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:
    >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):
    >>
    >> Regarding:  CSS3 Paged Media Module
    >>     http://www.w3.org/TR/2003/WD-css3-page-20031218
    >>
    >> The XSL FO SG <w3c-xsl-fo-sg@w3.org> 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
    >>
    >
    >  -- Jim Bigelow, editor

FOLLOWUP 02:

    To: Paul Grosso; www-style@w3.org
    Subject: RE: XSL FO SG comment on css3-page spec

    Paul,

    You wrote:
    > The XSL FO SG's understanding is that an important goal for
    > W3C style-related specifications is to maintain consistency
    > across the various models.
    >

    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 <--> @page

    > 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.

    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

RESOLUTION:

    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):
    >
    > Regarding:  CSS3 Paged Media Module
    >     http://www.w3.org/TR/2003/WD-css3-page-20031218
    >
    > The XSL FO SG <w3c-xsl-fo-sg@w3.org> 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
    >

      -- Jim Bigelow, editor

## 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

PROBLEM ID: 38

STATE: closed
RESOLUTION:Accepted, referenced specification and media names.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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)" <jim.bigelow@hp.com> 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

ACKNOWLEDGED:

    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:
    > 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.
    >

    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

FOLLOWUP 01:

    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)" <jim.bigelow@hp.com> 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:
    > 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.
    >

    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

FOLLOWUP 02:

    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)" <jim.bigelow@hp.com> 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:
    > 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.
     >

FOLLOWUP 03:

    To: don@lexmark.com
    Subject: RE: [css3-page] Last Call Comments on CSS3 Paged Media Module

    Don,

    You wrote about issue 38:
    >
    > Isn't there now a reference to the PWG Media Standard in the
    > document as well?
    >
    > If so, I'm happy with the resolution.
    >

    Yes, the Media Standardized Names standard is referenced during the
    discussion of media names.

    Best regards,

    Jim

RESOLUTION:

    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:
    > 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.
    >

## 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

PROBLEM ID: 39

STATE: closed
RESOLUTION:Accepted comment and changed example.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    > To: <ernestcline@mindspring.com>
    > Date: 2/7/2004 8:30:01 PM
    > 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.
    >
    > >
    > >
    > > 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.
    > >
    >
    > 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.

    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.

ACKNOWLEDGED:

    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

    > 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.
    >
    >

    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

RESOLUTION:

    To: W3C CSS List
    Subject: RE: [css3-page] LCWD issue 23 -- [23] Section 3.4.1 Example

    Ernest,

    You wrote:
    > > 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.
    > >
    > >
    > 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
    >

    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

## 1.40 [CSS3-page]: Comments on pages media

PROBLEM ID: 40

STATE: closed
RESOLUTION:Rejected, proposed redesign header and footer areas not accepted.
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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:
    > 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.
    >

RESOLUTION:

    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.

    > 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.
    >

    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.

    > 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.
    >

    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

## 1.41 [CSS3-page]: Comments on pages media

PROBLEM ID: 41

STATE: closed
RESOLUTION:Rejected, extension outside the scope of specification
USER POSITION: Agree

ORIGINAL MESSAGE:

    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?

ACKNOWLEDGED:

    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
    > 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?
    >

RESOLUTION:

    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.

    >
    > Issue 41
    > > 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?
    > >
    >

    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

## 1.42 [CSS3-page]: Comments on pages media

PROBLEM ID: 42

STATE: closed
RESOLUTION:Accepted without changes
USER POSITION: Agree

ORIGINAL MESSAGE:

    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?

ACKNOWLEDGED:

    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
    > 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?
    >

RESOLUTION:

    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.

    > Issue 42
    > > 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?
    > >
    >

    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

## 1.43 [CSS3-page]: Comments on pages media

PROBLEM ID: 43

STATE: closed
RESOLUTION:Rejected, no need for new formatting property, existing properties can be used
USER POSITION: Agree

ORIGINAL MESSAGE:

    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.

ACKNOWLEDGED:

    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
    > 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.
    >

RESOLUTION:

    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

    >
    > [1] http://lists.w3.org/Archives/Public/www-style/2003Sep/0114.html
    >
    > Issue 43
    > > 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.
    > >
    >

## 1.44 [css3-page] Is auto a page identifier or not?

PROBLEM ID: 44

STATE: closed
RESOLUTION:Rejected since auto is a special identifier
USER POSITION: Agree

ORIGINAL MESSAGE:

    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 | <identifier>
    Initial: 	auto

    becomes:

    Name: 	page
    Value: 	<identifier>
    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..

    <div>
    <p style="page:landscape">...</p>
    <p style="page:auto">...</p>
    </div>

    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

ACKNOWLEDGED:

    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

    >
    > 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 | <identifier>
    > Initial: 	auto
    >
    > becomes:
    >
    > Name: 	page
    > Value: 	<identifier>
    > 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..
    >
    > <div>
    > <p style="page:landscape">...</p>
    > <p style="page:auto">...</p>
    > </div>
    >
    > 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'.
    >

     -- Jim Bigelow, editor

FOLLOWUP 01:

    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?

    > [Original Message]
    > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>

    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.

    > 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:
    > > In the 'page' property is the value of "auto" to be treated
    > > as identifier or not?

FOLLOWUP 02:

    To: ernestcline@mindspring.com
    Cc: W3C CSS List
    Subject: RE: [css3-page] Is auto a page identifier or not?

    Ernest wrote:
    >
    > 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.
    >
    > > [Original Message]
    > > From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
    > > ...  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.
    > >

    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

FOLLOWUP 03:

    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:
    > 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 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                                <URL: http://dbaron.org/ >

FOLLOWUP 04:

    To: www-style@w3.org
    Subject: RE: [css3-page] Is auto a page identifier or not?

    L. David Baron wrote:

    > 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.
    >

    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:
    > [ current description ]
    > Name: 	page
    > Value: 	auto | <identifier>
    > Initial: 	auto
    >
    > becomes:
    >
    > Name: 	page
    > Value: 	<identifier>
    > 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:

    > @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?

    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

FOLLOWUP 05:

    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:
    > 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:
     >
    >>Value: 	<identifier>
    >>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 | <string>

    That would be much more future-proof.

    -Boris

FOLLOWUP 06:

    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?

    > [Original Message]
    > From: Boris Zbarsky <bzbarsky@MIT.EDU>
    >
    > 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 | <string>
    >
    > 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 <identifier> 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 |
    <identifier>" or "<identifier>" 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.

FOLLOWUP 07:

    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:
    > 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,

    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 | <identifier>" is somewhat meaningless.  It could be simplified
    to "<identifier>", 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

RESOLUTION:

    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:
    > 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 | <identifier>
    > Initial: 	auto
    >
    > becomes:
    >
    > Name: 	page
    > Value: 	<identifier>
    > Initial: 	auto
    >