Re: [css3-page] comments on WD-css3-page-20061010

Hello Björn ,
Thank you for your comments [1] on CSS3 Paged Media [2]. Changes will be reflected in the next release of the document (or can be previewed by members at
>Section 1:
>I think this should come after "Introduction". Specifications should
>always begin with the Introduction, not the references.

Agreed, thanks.

>Section 2:
>"Paged media (e.g., paper, transparencies, pages that are displayed on
>computer screens, etc.)" -- the "etc." should be removed.
>"CSS3 defines a page model" -- This should refer to "this document",
>"this specification", "this module", or similar; the current reference
>suggests this model is defined elsewhere, which is not the case.
>"a physical sheet onto which the document is ultimately rendered (paper,
>transparency, screen etc.)" -- the last part should be removed, it is
>redundant with the earlier listing, and using "etc." is generally
>editorially poor.

>Section 3.1:
>"This value is printer dependent" and "This value is printing device
>dependent" are used to refer to the same concept. The same language
>should be used to refer to this concept.
>For "Content-empty Page" the first word should be capitalized.


>Section 3.3.1:

>I think the <page-size> definition would be more readable as a table.


>Section 3.3.2:
>The term "Portrait Orientation" occurs in all lower-case letters in
>other sections of the document.

Changed to lower case here as well.

>Section 3.3.3:
>It's a bit odd to say the list is "in order", and then use a unordered

;-) Changed to an ordered list.

>Section 3.4.1:
>This section lacks a normative reference for the definition of the
>grammar that is being used here. I think it is a bad idea to mix
>grammars as is done here. If EBNF would be used throughout this section,
>the requirement
>  The value 'auto' may not be used as a page name and MUST be treated as
>  a syntax error.
>would be unnecessary, it could be encoded in the grammar.

The WG recognizes that the grammar used doesn't have a formal definition.  But it is the same as that used for CSS2.1, and the description in Appendix G ( seems to us sufficient.  Although, knowing your personal penchant for such matters, the WG would welcome a contribution should you wish to propose a concrete replacement...?

>Section 3.4.2:
>"Optionally, @page rules can have one pseudo-class (':first',':left', or
>'right') and/or one named page." -- it seems this should be ":right"
>with the colon. I think this sentence is poorly phrased and perhaps mis-
>placed (it does not have anything to do with "cascading").
>"The specificity of @page rules are " -- shouldn't this be "... is"?
>I think the "concatenating numbers" idiom to express the specificity is
>a very poor one, I would prefer to see this expressed as an array.
>"and all other pages (i.e., the right pages)" -- I think the "i.e.," is
>redundant here.

Offending sentence removed, verb changed to agree with its subject, and superfluous 'i.e.' removed.
The 'concatenating numbers idiom' is the same as that used in CSS 2.1 Section 6.4.3, and the group didn't see a strong motivation to change the model at this point in time.  We did agree to sync up the wording in css3 page with than in 2.1 6.4.3.

>Section 3.5:
>I am worried about the list of properties here, I think it is not very
>precise, it is difficult to map this to CSS3 properties instead, and the
>specification would have to be updated whenever new properties should
>apply to the concepts defined herein.

Yes, we want new CSS3 properties to apply where they make sense.  But a detailed list would be nice as well.  The two objectives are a bit at odds. We've resolved to create an appendix for the detailed list of CSS 2.1 properties that apply.  As the specification currently depends only on CSS2.1 and not on other CSS3 modules, we expect to have to rev this document at some point after 2.1 goes to REC. (We also plan at the same time to move some properties to 'Box' where they more logically belong.)

>"Values in units of 'em' and 'ex' refer to the page context's font. The
>page context has a font associated with it either by an explicit use of
>the 'font-family' and 'font-size' properties or from their initial
>values." -- Is this true? Using the 'font' property, which seems
>allowed, does not seem to qualify as "explicit use of the 'font-family'"

Good point.  Changed to " an explicit use of font properties or..."

>"It is recommended that user agents with a non-printable area ..." --
>this sounds like non-printable areas are a property of user agents,
>which they are not.

Well, they are if the user agent is a printer. ;-)  Changed to "It is recommended that user agents establish a default page margin via the user agent stylesheet that includes any non-printable area. "

>Section 3.7:
>I am concerned that the word 'may' here is not used with its RFC 2119
>meaning, yet the styling indicates that it is.
>The "should not" in this section is styled incorrectly.

Agreed, fixed.

>Section 4.3:
>"Note that, by their definitions, margins may be negative, but widths
>may not." -- Here "may not" is styled as if it was a RFC 2119 term, even
>though it is not. The other "may" also does not seem to be a RFC 2119
>keyword, and the note seems misplaced. It would be better to turn this
>into a non-normative note outside the list.


>Section 5.5:
>There appears to be a problem with the markup here.

Thanks, fixed.

>Concerning multiple sections:
>I think the use of "&nbsp; " is both inconsistent in the document and
>poor form generally.

Yes, a leftover from a previous incarnation where we used these silly things called typewriters, and put two spaces between sentences...  Fixed.  (For now.  They creep back.  I'll try to watch them.)

Thanks again for your input.  Please let us know within 10 days if you find any of our resolutions unacceptable.

Best wishes,




HP  -   Melinda Grant
Connectivity Standards 
Consumer Printing and Imaging
+1 (541) 582-3681   

Received on Thursday, 19 April 2007 02:16:06 UTC