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

On Friday, August 20, 2010 1:53 PM Anton Prowse wrote:
> 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.
> 

Thank you for your feedback. The CSSWG resolved not to make changes to the CSS 2.1 specification[1]. We will be reevaluating these issues for errata and future versions of CSS. 

Please respond before 18 March, 2011 if you do not accept the current resolution.

[1] http://w3.org/TR/CSS

Received on Tuesday, 15 March 2011 17:11:25 UTC