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

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

From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Date: Sat, 31 Mar 2012 05:08:38 +0800
Message-ID: <4F7620D6.4000601@csail.mit.edu>
To: Simon Sapin <simon.sapin@kozea.fr>
CC: WWW Style <www-style@w3.org>
(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.

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.

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

> , 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

2. change

  # Applies to:  	block containers


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


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

> Overflow happens at box boundaries, so it
> could behave differently on various boxes created by the same element.
> (Eg: on table wrapper boxes but not on table boxes.)

Indeed, for this very example, note that 17.4 says

  # The computed values of properties 'position', 'float', 'margin-*',
  # 'top', 'right', 'bottom', and 'left' on the table element are used
  # on the table wrapper box and not the table box; all other values of
  # non-inheritable properties are used on the table box and not the
  # table wrapper box.

, so 'overflow', which is not mentioned in the list, is used on the
table box. This is matching browsers except WebKit[1].

> For 'display: list-item', does overflow make sense on the list marker box?

No, although the spec doesn't have something as clear as 17.4.

[1] http://lists.w3.org/Archives/Public/www-style/2011Jul/0462

Received on Friday, 30 March 2012 21:09:07 UTC

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