Re: [css3-multicol] Intrinsic Widths of Multi-column elements (Take I)

On Monday 2011-04-11 14:34 -0700, fantasai wrote:
> Proposed Definition of Multicol Intrinsic Widths
> ================================================

It's worth noting that what this definition needs to say is
substantially constrained by the multicol specification.  Since the
multicol specification says:
  # However, both ‘column-width’ and ‘column-count’ are honored when
  # the width of the element has not been determined. This can,
  # e.g., be the case for table cells and floats.
and we define the sizing rules for table cells and floats in terms
of intrinsic widths, any intrinsic width rules that do not produce
that result introduce a contradiction between specifications and
mean that one of the three specifications is factually incorrect.
(I'd suggest it should be the one you're trying to define for
multicol intrinsic widths.  And the definitions you propose *do*
lead to such a contradiction.)

> min-content width:
>   Defined as the min-content width of the contents (same as now). *
>   (Alternatively, define as the width of a multicol element with the
>   column count and column gap as specified and the column-width as
>   the min-content width of the contents.)

I think this is wrong in any cases where:
 * the column-width and column-count properties force there to be
   more than one column no matter what the width
 * the column-width property constrains the content to less than its
   min-content width or forces it to be wider

So, instead, given
http://www.w3.org/TR/2011/CR-css3-multicol-20110412/#pseudo-algorithm ,
I think it should be:

  If column width is auto and column-count is auto:
    (This is not a multi-col element; the pseudo-algorithm exits at
    line 2.)

  If column width is auto and column-count is NOT auto:
    (In this case, the pseudo-algorithm exits at lines 12-14, and
    the column-count is obeyed exactly.)

    The min-content width of the contents times the column-count,
    plus one minus the column-count times the column-gap.  That is:

      (((min-content width of contents) + column-gap) * column-count)
      - column-gap

  If column width is NOT auto and column-count is auto:
    (In this case, the pseudo-algorithm exits at lines 16-18, and
    the number of columns is a function of the available width such
    that at narrow widths there will be one column.)

    The column-width.

    I don't think it makes a whole lot of sense to honor the
    min-content width of the contents in this case; in cases where
    that's larger than the column-width that can just lead to having
    multiple columns *each* of which doesn't hold the contents.
    (This is one of the contradiction cases I described above.)

  If column width is NOT auto and column-count is NOT auto:
    (In this case, the pseudo-algorithm exits at lines 16-18, and
    the number of columns is a function of the available width such
    that at narrow widths there will be column-count columns.)

    The column width times the column count, plus one minus the
    column-count times the column-gap.  That is:
      (column-count * (column-width + column-gap)) - column-gap

    Just as for the previous case, I don't think it makes sense to
    honor the min-content width of the contents.

These cases could be condensed into:

If column-count is auto:
  N := 1
else:
  N := column-count

If column-width is auto:
  W := min-content width of contents
else:
  W := column-width

result := (N * (W + column-gap)) - column-gap

> max-content width:
>   If the used column count is 1, then the max-content width is the
>   minimum of the max-content width of the contents and the used
>   column width. *
>   If the used column count is more than 1, then the max-content width
>   is calculated from the used column width, used column count, and
>   used column gap. **
>   - If both column-width and column-count are set, these give the
>     used column width and used column count. ***
>   - If only column-width is set, the used column count is found by
>     filling columns of exactly column-width, using any applicable
>     height constraints.
>   - If only column-count is set, the used column width is the
>     maximum of
>       - the min-content width of the contents and
>       - the column width that results in a balanced columns
>         height that most closely fits within any given height
>         constraints, or,
>       - if there are no height constraints, the column width
>         that would be that would be calculated for a normal
>         auto-width block (using the fallback width if the
>         available width is undefined).
>     ****

I think this is confusingly written, and the terms "used column
count" and "used column width" are bad choices since they sound like
used values of a property, which (I think) they are not.  I think you
should both rename the terms and define them before use.

I also worry that this use of height constraints will be very
expensive (i.e., slow) and disruptive to implement; it goes back to
making intrinsic widths depend on layout information, which is
something that some implementations (old IE and old Gecko) used to
do but explicitly moved away from (and thus substantially increased
interoperability).  It's unlikely to be something I'd be comfortable
implementing prior to the next complete rewrite of our layout
algorithms, and I think it's something you need to get all layout
engine developers on-board with.

And, finally, for the two reasons I described for min-content width
(one of which was the contradiction I described at the beginning of
the message), I think you should not propagate max-content widths of
content through a specified column width.

> fit-content width:
>   max(min-content,min(max-content, available))
>   Equivalent to max-content if available width is not defined.

This is true in general and should not be redefined specifically for
columns.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Wednesday, 22 June 2011 18:09:48 UTC