- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 11 Jun 2012 18:49:44 -0700
- 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 UTC