Re: [CSS3 Page] Comments on CSS3 Paged Media (II)

Grant, Melinda wrote:
> 
>>    "min intrinsic width" and "max intrinsic width" are not defined.
> 
> They don't appear to be defined in 2.1. Want to take a stab?

I believe "min intrinsic width" == "minimum preferred width" and
"max intrinsic width" == "preferred width" as defined in
   http://www.w3.org/TR/CSS21/visudet.html#float-width

>> Margin boxes and default values
>> -------------------------------
>>
>>    Additionally, we should discuss whether you indeed want to change
>>    their initial values (and hence the meaning of the 'initial' keyword,
>>    which we may not want to mess around with) or rather to RECOMMEND
>>    that these be the UA defaults.
> 
> I think I'll try David's favorite, 'The UA must behave as though...'
 >
 > "User agents must behave as though the values in the following table
 > were established by rules in the UA default style sheet. All other
 > properties take their initial values from their respective property
 > definitions."

Ok, in this case you should remove the sentence "All other properties ...
definitions" because it talks about 'initial values', which we are not
changing, and that sentence kinda implies that we might be.

>> Populating margin boxes
>> -----------------------
>>
>>    # A margin box is instantiated if a margin context is established
>>    # and one of the following conditions holds:
>>    #
>>    #  * The computed value of 'content' is not 'none'.
>>    #  * The properties 'width' and 'height' are set in the margin context.
>>
>>    This condition should be collapsed to
>>       | A margin box is instantiated if the computed value of its
>>       | 'content' property is not 'none'.
>>
>>    This is consistent with ::before and ::after, and if the author
>>    wants an empty margin box all they have to say is
>>       @margin-box { content: ""; }
> 
> Checking with implementers... If there's no complaint, I'll make the
> change.

Ok

>>    # Note that a counter value could be updated many times on a given
>>    # page. The value of the counter at the beginning of page processing
>>    # MUST be used by default.
>>
>>    Since "page processing" is not defined, it is not clear what "the
>>    beginning of page processing" means.
> 
> Replaced by our 'new and improved' counter rules.

Yay~ :)

>> Using named pages
>> -----------------
>>
>>    # 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.
>>
>>    I'm not quite understanding this.
>>
>>    What happens in the following example
>>      <div>
>>        <p>...</p>
>>      </div>
>>      <div>
>>        <p>...</p>
>>      </div>
>>    if all elements have different named values for 'page'? Is there
>>    a break between the beginning of the <div> and its child <p>?
>>    Is there a break between <div> as well? What happens if I have
>>    sibling blocks that do not have content, but are otherwise visible
>>    due to borders etc: does this mean I can't use named pages 
>> for them?
> 
> Well the short answer is that the div's are rendered on div-styled pages
> and the p's are rendered on p-styled pages.  The longer answer is that,
> since the div's don't contain anything but the p's (assuming no
> generated content), no div-styled pages are generated. (But the fact
> that the p is inside a div should cause a page break between the two
> p's.  A good test case...) The content-empty page thing says that, if
> your sibling blocks are the only thing on the page, the page doesn't get
> printed.  (Trying to minimize the generation of empty pages, which is a
> big cause of user frustration with web printing.)

I don't think it's clear what happens in this case if I put borders on
all four elements. Where are the page breaks and how do you know? If the
content-empty page suppression is what's keeping me from getting blank
pages, do the divs' top borders not get rendered because they are on empty
pages?

>> Allowed page breaks
>> -------------------
>>
>>     | When a page break occurs here, it replaces any clearance and
>>     | the used values of any adjoining margins are set to '0'.
> 
> If the used values of the margins are set to '0', how can there be any
> clearance?

Clearance is independent of margins. It doesn't affect the margins
themselves, only whether they collapse.

>> Forced page breaks
>> ------------------
>>
>>    It does not appear to be defined whether in
>>      <div></div>
>>      <p></p>
>>    with
>>      div { page-break-after: left; }
>>      p { page-break-after: always; }
>>    or
>>      div { page-break-after: left; }
>>      p { page-break-after: right; }
>>    the P's contents are required to appear on a left page, right
>>    page, or any page.
> 
> Hmm, well section 5.1 says 
> "left
>     Force one or two page breaks before (after) the generated box so
> that the next page is formatted as a left page."
> So after the div, one page break would occur if the div were on a right
> page, else two page breaks would occur.  Then the p would be rendered on
> a left-facing page.  Since the next page is a right page anyway, both
> your style rule sets would behave the same.
> What am I missing?

Nothing, I think I have a typo there. :) Try
       div { page-break-after: left; }
       p { page-break-before: always; }
     or
       div { page-break-after: left; }
       p { page-break-before: right; }

>> image-scaling
>> -------------
>>
>>    # The contents of a replaced element with an intrinsic aspect
>>    # ratio (which may be derived from intrinsic dimensions) are
>>    # scaled as follows, and are applied to the used height and
>>    # used width of the replaced element's box.
>>
>>    I think the second part of that sentence "and are applied ...
>>    box" should be deleted. It's not clear what it means, and it
>>    might be contradicting later parts of the text.
> 
> I think it may be trying to make clear that the used height/width aren't
> modified by the scaling operation, which is an easy-to-miss point on
> first read of this property.  I've deleted the 'and' clause, and added
> the following after the description of values, right before the
> explanation of overflow:
> "The used height and width of the replaced element are not affected by
> the scaling operation."

Except that's not true, the used height and width are affected in the
'contain' and 'cover' cases if the 'width' and 'height' are both 'auto'
and the appropriate min/max constraints exist.

~fantasai

Received on Thursday, 23 August 2007 04:49:31 UTC