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

[CSS21] How to define "block-level box"

From: Peter Moulder <peter.moulder@monash.edu>
Date: Sun, 14 Oct 2012 22:37:36 +1100
To: www-style@w3.org
Message-id: <20121014113736.GA24918@bowman.infotech.monash.edu.au>
[This issue exists whether or not Anton Prowse's "block container element"
 proposal (as currently worded) is adopted.]

Various behaviour in CSS 2.1 depends on knowing whether a given box is
block-level or not.  E.g. anonymous block box generation.

The term "block-level box" seems to be defined by this sentence in
section 9.2.1:

  # <dfn>Block-level boxes</dfn> are boxes that participate
  # in a <a href="#block-formatting">block formatting context.</a>

Evidence that this is the definition is that this sentence starts with a
dfn element, which is linked to by the index entry for "block-level box;
and the rest of the paragraph doesn't seem to be part of the definition.

Of course www-style regulars will know that other parts of the spec
specifically describe certain boxes being generated as block-level, but
(a) those aren't referenced by this text that appears to be the definition,
and (b) identifying some boxes as block-level doesn't tell us whether any
other boxes are also block-level; every appearance is that in general we
must refer to the above sentence to decide whether a given box is
block-level.

Accepting this definition, the question then becomes how to determine
whether a given box "[participates] in a <a href="block-formatting">block
formatting context</a>".

#block-formatting is section 9.4.1 (aptly titled “Block formatting
contexts”).

There is no dfn or index entry for "block formatting context",
but only the first paragraph of this section looks like a definition:

  # Floats, absolutely positioned elements, block containers (such as
  # inline-blocks, table-cells, and table-captions) that are not
  # block boxes, and block boxes with 'overflow' other than 'visible'
  # (except when that value has been propagated to the viewport)
  # establish new block formatting contexts for their contents.

There is no definition of "participate" in the CSS 2.1 spec;
the closest we get is section 9.4's

  # Block-level boxes participate in a block formatting context.
  # Inline-level boxes participate in an inline formatting context.

(which is redundant given how the terms "block-level box" and "inline-level
box" are currently defined).

So we can only assume that we should take the above "[certain elements and
boxes] establish new block formatting contexts for their contents" to imply
that their contents participate in said new established block formatting
contexts, and hence that their contents are block-level.

This means that if the div below is a float/abspos/...:

  <div><span>hello,</span> <span>world</span></div>

then its child span elements/boxes are block-level, and hence should be
laid out one on top of the other, contrary to the behaviour of every known
visual UA.

(If the "contents" mentioned above are boxes rather than elements,
then we also need to check whether some anonymous block box gets wrapped
around the span, but in any case 9.2.1.1 doesn't seem to do so, and I
can't think of any other text in CSS 2.1 that would do so.)

Certainly, the span elements (assuming the standard display:inline styling)
are elsewhere described as being inline-level, but (a) I'm not sure that
there's any text that explicitly says that inline-level implies not
block-level, and (b) even if there were, it would conflict with the
above-cited text that says that they're block-level in this example.


I haven't checked carefully, but I suspect that the term "inline-level box"
has analogous problems: it's currently defined as "[a box] that
participate[s] in an inline formatting context" (this time without a
hyperlink for inline formatting context), and there's no index term
or <dfn> element for inline formatting context, and "participate in an
inline formatting context" is even less defined than "participate in a
block formatting context".


To resolve these problems, I suggest that block formatting context should
be defined in terms of block-level box, not the other way around.

I gather that the sticking point for finding a good definition of
"block-level" is trying to remain compatible with future levels of
CSS, which might e.g. introduce table-caption boxes that aren't
block-level (or might introduce new values of 'display', though this
possibility is a bit easier to cater for).

I propose that "block-level box" (and "inline-level box") be defined in
terms of the text describing the generation of that box, i.e. that it be
the responsibility of text describing the generation of a box to specify
whether that box is block-level or inline-level (or neither), and that
there be text in both §9.2.1 and §9.2.2 saying explicitly that if a box is
described as block-level then it is not inline-level (with one copy being
reworded as "if ... inline-level then ... not block-level").  I further
(somewhat tentatively) suggest that either section 9.2 or sections 9.2.1
and 9.2.2 explicitly say claim that every part of CSS that specifies a box
to be generated also specifies whether that box is block-level,
inline-level or neither.

pjrm.
Received on Sunday, 14 October 2012 11:38:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:01 GMT