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

Re: Question about inline layout and margins, again

From: Peter Moulder <peter.moulder@monash.edu>
Date: Sun, 04 Sep 2011 22:16:32 +1000
To: www-style@w3.org
Message-id: <20110904121631.GA19041@bowman.infotech.monash.edu.au>
On Sat, Aug 27, 2011 at 01:13:32AM -0400, Boris Zbarsky wrote:
> I never really got a useful response to
> http://lists.w3.org/Archives/Public/www-style/2010Feb/0200.html
> 
> In particular, it's not clear to me whether CSS2.1 even defines the
> behavior.  If it does, what's the right behavior?  If it does not,
> what CSS3 module is planned to define it?

Here are some relevant excerpts from CSS 2.1 that I found.

Text relevant to when content must be split across line boxes:

  - Start of 9.4.2:
   
      # In an inline formatting context, boxes are laid out horizontally,
      # one after the other, beginning at the top of a containing block.
      # Horizontal margins, borders, and padding are respected between
      # these boxes.

  - In 9.4.2 para 3:
  
      # When several inline-level boxes cannot fit horizontally within a
      # single line box, they are distributed among two or more
      # vertically-stacked line boxes.

  - Para 6 of same section:

      # When an inline box exceeds the width of a line box, it is split
      # into several boxes and these boxes are distributed across several
      # line boxes.  If an inline box cannot be split (e.g., if the
      # inline box contains a single character, or language specific
      # word breaking rules disallow a break within the inline box, or
      # if the inline box is affected by a white-space value of nowrap or
      # pre), then the inline box overflows the line box.

  - I don't think the following paragraph (i.e. para 7) is relevant, but
    it's conceivable that others have interpreted it as applying:

      # When an inline box is split, margins, borders, and padding have
      # no visual effect where the split occurs (or at any split, when
      # there are several).

Text relevant to height of a line box:

  - in 10.8, item 3:

      # The line box height is the distance between the uppermost box top
      # and the lowermost box bottom.

  - The paragraph after that item 3:

      # Empty inline elements generate empty inline boxes, but these
      # boxes still have margins, padding, borders and a line height,
      # and thus influence these calculations just like elements with
      # content.

  - (The above is also echoed in 10.8.1 para 2 in the context of
    baseline/ascender/descender calculations:

      # If the inline box contains no glyphs at all, it is considered to
      # contain a strut (an invisible glyph of zero width) ...

    .)

  - Nevertheless, the point is contradicted by
    visuren.html#phantom-line-box for some cases:

      # Line boxes that contain no text, no preserved white space, no
      # inline elements with non-zero margins, padding, or borders, and
      # no other in-flow content (such as images, inline blocks or inline
      # tables), and do not end with a preserved newline must be treated
      # as zero-height line boxes for the purposes of determining the
      # positions of any elements inside of them, and must be treated as
      # not existing for any other purpose.

  - visudet.html#propdef-line-height further down 10.8.1:

      # On a block container element whose content is composed of
      # inline-level elements, 'line-height' specifies the
      # minimal height of line boxes within the element.
      # ...
      #
      # On a non-replaced inline element, 'line-height' specifies the
      # height that is used in the calculation of the line
      # box height.

I would conclude:

  - That it's wrong to make the first line-box zero-height.  E.g. it
    has an inline box that has a margin, so the phantom-line-box rule
    doesn't apply, and I'm not aware of any other rule that would give a
    zero-height line [assuming that the default 'line-height' is
    non-zero].

  - The text "Horizontal margins, ... are respected between
    these boxes" means that there's no way that the first two spans can
    "fit horizontally within a single line box", so the two spans must be
    "distributed among two or more vertically-stacked line boxes", so I
    would conclude that it's wrong for the first two spans to go in a
    single line box.

  - As for whether Text should appear 10px to the left of the div's
    left edge, or what the behaviour should be if the first span had
    a margin-left of 200px instead of margin-right, I don't think any
    of the above texts are sufficiently clear to say where the content
    area of the inline has to begin: the text I've found above only says
    that margins between boxes have to be honoured, without saying
    whether margins at the start of the first inline have to affect the
    position of the inline (for text-align:left/start).
    
    Nevertheless, I'd be fairly sure that the intent would be that it
    does affect the content start position (so that margin-left and
    margin-right would have equivalent behaviour in this test), and
    similarly I'd have thought it clear that wrapping a 20px inline in a
    box with -10px margins would be intended to act like a 0px-wide
    inline.

    So I too would expect Text to start 10px to the left of the div's
    left content edge.

pjrm.
Received on Sunday, 4 September 2011 12:17:09 GMT

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