W3C home > Mailing lists > Public > www-style@w3.org > August 2007

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

From: Grant, Melinda <melinda.grant@hp.com>
Date: Fri, 24 Aug 2007 01:50:52 -0000
Message-ID: <78A3602ADF54BA4EAB53F378BF55588B01A6FF8A@G3W0067.americas.hpqcorp.net>
To: "fantasai" <fantasai.lists@inkedblade.net>
Cc: <www-style@w3.org>

 
fantasai said:
> 
> 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

Ok, I can substitute 'preferred width' for 'max intrinsic width'; but we
don't seem to actually define 'minimum preferred width' (or 'preferred
minimum width') anywhere... There's just the suggestion that you can
find it by trying all possible breaks.  No indication of how you'd
recognize it among the possible resulting permutations.  Perhaps that's
a 2.1 issue.

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

Changed to "Properties used within page or margin contexts take their
initial values from their respective property definitions; however, user
agents must behave as though the values in the following table were
established by rules in the UA default style sheet."

<snip>

> >>      <div>
> >>        <p>...</p>
> >>      </div>
> >>      <div>
> >>        <p>...</p>
> >>      </div>
<snip - context is named pages>
> 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?

Correct. Pages with only borders are not printed.  Likewise the bottom
borders of the divs don't get printed, as the border would be the only
thing on the page.

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

Can you give me an example? (We don't want to be losing the bottom of
floats here...)

> 
> >> 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; }

Let's assume both the p and the div have contents (else, as Alex said in
[1], nothing is printed). In the first case, after the div, the UA is
ready to format the next content for a left-facing page. The contents of
the p are printed on that left-facing page; no need to generate an empty
page as the page-break-before has already been done. (Essentially the
page break after the div and the page break before the p are
'collapsed'.) In the second case, again, after the div, the UA is ready
to format content for a left-facing page. But the p requires that the
next content must be rendered on a right-facing page. So another page
break is generated, and the p is printed on a right-facing page.

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

Ah rats, right. I guess the illustrations will have to suffice to make
the point.

> ~fantasai
> 

Best wishes,

Melinda

[1] http://lists.w3.org/Archives/Public/www-style/2007Aug/0137.html
Received on Friday, 24 August 2007 01:53:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:52 GMT