W3C home > Mailing lists > Public > www-style@w3.org > April 2012

Re: [css21][css3-box] please define "block container element"

From: Anton Prowse <prowse@moonhenge.net>
Date: Mon, 02 Apr 2012 15:54:35 +0200
Message-ID: <4F79AF9B.8080405@moonhenge.net>
To: WWW Style <www-style@w3.org>
CC: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>, Gérard Talbot <www-style@gtalbot.org>, "L. David Baron" <dbaron@dbaron.org>
On 30/03/2012 14:01, Kang-Hao (Kenny) Lu wrote:
> Context: a three-month-old thread[1] about whether 'overflow' applies to
> 'table'/'inline-table' and what "block container" is in general.
> [1] http://lists.w3.org/Archives/Public/www-style/2011Dec/thread#msg14
> (11/12/03 19:36), Anton Prowse wrote:
>> On 02/12/2011 21:52, www-style@gtalbot.org wrote:
>>> Øyvind Stenhaug<oyvinds@opera.com>  a écrit :
>>>> On Fri, 02 Dec 2011 03:47:47 +0100, Gérard Talbot
>>>> <www-style@gtalbot.org>  wrote:
>>>>> overflow applies to inline-table elements though according to
>>>>> http://wiki.csswg.org/spec/css2.1#issue-217
>>>>> I can't help think that it's kinda weird ... overflow applies to
>>>>> inline-tables but not to fixed-width tables.<shrug>
>>>> The text modified due to that issue was since superseded by
>>>> <http://wiki.csswg.org/spec/css2.1#issue-120>  and
>>>> <http://wiki.csswg.org/spec/css2.1#issue-266>. Per the current spec
>>>> text, overflow does not apply to 'inline-table' nor 'table'.
>>> I do not read such in the issues you list. I do not see where it says or
>>> would suggest that overflow does not apply to inline-table.
>> Issue 266, my issue 6 contained therein.
>> Shame that the only one that didn't get pushed to errata was the one
>> that was wrong.  Sorry guys :-(
>> In the Applies To line of the 'overflow' property, "non-replaced
>> block-level elements, table cells, and inline-block elements" should
>> have been changed to "block containers and table boxes" not to "block
>> containers".
> I've been thinking about this for a while now and now I am not sure if
> the above solution is sufficient to resolve all the confusion around
> this. The broader problem, as far as I can tell, is this:
>    CSS 2.1 uses the term "block container element" throughout without
>    actually defining it. It's not even clear if there's a consistent
>    and satisfactory definition.

This is correct.  It's a well-known problem in CSS21 that 'element' and 
'box' are often used interchangeably, which is the cause of many 
technical inaccuracies in the spec.  I would love to have seen that 
fixed, but it's a lot of work and it was widely felt in the WG that it 
is not a good use of resources to fix this in CSS21; rather, the CSS3 
specs will be much more careful in their use of technical language.

Often it's clear what is meant even when the wrong term is used.  In the 
case of elements which generate multiple boxes, however, there may be 
ambiguities which we should try to resolve.

> To explain this, note that:
> 1. CSS 2.1 9.2.1[2] has the following italic terms (presumably
> representing definitions) "block-level element", "block-level block" and
> "block container box", but notably *not* "block container element"
> 2. "block container element" is used many times in CSS 2.1 (to be
> precise, 11 times). The type of a "Applies to" line is, I would assume,
> element, so this increases this to 14 times. (Can we always say "block
> container elements" in the "Applies to" line? Now that in CSS 2.1 both
> "block container" and "block container elements" are used in the
> "Applies to" lines, which is, I think, quite confusing.)

(Actually, my impression was that the use of "block containers" was a 
deliberate attempt to exploit the ambiguity so that we weren't 
explicitly using the undefined term "block container elements" :-)

> 3. We definitely want to make "block container element" include
> 'list-item', so a definition like "a block container element is an
> element that all the non-anonymous boxes it generates are block
> container boxes" doesn't work.

Indeed, such a definition would definitely not work.

> But it's not clear if s/all/any of/ to
> the previous definition would work because various people seem to
> suggest that a 'table'/'inline-table' is not a "block container
> element". (Note that while a table box is not a block container box, a
> table wrapper box is, at least in my mental model.)

Yes, that's right.  The table wrapper box is a block container box.  The 
table box itself is not; it's a special kind of box which establishes a 
table formatting context (or some such concept).  I think 17.4 is clear 
about the situation.

> I think the only place where this does make some differences is whether
> ::first-letter/::first-line applies[3]:
>    # The :first-line pseudo-element can only be attached to a block
>    # container element.
>    # The :first-letter pseudo-element applies to block container
>    # elements.

Thanks; focusing on specific examples like this are the best way to 
approach the problem, I think.

> All browsers I tested don't apply '::first-line/::first-letter' to
> 'table' (with this test case:
> data:text/html,<style>table::first-line { color: red;
> }</style><table><caption>should the first line be
> red?</caption><tr><td></td></tr></table>
> ),

