[CSS21] Loose text in block containers, and white-space processing model (Was: Re: [CSS21] Random editorial issues)

On 25/07/2010 14:30, Anton Prowse wrote:
> On 21/07/2010 fantasai wrote:
>> Section 16.6.1 The 'white-space' processing model
>>
>>    # Any text that is directly contained inside a block element (not
>>    # inside an inline element) should be treated as an anonymous inline
>>    # element.
>>
>>    This sentence belongs in 9.2.2.1, which currently lacks normative
>>    text to this effect, and seems to be trying to define behavior by
>>    giving an example.
> 
> 100% in favour.  9.2.2.1 does indeed lack that key point that "loose"
> inline content of block-level element is wrapped in an anonymous inline
> box, which is also of relevance to the wording of 9.2.1.1; see my
> earlier post [1].
> 
> Actually, is this not also the case for "loose" text inside arbitrary
> block boxes (not just the principal block box of block-level elements)?


Hang on, I think there are two issues here, not just one, and that we
were barking up the wrong tree.

Issue 1:

9.2.2.1 is silent on whether, in the case of a block container box with
text content but which contains no inline-level boxes arising from
document tree elements, an anonymous inline box is generated for this
"loose" text.  Rather, it talks about what happens when there's a
mixture of loose text and inline level boxes.

This needs clarifying.  (We know this is what the model demands, because
things are nonsensical if text isn't contained by an inline box.)

fantasai (I think) and I thought that this was precisely what the
sentence from 16.6.1 was telling us (through interpreting "element" as
"box" assuming the spec's usual element/box carelessness).  However, I'm
not so sure now, as I describe below.  So I no longer think moving the
sentence is the appropriate resolution to this issue.


Issue 2:

I think the sentence from 16.6.1, that any loose text in a block
container should be treated as an anonymous inline element, truly is
connected to the description of the white space processing model.  (If
so, the fact that its general application would result in the anonymous
inline box we require in Issue 1 is merely coincidental.)

In particular, the white space processing model requires us to consider
text runs on an element-by-element basis.  It's not talking about inline
boxes, since it's presumed that inline box generation hasn't happened
yet; box generation depends on determination of line break opportunities
which itself depends on the results of white space processing.  So we do
require anonymous inline elements.  This is a concept unused elsewhere
in CSS21 (if you don't count pseudo-elements).

Is this concept intended for general application?  My guess is that it's
not, and that it's merely a device for 16.6.1.  Hence the sentence needs
to remain in place.  I suggest the following changes:

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

s/Any text that is/Runs of text that are/
s/an anonymous inline element/anonymous inline elements/

to clarify that there may be one than one such run.  Then insert the
following at the end of the sentence:

   | for the purposes of white space processing.

to clarify the scope.


Now to some further issues.

Issue 3:

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

This is messy.  It would be better to explain in 9.2.2.1 that inline box
generation occurs after the white space processing (which itself takes
place after the determination of inline formatting contexts).  Then
nothing needs to be said here.


Issue 4:

In 16.6.1, the white space processing is undertaken for each inline
formatting context independently, and does not "cross the boundary"
between different contexts.  For example, in 16.6.1 Step 4.2, neither an
initial space in an inline-block, nor a space which comes after the
inline block, is regarded as "following" a space before the inline
block.  I think the "atomic inline block" terminology will come to our
aid in describing this.


Issue 5:

   # Each tab (U+0009), carriage return (U+000D), or space (U+0020)
   # character surrounding a linefeed (U+000A) character is removed if
   # 'white-space' is set to 'normal', 'nowrap', or 'pre-line'.

Remove the reference to carriage return, since all newlines have already
been normalized to line feeds, according to 16.6.  Note that in
CSS3-text, this issue doesn't arise since the sentence is formulated
differently.


Issue 6:

   # 4.  If 'white-space' is set to 'normal', 'nowrap', or 'pre-line',
   #   1. [...]
   #   2. any space (U+0020) following another space (U+0020) — even a
   #      space before the inline, if that space also has 'white-space'
   #      set to 'normal', 'nowrap' or 'pre-line' — is removed.

This is a bit messy.  A space doesn't have 'white-space' set. CSS3-text
manages to word this a bit more elegantly.  (This also affects the
second four-step list in 16.6.1.)

Both specs refers to a "space before the inline" which is also a bit
sloppy; the "inline" is presumed to be the element we're currently
treating, right?


Issue 7:

   # Then, the entire block is rendered. Inlines are laid out, taking
   # bidi reordering into account, and wrapping as specified by the
   # 'white-space' property. When wrapping, line breaking opportunities
   # are determined based on the text prior to the white space collapsing
   # steps above.

What's the purpose of the last sentence?  It's been dropped from
CSS3-text.  (And it's not entirely correct anyway, since the collapsing
steps themselves help determine link breaking opportunities (eg. step 2).)


Issue 8:

The contents of 16.6.2 (Example of bidirectionality with white space
collapsing) really should be an example, not normative text.  Hopefully,
the cleaned up version from CSS3-text (which manages to dispense with
the phrase "weird things" ;-) could be used instead.


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Friday, 20 August 2010 20:55:27 UTC