[CSS21] Re: Clarification needed for inline boxes containing block boxes

On Mon, Aug 23, 2010 at 06:53:53PM -0700, fantasai wrote:
> On 02/25/2009 06:46 PM, Boris Zbarsky wrote:
> >Consider the following testcase:
> >
> >data:text/html,<!DOCTYPE html><span style="padding: 0 20px; background:
> >green; border: 2px solid red">aaa<div>bbb</div></span>
> >
> >Note the lack of content inside the <span> after the <div>.
> >
> >[...]
> >
> >It seems to me that section 9.2.1.1 isn't very clear, since no two UAs
> >are doing it the same way.  [...]
> 
> Proposed text for CSS2.1 Issue 195
>   http://wiki.csswg.org/spec/css2.1#issue-195
> In section 9.2.1.1
>   http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level
> 
> append to
> 
>   # When an inline box contains an in-flow block box, the inline box
>   # (and its inline ancestors within the same line box) are broken
>   # around the block.
> 
> the following:
> 
>   | dividing the inline box into two pieces.

That still leaves a couple of other issues.

The first is, what is a "piece", and what is the rendering of a "piece" of an
inline box?  It's not clear whether this means "into two distinct boxes" or
something else.

A related provision is in line-breaking, section 9.4.2:

  # When an inline box exceeds the width of a line box, it is split into
  # several boxes and these boxes are distributed across several line boxes.
  # ...
  #
  # When an inline box is split, margins, borders, and padding have no visual
  # effect where the split occurs (or at any split, when there are several).

If we want that second paragraph's behaviour to apply, then we should use the
same sort of language: use the word "split" (so that the "when an inline box is
split" rule clearly applies), and make it clear that each part is a box (though
see query below about zindex.html behaviour).  E.g. "split into two boxes, one
each side of the block-level box".  

Neither the existing nor the new text say what to do if an inline box contains
more than one block-level box, but my interpretation would be that this
provision is to be applied for each such block-level box, so that an inline box
containing n block-level child boxes is divided into n+1 pieces.  If it's
considered clear enough that the first and last piece generate an empty line
(with background and borders) if empty, then I would also expect each of the
other pieces to generate an empty line (with background & borders) if empty.
Whereas none of the user agents I've tested (Gecko, Konqueror, WebKit) generate
such an empty line between two contiguous block-level children of an inline
element.  (Nor if the two blocks are separated by collapsible whitespace or
by an inline element containing only collapsible whitespace.)

The behaviour I see implemented (not generating an empty line between the two
blocks when there's no content to put there) seems quite reasonable to me, so
I'd be inclined to change the specification to clearly specify this behaviour.


There are also still some issues regarding unclear interaction with
zindex.html: if the inline has position:relative and a value of 'z-index'
other than 'auto', then it is unclear whether this inline counts as one
"element" (in the zindex.html sense) or several.  Relatedly, it's unclear
whether the anonymous block boxes count as "elements" (or "descendents")
for purposes of zindex.html.  zindex.html says:

  # "element" refers to actual elements, pseudo-elements, and
  # anonymous boxes

but isn't clear whether all actual elements, pseudo-elements and
anonymous boxes are to be counted as distinct elements/descendents,
and more generally isn't clear what the descendents of an "element" are
(e.g. whether the zindex.html "element" for the block-level box is a
child of the block container box's "element" or whether it's a child of
the inline element's "element", if the inline element counts as a single
"element").


Note that there's contradictory evidence within zindex.html as to whether
split/broken boxes count as one or several "elements", so I suggest we
decide based on what behaviour we want and what behaviour is commonly
implemented rather than trying to find a consistent answer within the
existing text.

I believe the easier of the two options to implement is for
splitting/breaking to result in distinct "elements".  From an authoring
point of view (though keep in mind that I'm not an author), there may
be some predictability benefit in the painting order not being influenced
by at least the breaking involved in line-breaking; though on the other
hand I would (ignorantly) have thought that it's very rare for this
decision to affect real layouts.

pjrm.

Received on Wednesday, 3 November 2010 00:12:51 UTC