[css3-multicol] was: [CSSWG] Minutes and Resolutions 2011-02-17

>From a recent discussion on multicol:

 > Multicol algorithm
 > ------------------
 >    glazou: howcome's not on the call, but he quoted two of his messages.
 >    alexmog: Which way to go is a matter of philosophy
 >    * glazou loves when philosophy come to CSS :-D
 >    alexmog: There are a few ways to treat a situation when there's no usable
 >             layout that satisfies the constraints.
 >    * fantasai votes for adding more comments to the pseudo-algorithm =)
 >    alexmog: One way is to honor everything that is exactly defined, and just
 >             overflow if necessary.
 >    alexmog: Another is to keep content visible, so users on a phone don't get
 >             a pretty layout, but it's usable.
 >    alexmog: I think that nowhere in CSS do we alter the way we interpret
 >             properties based on whether an overflow is about to happen.
 >    alexmog: If we really care about the end-user and want to show them
 >             content, when the design intent totally fails, the best thing for
 >             the user is to just drop to a single column as soon as possible
 >             when the multicol properties can't be satisfied.
 >    alexmog: So once we shrink down to 0 col width, the next step should be
 >             to drop straight to 1 column.
 >    alexmog: I think these are the only two situations (honor exactly, or
 >             drop to 1 col quickly), and not to try and gradually relax
 >             properties, hovering around unusable states.
 >    Bert: I like the principle, but what's the practical effect of 0-width
 >          columns?
 >    alexmog: I think the page becomes unusable before 0px-wide columns.
 >    alexmog: If the column is too small, the overflow just intrudes into
 >             the column-gap.
 >    alexmog: If there's a single 0-width column, you'll see the overflow
 >             content.  With multiple columns you won't.
 >    szilles: I thought we discussed overflow columns just going to the right.
 >             Does that help in this case?
 >    alexmog: Different situation - that's where column width is specified,
 >             but not count.  This case is where column-count is specified,
 >             but not width.
 >    szilles: So really, if you want to service multiple screens, setting a
 >             fixed number of columns is a bad idea.
 >    alexmog: Without using media queries, yeah.  Setting column-width is
 >             a better approach in general.
 >    TabAtkins_: I think we should just honor things exactly.  It can produce
 >                an unusable situation, but that's easy to fix right with
 >                media queries.
 >    szilles: And what happens if I set both -width and -count?
 >    alexmog: Current spec ignores -count in that case.
 >    alexmog: I don't think that this extreme case is a good enough reason
 >             to add column-min-width.
 >    <fantasai> I thought the -count became the maximum column count?
 >    alexmog: So we have two in favor of treating things exactly as specified.
 >    bradk: Me too.
 >    szilles: i could live with it.
 >    glazou: What's the option preferred by howcome?
 >    alexmog: I'd prefer to ask him directly, but I think he was okay with
 >             either option, and just wanted consensus.
 >    szilles: "Treating things exactly" is how the spec is now, right?
 >    alexmog: No, the current spec somewhat relaxes count in some situations.
 >             It would remove 3 lines from the pseudo-algorithm.
 >    fantasai: column-count sets a maximum number of columns when used with
 >              column-width, so if you set both values you effectively get
 >              a minimum width anyway.
 >    <fantasai> You get your column count combined with a minimum width for
 >               the columns when you set both.
 >    alexmog: So I think we should ask howcome if he agrees with the consensus
 >             here.
 >    ACTION howcome to read the minutes from today and confirm if he agrees
 >           or not with the Multicol algo consensus.
 >    <trackbot> Created ACTION-297
 >    <fantasai> So if there is not room for all the columns given your
 >               column-width, the algorithm drops columns until -width is honored
 >    <fantasai> Could even recommend that authors set -width when setting -count,
 >               so that the columns don't get too narrow.

I interpret the consensus recorded in the minutes to be that
'column-count' should be honored, even if this means that the width of
columns go to zero. I agree with the consensus.

But I'm not sure how this can be implemented by removing three lines
in the pseudo-algorithm. I would implement it by removing line 17 and
20-25, which leaves us with:

(16) if (column-width = auto) then
(18)      N := column-count;
(19)      W := (available-width - ((N - 1) * column-gap))/N;
(26) fi

To make sure we don't have negative widths, we should change line 19 to:

(19)      W := max(0, (available-width - ((N - 1) * column-gap))/N);


>From the summary of the minutes:

 >    - Tentatively resolved: Remove 3 lines from multicol pseudo-algorithm
 >                that relaxes column-gap when column-count requires too
 >                many columns. Pending Håkon's review.

I don't see a discussion about relaxing column-gap in the minutes
themselves. I would suggest not trying to relax column-gap. 


Also from the minutes:

 >    fantasai: column-count sets a maximum number of columns when used with
 >              column-width

This is correct as per the prose in the description of 'column-count':

  If both ‘column-width’ and ‘column-count’ have non-auto values, the
  integer value describes the maximum number of columns.


However, it is not correct as per the pseudo-algorithm which
specifies, in line 39 that the number of columns is only a function of
available-width, column-gap and column-width:

  N := floor((available-width + column-gap) / (column-width + column-gap));


I.e., the value of 'column-count' is not taken into account. 

This is an inconsistency in the spec, it seems. 

We can resolve it by:

  (a) removing the prose in the description of 'column-count'


  (b) changing line 39 in the pseudo-algorithm to:

  N := max(column-count, floor((available-width + column-gap) / (column-width + column-gap)))


              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Tuesday, 8 March 2011 15:38:48 UTC