W3C home > Mailing lists > Public > www-style@w3.org > April 2007

[CSS3 Page] Comments on CSS3 Paged Media (III)

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 09 Apr 2007 22:37:13 -0400
Message-ID: <461AF859.5040700@inkedblade.net>
To: www-style@w3.org

Page Boxes: the @page Rule
--------------------------

   # The content of the document is flowed into the page area.

   Should append something like "of one or more page boxes" and
   maybe says something about the rendering of these page boxes
   onto page sheets.

   @page should be in <code>

   # Margin boxed are typically used

   s/boxed/boxes/

Page Terminology and the Page Model
-----------------------------------

   # Page box ... The width and height of the page box are
   # determined by the size property. Unlike other boxes,
   # the margins of the page box are subdivided into margin boxes.

   Delete this. It is repeated from the previous section.

   # Page area ... The page area acts as a container for all the
   # boxes laid out within a given page box.

   This is not true: the margin boxes are laid out outside the
   page area.

Margin Box Definitions
----------------------

   This table seems overly-wordy and under-specific. The definitions
   for the left-* margin boxes are good. They also render the second
   column redundant. The top-* ones aren't specific enough even with
   the second column. Also, the table needs to be clear that it is
   defining the extent of the margin box's margin box. I suggest
   replacing the table with the following:

     The the margin edges[1] of each margin box are defined by the
     rectangles described below:
      [1]http://www.w3.org/TR/CSS21/box.html#box-dimensions

     top-left-corner
       A fixed-size box defined by the intersection of the top and
       left margins of the page box.
     top-left
       A variable-width box filling the top page margin between the
       top-left-corner and top-center margin boxes.
     top-center
       A variable-width box centered horizontally between the page's
       left and right border edges and filling the top page margin
       between the top-left and top-right margin boxes.
     top-right
       A variable-width box filling the top page margin between the
       top-center and top-right-corner margin boxes.
     top-right-corner
       A fixed-size box defined by the intersection of the top and
       right margins of the page box.
     left-top
       A variable-height box filling the left page margin between
       the top-left-corner and left-middle margin boxes.
     left-middle
       A variable-height box centered vertically between the page's
       top and bottom border edges and filling the left page margin
       between the left-top and left-bottom margin boxes.
     left-bottom
       A variable-height box filling the left page margin between the
       left-middle and bottom-left-corner margin boxes.
     right-top
       A variable-height box filling the right page margin between
       the top-right-corner and right-middle margin boxes.
     right-middle
       A variable-height box centered vertically between the page's
       top and bottom border edges and filling the right page margin
       between the right-top and right-bottom margin boxes.
     right-bottom
       A variable-height box filling the right page margin between
       the right-middle and bottom-right-corner margin boxes.
     bottom-left-corner
       A fixed-size box defined by the intersection of the bottom and
       left margins of the page box.
     bottom-left
       A variable-width box filling the bottom page margin between
       the bottom-left-corner and bottom-center margin boxes.
     bottom-center
       A variable-width box centered horizontally between the page's
       left and right border edges and filling the bottom page margin
       between the bottom-left and bottom-right margin boxes.
     bottom-right
       A variable-width box filling the bottom page margin between
       the bottom-center and bottom-right-corner margin boxes.
     bottom-right-corner
       A fixed-size box defined by the intersection of the bottom and
       right margins of the page box.

Page size: the 'size' property
------------------------------

   # <length>{1,2} | auto | [ <page-size> || [ portrait | landscape] ]

   This syntax does not allow <length> and 'portrait' or 'landscape' to
   be specified together. This makes sense. However the rest of the text
   seems to be written as if this were possible.

   # The size of a page box MAY either be "absolute" or "relative"

   This is not an RFC2119 MAY. s/MAY/can/

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

   Should this say that if the desired page size is not available,
   it should closest larger/smaller available size (rather than just
   any larger/smaller size)?

   # the contents of the page box should be scaled down to fit the
   # smaller page sheet.

   This definition discourages the "tiling" transfer method.
   Is that the intent?

   # Value  Description

   The rest of the CSS modules all use definition lists for value
   definitions. CSS3 Paged Media should follow this convention. [Note
   that nested <dl>s are valid HTML.]

   # auto
   #  The page box will be set to the size and orientation of the
   #  page sheet chosen by the UA.

   This definition disallows N-up printing. Is that the intent?

   # The page box is the same size as the page

   What is "the page"? Did you mean "the page sheet"? (If so the same
   problem as above applies.)

   # <length>: The page box will be set to the given absolute length.

   Perhaps s/absolute length/absolute dimensions/ ?

   # B5: The page box SHOULD be set to the size of ISO B3 media: 176mm
   # wide by 250mm high.

   B5 should set the size to the size of B5 media, not B3.

