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