W3C home > Mailing lists > Public > www-style@w3.org > November 2011

Re: [css3-*] [css3-box] Box Tree terminology for CSS3 specs

From: Anton Prowse <prowse@moonhenge.net>
Date: Wed, 23 Nov 2011 21:59:45 +0100
Message-ID: <4ECD5EC1.4050000@moonhenge.net>
To: www-style@w3.org
On 23/11/2011 00:09, L. David Baron wrote:
> On Tuesday 2011-11-22 12:31 -0800, fantasai wrote:
>> So that we can disentangle boxes from elements and logical boxes from box
>> pieces in our CSS3 specs, I'm proposing the following terminology (borrowing
>> from Rossen's work on css3-break):

I'm happy with the idea of disentangling these concepts (of course), but 
I share David's concerns about pseudo-elements.

>> box
>>    A box in the box tree. Boxes also have properties associated with them.
>> box fragment
>>    A piece of a box that has been broken across line/page/column/etc breaks.
> Because of the non-tree-like pseudo-elements, a box doesn't
> necessarily have a unique set of properties.  (A box fragment does,
> though -- I think -- though only as a result of ::first-letter and
> ::first-line working in opposite ways.)

Indeed.  I will be giving some thought as to how frequently we're 
concerned with the box fragment tree as opposed to the box "tree", and 
to how to avoid requiring cumbersome language in the specs.

>> Tree relationships "child", "sibling", "parent" operate on the box tree,
>> not on the element tree, unless otherwise specified (e.g. "child element").
>> An out-of-flow box's parent is its in-flow parent, not its containing block.
> I'm a little uncomfortable saying that one thing is the default.  It
> might be better to say that it should normally be specified in all
> cases, but specifying isn't necessary in cases where it's clear
> (at least when those cases would otherwise involve repetition).

Agreed.  It's not yet clear to me that having a default would aid clarity.

Anton Prowse
Received on Wednesday, 23 November 2011 21:00:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:52 UTC