Re: [CSS21] The 'clear' property on table wrappers.

On 17/06/2012 19:59, Simon Sapin wrote:
> Le 17/06/2012 12:37, Anton Prowse a écrit :
>> I'm not sure what it means to apply 'counter-increment' and
>> 'counter-reset' to a box, since they're not formatting controls in the
>> typical sense and their functionality is scoped only in terms of the
>> document tree. (In particular, a table caption is always in the scope
>> of those properties when they're set on a box with display:table.) What
>> would be the difference if you "applied" them to the table box in your
>> implementation? Of course, if an implementation relied on converting
>> that scoping mechanism into one which acted on the box tree then I
>> understand why it would be necessary to apply the properties to the
>> wrapper box... but that would be an implementation detail, surely.
>
> Scoping counters on boxes rather than elements makes sense because of:
> http://dev.w3.org/csswg/css3-lists/#counters-without-boxes

Counters are affected (increased, not increased, etc) by boxes, sure. 
They're scoped by element though.

> Then it depends on an implementation details: whether counter values are
> resolved before or after table wrappers are created. Currently
> WeasyPrint does it before (so having counter properties in the list has
> no effect.) But that may change in the future: resolve during the layout
> so that elements can use page counters, and page-margin boxes non-page
> counters.
>
> The use case I had in mind was something like this:
>
> table { counter-increment: table-num }
> table:before { content: "Table n° " counter(table-num);
> display: table-caption }
> /* Still increment: */
> table.nocaption:before { display: none }

I don't really follow.  'counter-increment' is applied to the table 
element, and since the pseudo-element caption is an element-tree child 
of the table element (by definition of '::before'), that child is in the 
scope of the counter.  The issue of when and how wrappers are generated 
doesn't come into it, from the perspective of the spec.

I guess I'm just saying that it remains meaningless to me to "use" 
'counter-increment' etc on a box.  Given that some implementers do 
insist that properties apply to boxes though, I think the sensible model 
is to say that properties on elements are assumed to be transferred by 
default to the principal box of the element, and then if the element 
generates other boxes then the spec should say which elements are 
transferred to those other boxes instead.

In the case of tables, most properties are actually transferred to the 
table box rather than to the principal (wrapper) box, but I'm persuaded 
that transferring 'counter-increment' to the table box – which is what 
the spec currently says – could naively be interpreted as clashing with 
element-based scoping (due to the the caption box being outside of the 
table box's subtree), and so the spec should instead be clear that 
'counter-increment' and 'counter-reset' are used on the wrapper box.

> Anyway, I’m not sure any of this is really important for interop.

In the specific case we're discussing, I agree.  Still, if we're having 
to update the list anyway, we might as well include these two counter-* 
properties.

> My
> main point in this thread is that implementations may need to extends
> the list to be consistent with themselves. (If only with CSS3 properties.)

Yes, certainly implementations need to keep their eye on these 
situations where elements have complex box generation.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Sunday, 24 June 2012 14:18:27 UTC