- 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>
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 UTC