Re: [CSS21] 17.4: properties on outer & inner table boxes

On 06/11/2010 22:14, Peter Moulder wrote:
> On Sat, Nov 06, 2010 at 09:37:05PM +0100, Anton Prowse wrote:
>
>> I don't think this is an issue since, as I understand it, the table
>> box doesn't have a 'display' property.  The value of the 'display'
>> property of an element determines (sometimes in conjunction with
>> other information) the types of boxes that the element generates.
>> The boxes themselves don't necessarily correspond exactly to the
>> values of the 'display' property.  A table box is outwardly
>> block-level and inwardly table, for example.
>>
>> When the spec sloppily refers to blocks, inline blocks, inline
>> tables, tables, list items etc in a context where it's really
>> talking about boxes, the only sensible assumption is that it's
>> referring to the principal box of the element of that type, so the
>> issue above doesn't arise.  Of course, principal box is defined in
>> generality either, but is defined enough to exist for table and
>> inline table elements.

(That should have been "isn't defined in generality", of course.)

>> I guess what I'm saying is that this area is sloppy, but I don't
>> think there's any unique difficulty with the case that you describe.
>> Of course, I'd like to see the spec fixed in full generality....
>
> I've no objection to taking that approach (it might work well for the
> principal box of a display:list-item element, for example, and I agree that
> one might question how meaningful it would be to describe the inner table
> box as having display:table as I suggested above), though there would need
> to be some changes to the text if we were to adopt it.  For example, §17.4
> para 3 currently starts with "The outer table box is a 'block' box if the
> table is block-level, and an 'inline-block' box if the table is
> inline-level", even though it's never generated by either a display:block
> element or display:inline-block element.

Since "block box" already has a well-defined meaning beyond merely being 
the principal box of an element with display:block, I agree that I 
should have excluded it from my list.

For me, 17.4 needs changing in respect of the 'inline-block' thing:

s/'block' box/block box/
s/'inline-block' box/inline-level block container box/

I suspect this was merely an oversight when recently introducing the 
more comprehensive box terminology.

> Also, §9.2 isn't really consistent with the above approach at present: it
> talks of "A box's type" (type singular), which I would tend to see as more
> consistent with "type" referring to display value than as the combination
> of whether it's block-level or inline-level and whether it's a block
> container or ...  (Though in any case, I have always been uneasy with
> the existing text "a box's type" when nothing in the text says what a box's
> type is.  It turns out that this sentence isn't needed normatively, but I'd
> still like to have this sentence changed so that readers like me don't
> spend time trying to work out what the sentence means.)

Indeed, the whole paragraph in 9.2 is woolly.  But it doesn't actually 
say anything actionable anyway so I suppose that this particular 
editorial issue is unlikely to be addressed.

> I'm also inclined to think that the talk of "..., list items etc. in a
> context where it's really talking about boxes" is something of an obstacle.
> Though maybe we could get around it with a single sentence in §9.2
> explaining this, ending with "except that the outer table box is ..." or
> similar.

Given that I doubt the elements vs boxes issue is going to be resolved 
for CSS21, I too am in favour of at least trying to cover our backs with 
an extra sentence or two in 9.2 to acknowledge the woolliness and send 
the reader down the right path.

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

Received on Saturday, 6 November 2010 21:53:53 UTC