Re: [css3-page] preferred height, containing blocks, counters, vertical-align, size, links

On 12/09/2011 05:21 AM, Simon Sapin wrote:
> Hi,
>
> Section 6.3.2. Margin Box Variable Dimension Computation Rules of the current editor’s draft mentions the preferred minimum
> width and preferred width.
>
> It also says that the used values for left-* and right-* margin boxes are established by the same rules, with (among others)
> 'width' replaced by 'height'. Does that mean that these boxes have a preferred minimum height and a preferred height? How and
> where is that defined?

Yes. The preferred minimum height and preferred height are equivalent,
and they are the content height as computed for 'height: auto' blocks.
Probably this whole section needs to be switched over to the new terminology
in Writing Modes Appendix D:
   http://www.w3.org/TR/css3-writing-modes/#intrinsic-sizing
I've filed this as ISSUE-256 so I don't forget.
   https://www.w3.org/Style/CSS/Tracker/issues/256

> Also, example XVIII says
>
> """
> Because there are no center cell contents, the extent of the top-left is allowed to cross the center of the page box. As the
> intrinsic width of the top-left contents is approximately twice the intrinsic width of that of the top-right, the top-left
> margin box is approximately twice as wide as the top-right margin box.
> """
>
> but I can’t find a rule to back the described behavior.

Hm, neither can I. I'll just delete the sentence about the intrinsic sizes there ...

> Section 4 Page Model should refer to section 8 Page Size to define the containing block of page boxes.

Good point. I've shifted the paragraph about containing blocks up into Section 4.

> Section 7.1 Page-based counters
>
> The 'page' counter is incremented implicitly on each page, but example XIX also explicitly uses 'counter-increment: page'. Is
> the counter incremented twice for each page in this case?

No, just once. The spec says 'page' is affected by 'counter-increment' and
'counter-reset' just like any other counter. The question, as you point out
below, is what happens when those properties are set to 'none'.

> Maybe we want the page counter to behave the same as the list-item counter in the latest Lists 3 editor’s draft: the implicit
> increment only happens if the counter-increment is not otherwise specified. This can be implemented with an 'auto' initial
> value, for counter-increment but that value should serialize to 'none' (the real initial value in CSS 2.1) when authors
> request the computed value.

Either that, or 'none' is really 'auto', and to turn off an implicit counter,
you have to specify it explicitly.

I'll have to escalate that suggestion up to the WG, since we'll have to coordinate
with css3-content and css3-lists. Filed as ISSUE-257
   https://www.w3.org/Style/CSS/Tracker/issues/257

If we go with the 'auto' option, I think it should only compute to 'none' on elements
other than @page and list-items; otherwise it should probably compute to whatever we're
actually doing.

> Section 7.2 a UA stylesheet with the vertical-align property set for each margin box. However, this property does not apply to
> blocks, only to inlines and table cells. Do we want margin boxes to behave like table cell for the purpose of vertical-align?

Yes, that's exactly the intent. Let me clarify that...
   | On margin boxes, the ‘vertical-align’ property behaves as specified for
   | table cells [1]. It always performs alignment in the vertical dimension,
   | regardless of writing mode.
   | [1] http://www.w3.org/TR/CSS21/tables.html#height-layout

Murakami-san, I think making vertical-align on margin boxes independent of
writing mode makes the most sense, especially given the default values
required for ua.css. But, what do you think?

> Section 8.1 Page Size:
> Definition of the 'size' property: "This property specifies the target size and orientation of the page box."
>
> This however, contradicts the first paragraph of the same section. That one says that the 'size' property only specifies the
> containing block of that box, and size is calculated is for the width of non-replaced blocks. That is, based on the 'width'
> and 'height' properties as well as margins, borders, padding.
>
> In the later case, the page box may end up bigger or smaller that what the 'size' property specifies.

Fixed.

> Finally, this document has many links such with the href starting with /TR/CSS21/. These links are broken on
> http://dev.w3.org. The absolute URL should be used instead: http://www.w3.org/TR/CSS21/

Fixed.

Thanks for the comments!

~fantasai

Received on Tuesday, 12 June 2012 00:26:23 UTC