Anonymous inline boxes (was Re: CSS2 implementation)

On Wed, 11 Aug 1999 18:35:50 +0200, Rasmus Kaj (kaj@raditex.se) wrote:
> 
>  LDB> On Mon, 09 Aug 1999 17:59:43 +0200, Rasmus Kaj (kaj@raditex.se) wrote:
>  >> In this case, anonymous inline boxes should be created like this:
>  >> 
>  >> <HTML><BODY><anon> TEXT IS NI</anon><EM>C</EM><anon>E
>  >> </anon></BODY></HTML>
> 
>  LDB> That is what the spec says [1], but I don't think it makes much sense,
>  LDB> since it doesn't explain why the anon and em inline boxes should have
>  LDB> the same baseline.  As I've said before [2], I think the following:
> 
>  LDB> <HTML><BODY><anon> TEXT IS NI<EM>C</EM>E</anon></BODY></HTML>
> 
>  LDB> makes much more sense, since the vertial-align: baseline (the typical
>  LDB> value) on the EM has a parent inline box to which it can align.
>  LDB> Otherwise, if, for example, EM had a computed font-size of 300% and
>  LDB> vertical-align of baseline, there would be nothing wrong with
>  LDB> formatting it as:
> 
> In [3] it is stated that the vertical-align values "only have meaning
> with respect to a parent inline-level element, or to a parent
> block-level element, if that element generates anonymous inline
> boxes". Hence, in your example vertical-align has a meaning with
> respect to the parent block-level element (which maybe should be
> clearified to mean the actual line box).

But it isn't clear to what part of the parent block-level element the
text is baseline-aligned.  The line-box itself doesn't have a baseline
- only the inline boxes within it do.  Vertical-align: baseline means
to align to the baseline of the parent.  If the parent doesn't have a
baseline (i.e., is a line box or a block-level element), then it's
ambiguous.  Thus an anonymous inline box around the entire contents of
the paragraph is needed (to give it a baseline, a text-top, a
text-bottom, a subscript-baseline, and a superscript-baseline).

>  LDB> It would also give a much nicer way to describe the action of
>  LDB> line-height on a block-level element.
> 
> Hmm ...  Maybe [4] could be made clearer? But onece the flow is broken 
> into line boxes, i think that [5] is quite clear.  IOW, I don't think
> this (how the anonymous boxes are generated) should be changed.

I think the current method is silly, though, since the inline box model
has very little to do with containment.  That is, the box model itself
has no problem with:

************
*     -----*--------
*     |    *       |
******|*****       |
      --------------

except that that can't be represented using a tree structure (and
inheritance, etc., wouldn't make any sense).  The idea that the empty
spaces should have anonymous boxes is related to the idea that one box
contains another, which really isn't true (except that their starting
and ending points must be properly nested due to the tree structure of
the document).

There is a very problematic statement in [6] that could be made much
clearer by this simplification of anonymous inline boxes.  The line
in question currently says:

  If the property [line-height] is set on a block-level element whose
  content is composed of inline-level elements, it specifies the
  minimal height of each generated inline box.

I assume the current form of this statement is in error, because if
inline boxes were really meant here, then the line box height for
something like:

  <p style="line-height: 1.2">
    lots of text
	...
	<span style="font-size: 70%">small text</span>
	...
	more text
  </p>

would be *bigger* on the line with the small text.  So I assume the
authors really meant "each generated *line* box" rather than inline
box.

However, using the above statement with the words "line box" creates a
huge ambiguity.  If the line-box is taller than the tallest element
within it, where does that element go?  (Think, for example, if the
"small text" above spans multiple lines.)  The ideal solution is that
the small inline box ends up somewhere in the middle of the line box so
that the baselines are evenly spaced.  This is somewhat difficult to
describe formally in the current model.

However, if my propsal for anonymous inline boxes were adopted, the
above statement could be *removed* and its intent (that a block level
element can never have a line box smaller than its line-height) would
be a natural consequence of the anonymous inline box within that block
level element.  Furthermore, there would be no strange side effects.
The difficult case I describe in the previous paragraph would come out
as desired - the baselines would be evenly spaced.  (The spec would
need to note that the anonymous block level element inherits all
inheritable properties from the block level element, including
line-height, and that line-height does not apply to block level
elements at all.)

David

> [1] http://www.w3.org/TR/REC-CSS2/visuren.html#anonymous
> [2] http://lists.w3.org/Archives/Public/www-style/1999Jan/0027.html
>     http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html
> [3] http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-vertical-align
> [4] http://www.w3.org/TR/REC-CSS2/visuren.html#line-box
> [5] http://www.w3.org/TR/REC-CSS2/visudet.html#line-height
[6] http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-line-height

Received on Wednesday, 11 August 1999 17:10:20 UTC