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

On 16/06/2012 13:13, Simon Sapin wrote:
> Le 16/06/2012 12:20, Anton Prowse a écrit :
>> That said, in a world where properties can only act on one or other of
>> the two boxes, the use case for having 'clear' (and 'z-index') act on
>> the table wrapper box is a lot stronger than that for having it act on
>> the table box!
>
> To follow up on this: I made the change in WeasyPrint and add these to
> the list that applies to table wrappers.
>
> clear, counter-increment, counter-reset, opacity, page-break-before,
> page-break-after, page-break-inside, transform, transform-origin,
> vertical-align, z-index.

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.

> Note that line-height does not need to be in this list as it is
> inherited.

Agreed.


> Actually what to do with inherited properties is implicit in
> the spec.

Indeed, I don't see any indication in the spec of how inherited 
properties are used on boxes, which correlates with the fact that I 
think deciding which box to apply them to is an implementation detail: 
the choice has no discernible effect in this particular case, since a 
table wrapper box cannot have any anonymous children other than the 
table box.

> Here is how I interpret it:
>
> The table wrapper box and table box are either both generated from the
> same table element, or are both anonymous. When there is a table element:
>
> * Both boxes get the element’s computed value for properties that are
> inherited
> * The table wrapper box gets the element’s computed value for
> properties in the list mentioned above, the initial value for
> other properties
> * The table box gets the initial value for properties in the list
> mentioned above, the element’s computed values for other properties

That's how I interpret it too.

I note that, to me at least, "using the computed value of a property on 
a box" is just an editorial device to handle the fact that, whilst it's 
only the /effect/ of the property that acts on a box, the spec contains 
various algorithms which are described in terms of the computed value of 
element properties together with an over-simplistic assumption of a 
one-to-one correspondence between elements and boxes so that those 
properties seem to apply directly to the boxes.  It's basically an 
admission that the algorithms aren't as rigorous as they should be!  (I 
don't like this device at all, but I recognize its convenience as a 
work-around in this particular spec.)

> The main difference between the two boxes are the captions, which are
> children of the table element: this should be a guiding principle to
> decide which properties to include in the list. In particular, I think
> that properties that affect their descendants through means other than
> inheritance (like opacity) should be included.

For me, a simple guiding principle is that the principal box [roughly: 
the outermost one] of the table "structure" is the wrapper box, and so 
properties which influence the relationship between the structure and 
the world around it should apply to the wrapper box.  Other properties, 
when non-inherited, should typically apply to the table box, since 
caption boxes can styled independently.

To be honest though, I'm not sure that there's really any golden rule 
here.  The reason that the (non-inherited) 'border' property applies to 
the table box and not to the table wrapper box, for example, is merely 
because that's what matches the most common typographic need.

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

Received on Sunday, 17 June 2012 10:37:29 UTC