- From: Grant, Melinda <melinda.grant@hp.com>
- Date: Fri, 4 May 2007 03:46:04 -0000
- To: "fantasai" <fantasai.lists@inkedblade.net>
- Cc: <www-style@w3.org>
Hi fantasai, Thanks much for the detailed review. Responses intercalated below. Best wishes, Melinda > -----Original Message----- > From: fantasai [mailto:fantasai.lists@inkedblade.net] > Sent: Thursday, March 29, 2007 5:05 PM > To: www-style@w3.org; Grant, Melinda > Subject: [CSS3 Page] Comments on CSS3 Paged Media (I) > > Introduction > ------------ > > # A signature is a group of pages printed on a sheet, which, > # when folded and trimmed like a book, appear in their proper > # sequence; > > "signature" should be in <dfn> OK > Page Boxes: the @page Rule > -------------------------- > > # The properties of a page box are determined by properties > # established within the page context, which is the rule set > # of the @page rule. > > s/established/declared/ > -- also link this to > http://www.w3.org/TR/CSS21/syndata.html#declaration OK > s/rule set/declaration block/ > -- also link this to http://www.w3.org/TR/CSS21/syndata.html#x14 OK > Page Terminology and the Page Model > ----------------------------------- > > # A user agent may not be aware of this area or how it varies > # from printing device to printing device. > > s/may not be aware/may be unaware/ -er, ok > # Printing devices MAY adjust the layout of the document > # so that content is not lost. > > If a UA is aware of the non-printable area restriction, is > it allowed to make the adjustment before sending the page > to the printer? Yes. The sentence should actually state, "User agents MAY adjust the layout of the document so that content is not lost." I'll make that change. > # A user agent may not be aware of this are ... Content outside > # the page box. > > This text is repeated twice: in the non-printable area definition > and again in the printable area definition. Reworded to minimize redundancy between the two definitions. > # Unlike other boxes, the margins of the page box are subdivided > # into margin boxes. > > This repeats an earlier statement in the previous section. The terminology section is currently misplaced. Once it's moved, I think the redundancy will be less noticeable and more valuable. I've reworded this occurrence to: "Running headers and footers can be put into margin boxes." > > # In the simplest case, the page box is congruent with the page > # sheet. > > Which page box is congruent with the page sheet? Its margin box, > border box, padding box, or content box? Well, as with other boxes, the margin box is congruent with the box's edge... So the page's margin box is congruent with the page box's edge... But we're not talking about any of those boxes here, we're defining a new term, the 'page box'. Is that confusing/not clear? > # The page area acts as a container for all the boxes laid out > # within a given page box. > > This statement is repeated from the previous section. Same disclaimer about moving the Terminology section. > # Margin box > > I would add to the beginning of this definition the following: > "Margin boxes are rectangular regions within the page margin." > The current definition only says what they are used for, not > what they are. Also, this definition duplicates content from the > previous section. Thanks, text added. > # page margin / page border / page padding > > These terms are not defined anywhere. No. Once the page box is defined and the box model derivation given, aren't margins, border, padding already defined by the box model? Would it really add clarity to say that the page margin is the margin (link to http://www.w3.org/Style/Group/css2-src/box.html#box-dimensions) for the page box (link to page box dfn)? Or what else would you like to see added here? > Page Types > ---------- > > # Some of these depend upon factors such as the major writing > # direction and the media type that are not specified by this > # module. > > s/ that/, which/ I've reworded the sentence to: "Some of these depend upon factors not specified by this module, such as the major writing direction and the media type. > > Also, you might want to pick a more precise term than media type. > It has at least two other technical meanings that are associated > with CSS and (X)HTML documents. Yes. The problem is 'media type' is widely and consistently used within the print industry. Sentence re-reworded to: "Many of these depend upon factors not specified by this module, such as the major writing direction and the properties of the print media to be used." Actually, I think this section should focus on layout or go away. The terms should be added to the previous Terminology section. The discussion of variability of page layout could maybe be moved to the section on "Positioning the page box on the sheet". > # page orientation > > I would add to the definition that the page orientation can be > either landscape or portrait. Added "This specification defines page orientations of 'portrait' and 'landscape'." (Reverse-portrait and reverse-landscape terms are also commonly used, but CSS3 Page doesn't use them.) > > # Duplex printing uses one page box... > > s/uses/prints/ OK > # Binding Edge treatment > > s/treatment// OK > # 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. > ... > # Page layouts for documents using a left-to-right major writing > # direction have the earlier of the facing pages on the left. > ... > # Whether the first page of a document is ':left' or ':right' > # depends on the major writing direction of the document and is > # outside the scope of this document. > > These three sentences are contradictory. (The last one was taken > from a different section, "Left, right and first pages") First and third sentences removed. > > # 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 MUST determine it using the value > # of that property on the root element. > > I think we need to be a bit more specific here, since in vertical > text the 'direction' property is irrelevant for determining page > order: the block progression direction is used instead. So > If text is laid out horizontally, > the major writing direction is the same as the inline > progression > direction (determined by 'direction'). > If text is laid out vertically, > the major writing direction is the same as the block > progression > direction (determined by a new property from CSS3 Text Layout) Great! I renamed 'major writing direction' to 'page progression' to be more consistent with 'block-progression'; I suppose we could need to add a 'page-progression property some day. I've reworked the pertinent text a bit, and added the above. Check out the next version and see if it addresses your concerns. > # Rules for the left page can be specified using the ':left' page > selector. > # Rules for the right page can be specified using the ':right' page > selector. > # Rules for the first page can be specified using the ':first' > page selector. > > s/for/specific to/g OK > # 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. > > Stating this requirement should be deferred to the page selectors > section. > (It is already defined there.) OK > How does this module consider these concepts when the binding edge > is the top edge of the booklet instead of a side edge? Left/right- > based styling doesn't really make sense in that case. The module does not address the short-edge (horizontal) bindings use case. I don't know the historical rationale behind this. Arguably 'leading' and 'trailing' or similar terms might have been preferable. > > Page Size > --------- > > It is not clear which box's size is being set here because what > rectangle > exactly corresponds to the term "page box" is not defined. > I assume it > is the same rectangle as the page margin box, but that must be > stated > somewhere. The first sentence in the property description links to the following definition: "Page box A page box is derived from the box model and contains portions of the document flow destined for rendering on a page sheet. The width and height of the page box are determined by the size property. Running headers and footers can be put into margin boxes. In the simplest case, the page box is congruent with the page sheet. However, there are more complex use cases (see the transfer possibilities in the Introduction) where the page box differs from the page sheet in values such as size or orientation." Apparently it would be helpful if I expanded the definition to include something like: "As for all CSS boxes, it contains margin, border and padding areas." If I change the definition as follows, does it clear things up? "Page box A page box is derived from the box model and contains portions of the document flow destined for rendering on a page sheet. The width and height of the page box are determined by the size property. In the simplest and usual case, the page box is congruent with the page sheet. (See the transfer possibilities in the Introduction for situations where the page box differs from the page sheet in values such as size or orientation.) As with all CSS boxes, the page box contains margin, border, and padding areas. Unlike other CSS boxes, running headers and footers can be placed within the margins. " > > # When possible, output should be rendered on the media size > indicated; > # if not available, a larger size should be used; if not available, > # the contents of the page box should be scaled down to fit the > smaller > # page sheet. > > Given the conditionals about availability, we might want to > s/should/must/g The problem is that cheap printers are dumb. A media size is obviously available if it's loaded in the device tray; but many low-end printers don't have media size sensors, so they don't know what size is loaded where. I'd prefer to leave this as a recommendation. > # The page context has a font associated with it either by an > explicit > # use of the 'font-family' and 'font-size' properties or from the > UA's > # default style sheet. Therefore, values in units of 'em' and 'ex' > # refer to the page context's font. > > Replace with just "Values in units of 'em' and 'ex' refer to the > page > context's font." How to find that font is more accurately defined > in > the "Page Properties" section. OK > You need to add that > "If two length values are specified, the first value sets the > width > of the page box and the second value sets the height." > (or vice versa if that's what you meant). Boy, a lot of eyes have missed that one! All the way back to CSS2. ;-) Thanks! > # A5 > # The page box should be set to the size of ISO A5 media: > 148mm wide > # and 210mm high. > > Since the paragraph above defines these names as equivalent to > their > stated size in <length> values, the definitions should reflect > that. > I propose adopting the form > > | A5 > | Equivalent to the size of ISO A5 media: 148mm wide and > 210mm high. OK > It's pretty obvious what should happen with > size: 8.5in 11in portrait; > and > size: 8.5in 11in landscape; > but I just want to check what should happen with > size: 11in 8.5in landscape; > ? > Are > size: 8.5in 11in landscape; > size: 11in 8.5in landscape; > size: 11in 8.5in; > all equivalent? Yes > > # User agents SHOULD also support Media Size Self-Describing Names > as > # defined in Section 5 of [PWGMSN]. > > Why is this SHOULD rather than MUST? While other protocols require printer user agents to support these names, it's not clear that desktop user agents need that level of support, given that length pairs provide equivalent functionality. > Is there any way for the author to specify preferred paper sizes? > E.g. I want my report to print on letter paper, but A4 paper would > be OK, too. Failing that, I'll settle for legal, and failing that > whatever the printer has available. > 'size' only allows me to set one size, which becomes the absolute > paper size, and @media rules only let me specify different styles > for different sizes: they doesn't let me specify a preference for > one size over another. No, we haven't defined a means to provide preferences/fallbacks. > # The '<page-size>' names can be used in conjunction with > 'landscape' > # or 'portrait' to indicate size and orientation. > > Insert "both" immediately before "size". OK > Some Examples > ------------- > > In the second example, it might also be helpful if you stated the > size of the page area. OK > > In the third example, s/requires/requests/ since the printer will > give a smaller sheet if that's all it has. Changed to: This indicates that the page sheet size should be 8.5"x11". > Rendering page boxes that do not fit a page sheet > ------------------------------------------------- > > # There is no requirement to maintain the aspect ratio of the page > # or of any elements on the page when scaling; however, > preservation > # of the aspect ratio is preferred. > > Should that be s/preferred/recommended/? Probably. Reworded. > # Reformat the page contents, including 'spilling' onto other page > # sheets. > > Does this mean reformatting the document to print as if a smaller > page 'size' were specified, or does this mean each page will have > its own slice of overflow printed on a separate page? Unspecified; either is allowed in this case. > > Page Selectors and the Page Context > ----------------------------------- > > # Authors specify various aspects of a page box such as the > dimensions, > # orientation, and margins within an @page rule. > > I would either use the passive voice here, or s/specify/can > specify/ OK > # The OPTIONAL page name and OPTIONAL page pseudo-class constitutes > > s/constitutes/constitute/ Yep. > Page selector grammar > -------------------- > > # more strict > > stricter OK > Cascading in the page context > ----------------------------- > > # computed in an analogous manner to > > computed in a manner analogous to OK > > Either this section or the following section must specify that > properties that aren't explicitly set take their initial values > and do not inherit from any element. Added to the Cascading section. > Page Properties > --------------- > > # That is, when set in the page context, the values become the > # initial values for the margin boxes. > > This should be specified in terms of inheritance, because we > don't want to e.g. re-interpret the meaning of the 'initial' > keyword here. > > | That is, the margin boxes inherit values for inheritable > | properties from the page context. Yeah, that's better. > # Values in units of 'em' and 'ex' refer to the page context's > font. > > Is this true for margin boxes as well, or do 'em' and 'ex' on > the margin boxes refer to the margin box's font (as I would have > expected)? Should be called out separately, thanks. > # For left and right, the margin, border and padding percentages > # are relative to the width of the containing box; for top and > # bottom, the margin, border and padding percentages are relative > # to the height of the containing box. > > I don't understand this sentence at all. I've replaced it with: "For 'margin-left', 'margin-right', 'padding-left', 'padding-right', 'border-left-width', and 'border-right-width', percentages are relative to the width of the containing box; for 'margin-top', 'margin-bottom', 'padding-top', 'padding-bottom', 'border-top-width', and 'border-bottom-width', percentages are relative to the height of the containing box." Does that help? > # * The page background applies to the entire page box, > # including the page margins. > # > # The page background is painted first, and covers the entire > # page box. > > Delete the list item, and add "including the page margins" to the > first sentence of the paragraph after it. It would read a bit more smoothly that way, but the list of exceptions would be missing the special background treatment for page margins. So I'm not sure that would be an improvement. > # The origin of the page background is the upper-left corner of > # the page area. > > To be consistent with how backgrounds are handled on all other > elements, the origin should be the top left corner of the page's > padding box, not its content box. OK > # When a page break splits a box, the box's margins, borders, > # and padding have no visual effect where the split occurs. > > IIRC, this is covered by CSS2.1. If you want to state it in this > module, it needs a more appropriate context: this section is > talking about page-level boxes, whereas this statement refers to > content-level boxes. Moved to the 'Page Breaks' section. > Left, right, and first pages > ----------------------------- > > # However, to force a ':left' or ':right' first page, authors MAY > # insert a page break before the first generated box (e.g., in > HTML, > # specify this for the BODY element). > > I suggest s/MAY/can/. OK > I also suggest changing the parenthetical example to say > (e.g. by specifying it on the root element) Changed into a real example. > Content outside the page box > ---------------------------- > > # Note, however, that generating a small number of empty page boxes > # MAY be necessary to honor the 'left' and 'right' values for > # 'page-break-before' and 'page-break-after'. > > That should not be a MAY for two reasons: > 1. It's not expressing a conformance requirement > 2. It's in a non-normative note. It's certainly not a conformance requirement (fixed); but why do you think it's in a non-normative note? I think the recommendations here are normative. > # User agents MAY handle boxes positioned outside the page box in > # several ways, including discarding them or creating page boxes > # for them at the end of the document. > > The term "several ways" seems to imply a fixed list. Maybe > | This specification does not define how boxes positioned > | outside the page box are handled. Possibilities include > | discarding them or creating page boxes for them at the > | end of the document. > ? Works for me. > ~fantasai > > > >
Received on Friday, 4 May 2007 03:50:50 UTC