W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: [css3-page] Editorial comments

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 11 Jun 2012 18:49:44 -0700
Message-ID: <4FD6A038.40807@inkedblade.net>
To: Lobotom Dysmon <lobotom.da.dismon@free.fr>
CC: www-style list <www-style@w3.org>
On 11/06/2010 04:21 PM, Lobotom Dysmon wrote:
> 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).

OK, fixed.

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

How about "Margin boxes are positioned with respect to the page area" ?

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

Hmm.. I suppose calling them "page-margin boxes" should be okay.
I've filed that as ISSUE-258:
   https://www.w3.org/Style/CSS/Tracker/issues/258

> 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' :) ?

lol, I think in the ancient days it /was/ anchored to the content box.
But you're right, it should be padding box.

http://www.w3.org/TR/CSS1/#background-position

> 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. ;)

Hmm, good catch. I've removed the text in 8.1 in favor of the text in 8.2;
let me know if you have any further suggestions.

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

Fixed.

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

Fixed.

Thanks for the review!

~fantasai
Received on Tuesday, 12 June 2012 01:50:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:55 GMT