Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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.
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.
| Issue | State | User | Resolution |
|---|---|---|---|
| 01: [1] Section 1: | closed | Agree | Accepted, spec updated |
| 02: [2] Section 1: | closed | Agree | Accepted, spec updated |
| 03: [3] Section 2: | closed | Agree | Accepted, spec updated |
| 04: [4] Section 2: | closed | Agree | Accepted, spec updated |
| 05: [5] Section 3.1: | closed | Agree | Accepted, spec updated |
| 06: [6] Section 3.1 "Page Box": | closed | Agree | Accepted, spec updated |
| 07: [7] Section 3.1 "Page Box": | closed | Agree | Accepted, spec updated |
| 08: [8] Section 3.1 "Margin box" | closed | Agree | Accepted, spec updated |
| 09: [9] Section 3.1 "Margin box" | closed | Agree | Accepted, spec updated |
| 10: [10] Section 3.1 "Margin box" | closed | Agree | Accepted, spec updated |
| 11: [11] Section 3.1 diagram | closed | Agree | Accepted, spec updated |
| 12: [12] Section 3.1 diagram | closed | Agree | Accepted, spec updated |
| 13: [13] Section 3.1 diagram | closed | Agree | Accepted, spec updated |
| 14: [14] Section 3.2 | closed | Agree | Accepted, spec updated |
| 15: [15] Section 3.2 "Back side" | closed | Agree | Accepted, spec updated |
| 16: [16] Section 3.2 "First page" | closed | Agree | Accepted, spec updated |
| 17: [17] Section 3.2 "Left page" | closed | Agree | Accepted, spec updated |
| 18: [18] Section 3.2 "Right page" | closed | Agree | Accepted, spec updated |
| 19: [19] Section 3.3 | closed | Agree | accepted, spec updated |
| 20: [20] Section 3.3.1 Example | closed | Agree | accepted, spec updated. |
| 21: [21] Section 3.3.2 | closed | Agree | duplicate of #36 |
| 22:
[22] Section 3.3.2 | closed | Agree | accepted, spec updated. |
| 23: [23] Section 3.4.1 Example | closed | Agree | Rejected, editorial comment, not change needed. |
| 24: [24] Section 3.5 | closed | Agree | Duplicate of #22 |
| 25: [25] Section 3.6 | closed | Agree | Rejected, comment on functionality outside scope of specification. |
| 26: [26] Section 4.2 maximum width of the top center cell | closed | Agree | Accepted and updated spec. |
| 27: [27] Section 7 | closed | Agree | Accepted and updated spec. |
| 28: [28] Section 7.4 | closed | Agree | Accepted and updated spec. |
| 29: [29] Section 8 | closed | Agree | Accepted and updated spec. |
| 30: [30] Section 8 | closed | Agree | Accepted and updated spec. |
| 31: RE: [css-page] New, last draft of CSS3 Paged Media Module | closed | Agree | Duplicate of #14. |
| 32: [CSS3-Page] 3.3.2 Page Size Error | closed | Agree | Accepted and changed spec. |
| 33: [css3-page] Comment on page counters | closed | Agree | Accepted and changed spec by extending the page-policy to apply to counter-reset. |
| 34: [css3-page] Section 3.4.2. Cascading in the page context | closed | Agree | Accepted and updated spec. |
| 35: [css3-page] Applicable properties in margin boxes | closed | Agree | Not an issue, behavior already part of CSS |
| 36: [css3-page] examples in 3.3.2 (page size) are 'US-centric'(?) | closed | Agree | Accepted and corrected units, added set of media names, and referenced PWG media names spec. |
| 37: XSL FO SG comment on css3-page spec | closed | Agree | Not an issue, no change proposed. |
| 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 | closed | Agree | Accepted, referenced specification and media names. |
| 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 | closed | Agree | Accepted comment and changed example. |
| 40: [CSS3-page]: Comments on pages media | closed | Agree | Rejected, proposed redesign header and footer areas not accepted. |
| 41: [CSS3-page]: Comments on pages media | closed | Agree | Rejected, extension outside the scope of specification |
| 42: [CSS3-page]: Comments on pages media | closed | Agree | Accepted without changes |
| 43: [CSS3-page]: Comments on pages media | closed | Agree | Rejected, no need for new formatting property, existing properties can be used |
| 44: [css3-page] Is auto a page identifier or not? | closed | Agree | Rejected since auto is a special identifier |
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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. >
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
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
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
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
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. > > >
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
>