[css3-page] Editorial comments

Typos and other feedback about the ED dated 25 October 2010
(written more or less in the order they occur in the spec, I put them 
all in one post, as most of them probably don't deserve their own thread):

In Chapter 4.3. Page Progression :
Second paragraph reads "In documents with with a left-to-right page 
progression..." (one "with" too many).

Chapter 6. Margin Boxes states:
"Margin boxes are oriented with respect to the content and are 
independent of page orientation,..."
For one thing the word "oriented" is unfit since the text speaks of 
where a page-margin-box with a certain name is placed on a page, not how 
it is rotated.
Also and more dearly to me, I find "with respect to the content" raises 
more interrogation than it brings information. Block-progression 
direction ? Or what ? What I'm suggesting here is to use the 'magic' 
"normal reading orientation" (as used earlier in the spec). After all 
this normal reading orientation is the only 'absolute' axis to refer to 
when talking about pages with various possible orientation, content 
directionality, printing order, exotic binding edge, etc...
Not only in the above quoted statement, but generally in the spec, I 
believe this "normal reading orientation" is a precious term that which 
shouldn't be neglected.

While we're talking vocabulary, even though I confess that the choice 
"margin box" for boxes drawn inside page-box margins happens to be much 
less conflicting/confusing than I expected with the "regular" margin box 
(area of the margin-edge of any box). I still think it's playing with 
fire to start off designating something with words already used for 
something else. So I suggest as safer choice for calling the _boxes_ 
inside the _margin_ of a _page_ area: "page-margin-boxes". In any case 
the systematic use of "page-" sets well in what context of such a name 
takes place: paged media.
However, and no matter how the above is questionable, such boxes (what I 
call page-margin-boxes) are named "margin-boxes" (with a dash) several 
times. It seems to me the bare minimum for distinction from the 'other' 
margin boxes (those without a dash ;).
Now a remarkable example is Chapter 4.2. Page Backgrounds and Painting 
Order,
in which one can read in the first paragraph "Margin-boxes are painted 
over (on top of) the page box." (dashed) and in the second paragraph 
"the exact "tree order" of margin boxes is not defined..." (no dash). I 
strongly believe the dash is fully part of the term and should not be 
dropped randomly.
As a final note on this matter I'll point out the delicate case of 
Chapter 6.3. Computing Margin Box Dimensions, specially meant to deal 
with margin boxes of the margin-boxes.

In Chapter 7. Page Properties, in the specifics of properties in page 
and margin contexts:
"The page background covers the entire page box, including the page 
margins. Background images are positioned as for any other box, by 
default anchored within the page area (i.e. the page box's content box); "
Unless I'm terribly wrong background-origin's initial value makes sure 
backgrounds are (I quote) "anchored" to the padding-box. Was this 
written a long time ago in the dark age of the 'padding wars' :) ?

In Chapter 8.2. Rendering page boxes that do not fit a page sheet
details various possible user agent behaviour for fitting page boxes 
onto differently sized sheets. It extends and/or conflicts with similar 
text in Chapter 8.1, in the detailing of what user agents should do when 
a fixed-size page box can't be matched to a similarly sized sheet.
Since the two texts overlap each other, and even though they are on the 
"should" recommendation level, I think they ought to be merged as one 
piece, clearly stating what's best in well-defined circumstances. Less 
we want different browsers each have a different printing results in 
"common yet exotic cases", but we don't. ;)

At the end of Chapter 9.1. Break before/after... text state:
"User Agents must apply these properties to block-level boxes and to 
table rows, table row groups, and—in the case of 
‘page-break-inside’—table cells of block-level tables in the normal flow 
of the root element."
This specifies that page-break-before property applies to table rows and 
table row groups... Which is not what the summary for page-break-before 
says (only "block-level elements" is mentioned there).

In Chapter 9.3. Breaks inside elements: ‘orphans’, ‘widows’
the summaries for orphans and widows properties both state that their 
respective property applies to _visual_ media. It has to be a typo, as I 
can't figure why such properties would apply to visual instead of paged 
media.

Hope this is useful.
Regards.
Lobotom Dysmon

Received on Saturday, 6 November 2010 23:22:07 UTC