W3C home > Mailing lists > Public > www-style@w3.org > July 2010

Re: [CSS21] Distinguishing block boxes, block containers, and block-level elements

From: Peter Moulder <peter.moulder@monash.edu>
Date: Thu, 29 Jul 2010 21:16:31 +1000
To: "www-style@w3.org" <www-style@w3.org>
Message-id: <20100729111631.GA26310@bowman.infotech.monash.edu.au>
On Wed, Jul 21, 2010 at 12:16:54AM -0700, fantasai wrote:

>   | An <dfn>inline box</dfn> is one that is both inline-level and whose
>   | children (if any) would participate in its containing inline formatting
>   | context. For non-replaced elements, a 'display' value of 'inline' and
>   | sometimes 'run-in' (when it is not creating a block box) generates an
>   | inline box.

If this last sentence is intended to be normative (information not already
given elsewhere) then I suggest

  "Each non-replaced element whose computed value of 'display' is
  'inline' generates an inline box.  Each non-replaced element whose computed
  value of 'display' is 'run-in' generates either a block box or an inline box,
  according to the rules of section 9.2.3."

If the sentence is rather just to help the reader to grasp intuitively
what an inline box is, then I suggest conveying to the reader that they
don't need to understand it precisely: for example

  "(So for example non-replaced elements with a 'display' value of 'inline'
   generate an inline box.)"

If we're just helping the reader to grasp the concept, then I'd be inclined
not to mention run-in boxes.

The word "So" (or "Thus") is one indication that it doesn't contain normative
information, and parenthesizing is another indication.


For the reasons given earlier (sometimes vs always), it's not clear whether
anonymous inline boxes are inline-level boxes or not, though my impression from
the existing text is that they aren't.  [I see that Anton Prowse guesses that
they're nevertheless intended to be.]  If they aren't inline-level boxes,
then the text here is quite clear that they aren't inline boxes.  Whereas I
believe we want them to be at least inline boxes.


>   | Inline-level boxes that are not inline boxes [...]
>   | are called <dfn>atomic inline boxes</dfn>
...
>       (we can pick a different term, this is just what I came up with)

It would be rather unfortunate if "atomic inline boxes" weren't in fact
inline boxes.  So perhaps "atomic inline-level boxes".

> Section 9.2.4 The 'display' property
> 
>   # inline-block
>   #   This value causes an element to generate a block box, which itself
>   #   is flowed as a single inline[-level] box, similar to a replaced element.
>   #   [...]
> 
>   s/generate a block/generate an inline-level block container, i.e. a block/

That change seems not what you intended: to me it reads as saying that it generates
a block box, and that an inline-level block container is a block box.


I still haven't finished reading this message, and again I need to leave.

However, perhaps that's enough until I know what the terms are intended
to mean.

pjrm.
Received on Thursday, 29 July 2010 11:17:01 GMT

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