Positioning the page box on the sheet
-------------------------------------

   # The user agent MAY wish to consult the user in this regard.

   s/wish//

Page Selectors and the Page Context
-----------------------------------

   # Properties for the page box are specified within the page context.

   Properties declared within the page context apply to the page box.

page selector grammar
---------------------

   # The value 'auto' may not be used as a page name and MUST be treated
   # as a syntax error.

   s/may not/MUST NOT/

Cascading in the page context
-----------------------------

   # Page contexts cascade

   This is the only normative text that says that declarations in @page
   rules cascade. It's a tucked inside an example paragraph. We should
   probably be clearer about property declarations inside the page
   context -- including those inside margin box contexts within the
   page context -- cascade.

Page Properties
---------------

   # These properties can be used in the page context to style the content
   # of margin boxes:

   This is a bit inaccurate: they can also affect the styling of the page
   page box itself, since these properties can affect the interpretation
   of box properties. ('color' affects 'border-color', and the font properties
   affect 'em' and 'ex' units) CSS2.1 says that 'color' applies to all elements.
   CSS3 Page can just say that these properties also apply to the page box.

   # Percentage values on the margin, padding and border properties are
   # relative to the dimensions of the containing box (defined by the
   # 'size' property in the page context). 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.

   a) 'border' doesn't take a percentage value

   b) It's not very clear how this rule applies to margin boxes. Using symmetry
      to reduce the number of cases, I see three different things to consider
        - percentages on corner boxes
        - percentages on top/bottom values for boxes in the top/bottom margins
          and on left/right values for boxes in the left/right margins
        - percentages on left/right values for boxes in the top/bottom margins
          and on top/bottom values for boxes in the left/right margins

   # The 'width' and  'height' properties do not apply to the page box
   # (and SHOULD be treated as if they were set to 'auto').

   If they don't apply, it doesn't matter what value the UA treats them as,
   so that last part should be deleted.
   However, if you want them to /compute/ to 'auto', then you must specify
   that. (I don't think it would gain us anything.)

   # The page background applies to the entire page box, including the page
   # margins.

   s/applies to/covers/ to be consistent with CSS2/CSS3 background wording.

   # A margin-box background is painted over (on top of) the page background.

   What order do margin box backgrounds paint if they overlap (e.g. due to
   negative margins)?

   # The root element then paints the canvas within the page area

   But not the page padding area?

   # which contains the portions of the root element formatted for a single page

   s/single/given/

   # The origin of the page background is the upper-left corner of the page area.

   This does not define what happens when the background is anchored in the
   bottom right corner. I suggest replacing it with

    | The page context's background image is positioned and anchored within
    | the page's padding box.

Left, right, and first pages
----------------------------

   # When printing double-sided documents, the page boxes on left and right
   # pages MAY be different.

   I don't think was intended as an RFC2119 MAY, so s/MAY be/are often/

   # Authors MAY also specify style for the first page of a document with
   # the ':first' pseudo-class:

   This sentence puts no normative requirements on the UA about what it should
   do with such declarations.

Content outside the page box
----------------------------

   # User agents SHOULD avoid generating a large number of empty page boxes

   s/empty page boxes/content-empty pages/

Dimension of margin box
-----------------------

   # If the above constraints are contradictory ("over-constrained"), then
   # constraint 7 is replaced by 7a:
   # 7a. If the computed values of the left box's left and right margins
   # are 'auto and not 'auto', respectively, then the used value of the
   # right margin is its computed value. If the computed values of the
   # right box's left and right margins are not 'auto' and 'auto',
   # respectively, then the used value of the left margin is its computed
   # value. This effectively means that the specified right margin of the
   # left box is ignored if necessary, and ditto for the left margin of
   # the right box.

   I think the intent is to say
     "If the above constraints are contradictory ("over-constrained") then
     the right margin of the left box and the left margin of the right box
     are treated as if their computed values were 'auto'."
   The last sentence expresses this wish, but the previous sentences in 7a
   are merely repeating what 7 says.
   Using this wording also allows you to compress 6 and 7 to
    6. The used values of the margin boxes' left and right margins are their
       respective computed values unless the computed value is 'auto'.

Margin boxes and default values
-------------------------------

   The 'vertical-align' property is defined in terms of inline content.
   This section seems to assume that vertical-align behaves for margin
   boxes like it does for table cells. However, there is no normative
   prose to that effect.

   'none' is not currently defined as a 'content' value except in CSS3
   Generated Content. CSS2.1 uses 'normal', and 'normal' is a valid
   computed value in CSS2.1-- but not in CSS3 Generated Content. Also
   it seems like the desired behavior is that given by 'inhibit'.
   Perhaps the CSSWG needs to discuss css3 'content' and nail its values
   down.

Page Breaks
-----------

   This paragraph is written as if the following rules for page-break-* were
   recommended or allowed (should/may), but not required. Is that the intent?

Break before/after elements
---------------------------

   # so that the next page is formatted as a left page.

   I suggest replacing with
     "so that the page after the break is formatted as a left page."
   to be clearer about where the "next page" starts in the content
   flow.

Using named pages: the 'page' property
--------------------------------------

   # If a block box with inline content has a 'page' property
   # that is different from the preceding block box with inline
   # content, then one or two page breaks are inserted between
   # them, and the boxes after the break are rendered on a page
   # box of the named type.

   So, how do we know if one page break is inserted or two?

Breaks inside elements: 'orphans', 'widows'
-------------------------------------------

   # The 'orphans' property specifies the minimum number of line
   # boxes in a block element that  MUST be left at the bottom
   # of a page.

   I suggest appending "when a page break occurs inside the block"
   to this sentence (and to the next one about 'windows').

   # If a block contains fewer lines than the value of 'widows'
   # or 'orphans', the rule is relaxed.

   That means that if I set "orphans: 5" and I have a 5-line block
   that falls at the bottom of the page, I cannot break within that
   block--but if I have a 3-line block falls at the bottom of the
   page, I can break within that block. Perhaps something along the
   lines of
     "If a block contains fewer lines than the value of 'windows'
     or 'orphans' then all lines in the block must stay together on
     one page."
   would make more sense?

   Another thing to consider is that the rules for windows and
   orphans are described more succinctly and, more importantly, more
   accurately in the "Allowed page breaks" section. It would be
   better to avoid any conformance statements in this section in
   deference to the next one.

Orienting an Image on the Page: the image-orientation property
--------------------------------------------------------------

   # image-orientation ... Inherited: N/A

   Inheritance for this property *must* be specified. The only
   property that can get away with not specifying it is the 'size'
   property because the page box has no parent and it applies to
   nothing else. But images usually have parents, and it must be
   defined whether they inherit this property from their parents
   or not.

   # Computed value: specified value modulo full circle value

   This works for degrees, but it doesn't make sense for 'intrinsic'.
   For 'intrinsic', the computed value should be the specified value.

   # This implies, for example:

   I don't think this needs to be a non-normative example.

   # The height (width) property applies to the vertical (horizontal)
   # dimension of the image, after rotation.

   I suggest s/applies/and related calculations apply/

   If 'auto' is the same as '0deg', why do we have 'auto'? Can we
   drop this value in favor of '0deg'?

   # auto
   # The image will be set to the orientation of the page.

   As someone without much print technology background, I think this
   description is a bit confusing. Less subjectively, I think the
   definition should avoid paged media terminology since it applies
   to other visual media as well.

   # <angle>
   #  [ 0deg | 90deg | 180deg | 270deg | -90deg | -180deg | -270deg ]

   If this is meant to restrict 'image-orientation' to those values,
   it needs to be much more explicit about it. Also, listing the values
   like that forbids the use of grad or rad values.
     http://www.w3.org/TR/CSS21/aural.html#q3

The 'image-scaling' property
----------------------------

   # The 'image-scaling' property specifies how the contents of a
   # replaced element should be scaled within the box established
   # by its height and width.

   s/should be/are/ ?

The 'image-position' property
-----------------------------

   # Computed value: specified value

   This should be "for <length> the absolute value, otherwise a percentage"
   as for 'background-position' in CSS2.1.

   # auto

   I don't think we need an 'auto' value here. Might be useful for
   background-position, but I can't think of a use case here.

   The description of the image-position values is poor, but that problem
   comes from the definition of 'background-position' in CSS2.1 and CSS3
   Backgrounds. :/

   # The computed value is the same as the specified value; i.e., the
   # keywords are not replaced by percentages and the percentages are not
   # replaced by something else.

   This should be dropped and the keywords (except auto if it's kept)
   should compute to percentages, just as for background-position.

I suggest combining the image-scaling, image-position, and image-orientation
properties under one major section, and giving them each a subsection.

The capitalization of headings in this spec is inconsistent.

~fantasai
Received on Tuesday, 10 April 2007 02:39:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:50 GMT