W3C home > Mailing lists > Public > www-style@w3.org > June 2012

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

From: Simon Sapin <simon.sapin@kozea.fr>
Date: Tue, 12 Jun 2012 14:42:27 +0200
Message-ID: <4FD73933.9020404@kozea.fr>
To: fantasai <fantasai.lists@inkedblade.net>
CC: www-style@w3.org, MURAKAMI Shinyu <murakami@antenna.co.jp>
Le 12/06/2012 02:25, fantasai a écrit :
> 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


The current text (preferred width) is fine for horizontal text on the 
top or bottom side. Using Writing Modes terminology should fix it for 
vertical text on the left or right side. In other words, the intrinsic 
size is well-defined when the inline base direction is in the variable 
dimension.

Admittedly the use case is much less common, but what about cases where 
the *block flow direction* is in the variable dimension? Is the 
intrinsic size defined in the block flow direction?  (eg. the intrinsic 
height for horizontal text)


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

I still think that the behavior is valuable. Without it, 6.3.2 is 
under-specified. I have an example and all the gory details in 
http://lists.w3.org/Archives/Public/www-style/2012Jun/0184.html


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

Ok, another example:

@page figures { counter-increment: figure-pages }

Is the 'page' counter incremented on such pages?


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

Rephrased: 'counter-increment: foo' and 'counter-increment: none' can 
both increment the 'list-item' or 'page' counter. The only way to 
inhibit this to explicitly use this counter name:
'counter-increment: page 0'

Is this what you mean?
I guess it could work too. Actually I like it better than the alternatives.


> 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

Is css3-content still relevant? The ED (but not the WD?) has a big red 
obsoletion notice. I based WeasyPrint’s implementation of counters on 
css3-lists, even for non-list counters.

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

If I read CSS21:17.5.3 correctly, a table row is always high enough for 
its in-flow content. This is not the case for margin boxes, especially 
if the vertical is a Fixed Dimension.

Here is how I understand vertical-align on margin-boxes:

Define the "height of the content" as the used height that would have a 
block with 'hight: auto', the same width and the same content.

vertical-align: {top,middle,bottom}
Assuming a horizontal writing mode, align the {top,middle,bottom} of 
this hypothetical block (and thus the content) with the 
{top,middle,bottom} of the content area of the margin box.

Now, if the content is higher than its box, it will overflow on either 
or both sides depending on vertical-align. Is this what we want?

What about vertical-align: baseline or other values?


-- 
Simon Sapin
Received on Tuesday, 12 June 2012 12:43:04 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:55 GMT