- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 09 Apr 2007 22:37:13 -0400
- 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 UTC