I agree that this is ambiguous.  I think I'd rather change "block 
container elements" to "block containers" in 5.12 and then say something 
about ::first-line and ::first-letter explicitly in Chapter 17 at the 
place where the division of properties between the wrapper box and the 
table box is discussed (ie 17.4).  As to which behaviour to choose, I 
think that either could be reasonable but given that it sounds like UAs 
don't apply ::first-x on table to the caption box I guess we should just 
prohibit the use of ::first-x on table.

> but I don't see a test like this in the test suite either

Would you mind sending that specific example to 
public-css-testsuite@w3.org ?  The folks there can track it.

> I see two possibilities here:
> A. Explicitly define "block container element" as an element with the
> computed 'display' of 'block', 'list-item', 'inline-block',
> 'table-cell', 'table-caption'.
> This has minimal impact to the conformance requirement. It's not too
> clear to me how you establish the relationship of "block container
> element" and "block container box" though.
> B. Define "block container element" with the invariant "a block
> container element is an element that at least of the non-anonymous boxes
> it generates is a block container box".
> This will include 'table'/'inline-table' in the "block container
> elements" category and we'll need to review various occurrences of this
> term in CSS 2.1.

I don't really fancy either of these, and I would prefer to clean all 
this up in CSS3 apart from specific contradictions or ambiguities which 
have a direct impact (such as the ::first-x situation above).

> (11/12/02 4:39), L. David Baron wrote:
>> On Thursday 2011-12-01 15:12 -0500, Boris Zbarsky wrote:
>>> Right now, answering the question "What elements does the 'overflow'
>>> property apply to?" is rocket science.  It says it applies to "block
>>> containers", but the text isn't a link, and actually finding the
>>> definition of that term, assuming there is one at all, is
>>> near-impossible.
>> I think the definition it's intending to refer to is the second
>> sentence of this:
>>    # Except for table boxes, which are described in a later chapter,
>>    # and replaced elements, a block-level box is also a block
>>    # container box. A block container box either contains only
>>    # block-level boxes or establishes an inline formatting context
>>    # and thus contains only inline-level boxes. Not all block
>>    # container boxes are block-level boxes: non-replaced inline
>>    # blocks and non-replaced table cells are block containers but not
>>    # block-level boxes. Block-level boxes that are also block
>>    # containers are called block boxes.
>>     --http://www.w3.org/TR/CSS21/visuren.html#block-boxes
>> which is admittedly rather imprecise (since it defines the
>> characteristics of a block container box rather than defining what
>> causes a box to be one), but I think it's pretty clear that tables
>> are not block container boxes, and therefore, according to CSS 2.1,
>> the 'overflow' property does not apply to tables.
> If the definition of a "table container box" is based on the
> characterisc that it "either contains only block-level boxes or
> establishes an inline formatting context and thus contains only
> inline-level boxes", we soon run into circular definition because the
> following section, Anonymous block boxes[4], has
>    # In other words: if a block container box (such as that generated
>    # for the DIV above) has a block-level box inside it (such as the P
>    # above), then we force it to have only block-level boxes inside it.
> . So the definition of a "block container box" must be "what causes a
> box to be one" and hence consists of the piecewise
> statement-of-fact-like texts that are spread everywhere:

Yeah, that's pretty much how it is, I'm afraid. :-(

> 1. Except for table boxes, which are described in a later chapter, and
> replaced elements, a block-level box is also a block container box.
> 2. Not all block container boxes are block-level boxes: non-replaced
> inline blocks and non-replaced table cells are block containers but not
> block-level boxes.
> 3. Floats, absolutely positioned elements, block containers (such as
> inline-blocks, table-cells, and table-captions) that are not block
> boxes... (to make sure 'table-caption' is included, but I think
> including 'table-caption' in block-level elements would probably be a
> better solution)
> (I think it's probably no longer useful to criticize this text, but can
> we link "table box" to 17.4 Tables in the visual formatting model in the
> errata so that a CSS 2.1 newbie like me won't confuse "table box" with
> "the thing generated by a 'table'"?)

Which instance?  (Chapter 9 already contains several links to Chapter 17 
or mentions of it.)

> By the way, css3-box has this text[5]:
>    # In the above, a block container box is, informally, a box that can
>    # contain block boxes. More precisely: any box generated by a
>    # (pseudo-)element with a computed value for ‘display’ of
>    # ‘block’, ‘inline-block’, ‘table-caption’, ‘table-cell’,
>    # ‘list-item’ or template.
> which is not accurate for 'list-item' because it generates inline marker
> boxes too.
> Also, css3-box doesn't define "block-level element".

Unfortunately css3-box is horribly out-of-date.  Bert and I are working 
on bringing it back to life...

Anton Prowse
Received on Monday, 2 April 2012 13:55:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:14 UTC