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

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

From: L. David Baron <dbaron@dbaron.org>
Date: Tue, 22 Nov 2011 15:09:06 -0800
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <20111122230906.GA12415@pickering.dbaron.org>
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):
> 
> element
>   An element in the document tree or a pseudo-element. Elements have properties
>   associated with them. An element generates zero or more boxes, but typically
>   only one. Of the boxes generated, one of them is the principal box.

I'm uncomfortable including pseudo-elements in the definition of
element.  It's particularly difficult for the pseudo-elements
(::*-line, ::*-letter, ::selection) that are not tree-like.

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

> Layout specs should be mostly written in terms of boxes, not elements. If a spec
> talks about elements, the editor should be very careful to check that the spec
> should indeed be talking about elements, and not about boxes.

Agreed.

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

We also need to talk about the tree built from containing-block
relationships (e.g., for 'overflow').

> I also suggest (separately) that the Applies-to: line of a spec describe the
> types of boxes the property applies to rather than the types of elements the
> property applies to. So "All elements" would change to "All box types", which
> will mean "all box types except certain pseudo-elements as specified that
> pseudo-element", e.g. ::first-line pseudo-elements and their generated boxes
> do not accept 'height', as stated in the definition of ::first-line. This
> would mean that the Applies-to line would not be applicable to e.g. 'display'.

As I said in
http://lists.w3.org/Archives/Public/www-style/2011Nov/0179.html , I
think we should get rid of "Applies To" lines.  Restrictions we need
to express can go in the prose.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Tuesday, 22 November 2011 23:09:41 GMT

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