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:55:20 +0200
Message-ID: <4F79AFC8.2080309@moonhenge.net>
To: WWW Style <www-style@w3.org>
CC: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>, Simon Sapin <simon.sapin@kozea.fr>
On 30/03/2012 23:08, Kang-Hao (Kenny) Lu wrote:
> (12/03/31 3:49), Simon Sapin wrote:
>> The table wrapper box is indeed a block container, but the "real" table
>> box is not. By "other table boxes" in my previous message I meant any
>> other table-related box (ie: tables themselves, row groups, rows, column
>> groups and columns) but missed the exception of table wrapper boxes.
>
> Then I was wrong in reading your mail. This often confuses me too as it's
> often not clear to me if "table element" means "'table' element" or
>
>    # In this specification, the term table element refers to any element
>    # involved in the creation of a table.

Yes, I'm not a fan of using "table element" to mean anything other than 
the element to which display:table or display:inline-table is attached, 
either.

> This is even more confusing because the term "table box"('table',
> 'inline-table') doesn't match the term "table element"('table',
> 'inline-table', 'table-*') in the CSS 2.1 specification.

Indeed, it doesn't match.  (And note that "table box" doesn't precisely 
match 'table' or 'inline-table' either, since it's merely one of /two/ 
important boxes which such elements generate.)

>> To conclude: I don’t know whether elements with 'display: table' or
>> 'inline-table' should be "block container elements"
>
> I think it's pretty sad that we are still debating the definition of
> "block container element", which is a term that's so fundamental and
> used 14 times throughout the specification. As I said, I am fine if we
> define it as the majority understanding of this term (i.e. my Plan A,
> which excludes 'table'/'inline-table'). It just seems bad if a spec
> reader has to get the definition of "block container element" form the
> the definition of "block container box" and some element<->  box
> heuristics, which would break once he/she (like me) reads 17.4.

I agree that it's all a bit confusing.  I really think that CSS3 is the 
right place to fix this though.


>> , but I don’t think it matters for 'overflow'.
>
> Indeed. It doesn't. That's a technical issue and I am not even sure if
> my issue is technical.
>
> But I'll note that when people try to figure out whether 'overflow'
> applies to 'table'/'inline-table', like my friend and I who raised the
> original 'overflow' issue, the first thing they do will be 1) look at
> the "Applies to" line 2) find the definition of "block container" and
> soon get into this mess.
>
> In any case, my proposal to the 'overflow' issue would be
>
> 1. adopt my plan B (include 'table'/'inline-table' in "block container
> elements")
>
> 2. change
>
>    # Applies to:  	block containers
>
> to
>
>    | Applies to:  	block container elements
>
> 3. change
>
>    # This property specifies whether content of a block container
>    # element is clipped when it overflows the element's box. It affects
>    # the clipping of all of the element's content...
>
> to
>
>    | This property specifies whether content of a block container
>    | box (when 'display' is not 'table' or 'inline-table') or table box
>    | is clipped when the content overflows the box. It affects the
>    | clipping of all of the box's content...

Is it not good enough (modulo the acknowledged impreciseness of element 
vs box) to simply say that overflow applies to "block containers and 
table boxes"?

Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Monday, 2 April 2012 13:55:55 GMT

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