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

Grant, Melinda wrote:
>  
>>    # Unlike other boxes, the margins of the page box are subdivided
>>    # into margin boxes.
>>
>>    This repeats an earlier statement in the previous section.
> 
> The terminology section is currently misplaced.  Once it's moved, I
> think the redundancy will be less noticeable and more valuable.  I've
> reworded this occurrence to: "Running headers and footers can be put
> into margin boxes."

I think leaving it out would be fine. It isn't particularly necessary
for defining 'page box'.

>>    # In the simplest case, the page box is congruent with the page
>>    # sheet.
>>
>>    Which page box is congruent with the page sheet? Its margin box,
>>    border box, padding box, or content box?
> 
> Well, as with other boxes, the margin box is congruent with the box's
> edge... So the page's margin box is congruent with the page box's
> edge...  But we're not talking about any of those boxes here, we're
> defining a new term, the 'page box'.  Is that confusing/not clear?

Hmm, how about changing
   In the simplest ... within the margins.
to
   As with all CSS boxes, the page box consists of margin, border,
   padding, and content areas. In the simplest and usual case, the
   page box's margin box is congruent with the page sheet. (See the
   transfer possibilities in the Introduction... orientation.)
That way we're very clear about how the page box and the page sheet
relate in the simplest case, but we're also making sure we introduce
the fact that it has a margin before using it in that definition. :)
Maybe also link "all CSS boxes" to http://www.w3.org/TR/CSS21/box.html

>>    # page margin / page border / page padding
>>
>>    These terms are not defined anywhere.
> 
> No. Once the page box is defined and the box model derivation given,
> aren't margins, border, padding already defined by the box model?  Would
> it really add clarity to say that the page margin is the margin (link to
> http://www.w3.org/Style/Group/css2-src/box.html#box-dimensions) for the
> page box (link to page box dfn)?  Or what else would you like to see
> added here?

True. I guess its ok as it is.

> I've reworded the sentence to: "Some of these depend upon factors not
> specified by this module, such as the major writing direction and the
> media type.

Ok, cool.

>>    # The major writing direction for the document is determined by
>>    # the UA. If the UA supports the 'direction' property from CSS2
>>    # or the CSS 3 Text Module it MUST determine it using the value
>>    # of that property on the root element.
>>
>>    I think we need to be a bit more specific here, since in vertical
>>    text the 'direction' property is irrelevant for determining page
>>    order: the block progression direction is used instead. So
>>      If text is laid out horizontally,
>>        the major writing direction is the same as the inline 
>>        progression direction (determined by 'direction').
>>      If text is laid out vertically,
>>        the major writing direction is the same as the block 
>>        progression direction (determined by a new property from CSS3
>>        Text Layout)
> 
> Great!  I renamed 'major writing direction' to 'page progression' to be
> more consistent with 'block-progression'; I suppose we could need to add
> a 'page-progression property some day.  I've reworked the pertinent text
> a bit, and added the above.  Check out the next version and see if it
> addresses your concerns.

Ok, looks pretty good.
The sentence
   # Whether the first page of a document is a ‘:left’ or a  ‘:right’ page
   # depends on the page progression of the document.
isn't quite true because of
   # To force a  ‘:left’ or ‘:right’ first page, authors can insert a page
   # break before the first generated box.
so maybe add a "by default" or something to that first sentence.

Tying a normative statement to CSS3 Text Layout could become problematic
in Paged Media's quest for REC status, so you might want to state the
horizontal/vertical principles generally first and then get specific
about properties.

One way of doing that would be
   1. Move "If the UA supports ... as follows" to after the two <li>s
      and remove "as follows".
   2. Remove the parentheticals in the <li>s.
   3. Add this paragraph afterward:
        If the UA supports the 'direction' property from CSS2.1, it
        *must* determine the inline progression direction from that
        property on the root element. If the UA supports the
        'block-progression' property from CSS3 Text Layout, it must
        determine the block progression from that property.

Then if the normative reference to CSS3 Text Layout becomes the only thing
holding up the spec from progressing, you can drop that last sentence.

I'd also consider moving "The page progression direction is determined"
etc back into the definition of page progression and join up the sentences
about :left and :right into one paragraph.

>>    How does this module consider these concepts when the binding edge
>>    is the top edge of the booklet instead of a side edge? Left/right-
>>    based styling doesn't really make sense in that case.
> 
> The module does not address the short-edge (horizontal) bindings use
> case. I don't know the historical rationale behind this.  Arguably
> 'leading' and 'trailing' or similar terms might have been preferable.

Ok.

>> Page Size
>> ---------
>>
>>    It is not clear which box's size is being set here because what rectangle
>>    exactly corresponds to the term "page box" is not defined. 
>>    I assume it is the same rectangle as the page margin box, but that must be 
>>    stated somewhere.
> 
> Apparently it would be helpful if I expanded the definition to include
> something like:
> "As for all CSS boxes, it contains margin, border and padding areas."
> If I change the definition as follows, does it clear things up?

Yep, I think that solves the problem. :)

