W3C home > Mailing lists > Public > www-style@w3.org > January 2011

[CSS21] Box tree - comments on Working Draft

From: Anton Prowse <prowse@moonhenge.net>
Date: Fri, 07 Jan 2011 22:01:44 +0100
Message-ID: <4D277F38.5060402@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
As a result of the resolution of Issue 177,[1] 9.2.2.1 (Anonymous inline 
boxes) now says:

   # Any text that is directly contained inside a block container
   # element (not inside an inline element) must be treated as an
   # anonymous inline element.

Whilst I re-emphasize that this might be a technical change from the 
previous version of the spec (since I believe that this sentence, which 
has been moved from 16.6.1, was introduced purely for the narrow 
purposes of the white space processing model; see [2]), I do think it's 
a good change.  In a situation like

<p>text</p>

the principal block box generated by the p element now contains an 
anonymous inline box containing the word "text" (possibly split into 
multiple inline boxes across different lines if the UA implements some 
sort of hyphenation functionality).

It's difficult to see how the inline formatting model holds together 
without all text being contained in some inline box.


Issue 1: 9.2.2.1 goes on to say:

   # In a document with HTML markup like this:
   #
   # <p>Some <em>emphasized</em> text</p>
   #
   # the <p> generates a block box, with several inline boxes inside it.
   # The box for "emphasized" is an inline box generated by an inline
   # element (<em>), but the other boxes ("Some" and "text")) are inline
   # boxes generated by a block-level element (<p>).

We need:

s/"Some"/"Some "/
s/"text"/" text"/

since the white space processing has not yet taken place at the time of 
introducing the anonymous inline boxes.

This fact also creates a problem for the subsequent paragraph:

   # White space content that would subsequently be collapsed away
   # according to the 'white-space' property does not generate any
   # anonymous inline boxes.

At the time of generating the inline boxes, it is not known whether the 
white space would be subsequently collapsed away.  It could be possible 
to know this... but that would involve changing the white space 
processing model in 16.6.1 which currently relies on the fact that the 
inline boxes are already present.


Issue 2: 16.3.1 (Underlining, overlining, striking, and blinking: the 
'text-decoration' property) says:

   # [...] For block containers that establish an inline formatting
   # context, the decorations are propagated to an anonymous inline
   # element that wraps all the in-flow inline-level children of the
   # block container.

Is this anonymous inline in addition to the anonymous inline that is 
generated when a block container has text content but no element 
children?  For example, in

<p>text</p>

are there two nested anonymous inline boxes containing the text?  This 
section and its example would certainly imply this.  When does this 
outer anonymous inline box exist?  Always, or only when the computed 
value of 'text-decoration' is other than none?  (I suspect we don't want 
to treat this anonymous inline as something additional.  Rather, we 
should define block containers which establish an inline formatting 
context to *always* contain an anonymous inline box which wraps its 
content.  This complements the example in 16.3.1 as well as simplifying 
9.2.2.1 (although the example in 9.2.2.1 would need adjusting).


Issue 3: 17.2.1 (Anonymous table objects) says:

   # Document languages other than HTML may not contain all the elements
   # in the CSS 2.1 table model. In these cases, the "missing" elements
   # must be assumed in order for the table model to work. Any table
   # element will automatically generate necessary anonymous table
   # objects around itself, consisting of at least three nested objects
   # corresponding to a 'table'/'inline-table' element, a 'table-row'
   # element, and a 'table-cell' element. Missing elements generate
   # _anonymous_ objects (e.g., anonymous boxes in visual table layout)
   # according to the following rules

where _anonymous_ links to 9.2.2.1 (Anonymous inline boxes).  Wouldn't 
it be better to link to 9.2.1.1 (Anonymous block boxes) since that's 
where the discussion of anonymous boxes begins?


[1] http://wiki.csswg.org/spec/css2.1#issue-177
[2] http://lists.w3.org/Archives/Public/www-style/2010Aug/0421.html 
(Issues 1 and 2)

Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Friday, 7 January 2011 21:02:16 GMT

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