>>    # When possible, output should be rendered on the media size 
>> indicated;
>>    # if not available, a larger size should be used; if not available,
>>    # the contents of the page box should be scaled down to fit the 
>> smaller
>>    # page sheet.
>>
>>    Given the conditionals about availability, we might want to
>>      s/should/must/g
> 
> The problem is that cheap printers are dumb.  A media size is obviously
> available if it's loaded in the device tray; but many low-end printers
> don't have media size sensors, so they don't know what size is loaded
> where.  I'd prefer to leave this as a recommendation.

Ok

>>    # User agents SHOULD also support Media Size Self-Describing Names 
>>    # as defined in Section 5 of [PWGMSN].
>>
>>    Why is this SHOULD rather than MUST?
> 
> While other protocols require printer user agents to support these
> names, it's not clear that desktop user agents need that level of
> support, given that length pairs provide equivalent functionality.

I think we should discuss this with the WG then, because it's basically
defining optional aliases for a property, which I'm not sure is a good
idea. What protocols require support for these names *in CSS*?


>>    # For left and right, the margin, border and padding percentages
>>    # are relative to the width of the containing box; for top and
>>    # bottom, the margin, border and padding percentages are relative
>>    # to the height of the containing box.
>>
>>    I don't understand this sentence at all.
> 
> I've replaced it with:
> "For 'margin-left', 'margin-right', 'padding-left', 'padding-right',
> 'border-left-width', and 'border-right-width', percentages are relative
> to the width of the containing box; for 'margin-top', 'margin-bottom',
> 'padding-top', 'padding-bottom', 'border-top-width', and
> 'border-bottom-width', percentages are relative to the height of the
> containing box."
> Does that help?

Hm, if that was confusing me then I'm just dumb. I don't quite remember, but
I strongly suspect I was more confused about the containing box. So I think it
was fine to leave left/right unexpanded (although I'd add "values" after
"left and right" and again after "top and bottom"), but containing box needs
to be better defined. So the problem is
   - containing box for page box isn't all that clear, but it's at least
     implied there
   - containing box for margin boxes isn't defined at all
     (the spec thinks it's defined in Dimension of Margin Boxes, but
      that's actually defining the margin boxes' widths and margins
      and assumes percentages can be resolved against something else)
The margin box model generally needs work, though.

>>    #     * The page background applies to the entire page box,
>>    #       including the page margins.
>>    #
>>    # The page background is painted first, and covers the entire
>>    # page box.
>>
>>    Delete the list item, and add "including the page margins" to the
>>    first sentence of the paragraph after it.
> 
> It would read a bit more smoothly that way, but the list of exceptions
> would be missing the special background treatment for page margins.  So
> I'm not sure that would be an improvement.

Ok, then maybe remove "and covers the entire page box" from that second
sentence so it's not repeated?

>>   Left, right, and first pages
>> -----------------------------
>>
>>    # However, to force a  ':left' or ':right' first page, authors MAY
>>    # insert a page break before the first generated box (e.g., in HTML,
>>    # specify this for the BODY element).
>>
>>    I suggest s/MAY/can/.
> OK
>>    I also suggest changing the parenthetical example to say
>>      (e.g. by specifying it on the root element)
> 
> Changed into a real example.

Change 'html' to ':root' and then s/an XHTML/a/ -- this avoids
needing to know that <html> is the root element of an XHTML document.

>> Content outside the page box
>> ----------------------------
>>
>>    # Note, however, that generating a small number of empty page boxes
>>    # MAY be necessary to honor the 'left' and  'right' values for
>>    # 'page-break-before' and  'page-break-after'.
>>
>>    That should not be a MAY for two reasons:
>>      1. It's not expressing a conformance requirement
>>      2. It's in a non-normative note.
> 
> It's certainly not a conformance requirement (fixed); but why do you
> think it's in a non-normative note? I think the recommendations here are
> normative.

The sentence says "Note". There's no strong reason for that sentence to
be normative, so that's fine but s/may/might/ or s/may/is sometimes/
could be appropriate here.

~fantasai

Received on Monday, 7 May 2007 21:10:48 UTC