[css3-multicol] Proposed edit for the pseudo-algorithm

Le 20/02/2013 16:34, Bert Bos a écrit :
> Hello Håkon and Simon,
>
> When I wrote the previous suggested replacement, I thought the
> problem was that the CR text wasn't precise enough and so I rewrote
> the text to use only terms from level 2.
>
> But at the ftf, the WG decided that the problem was the opposite: the
> pseudo-algorithm was too precise: it didn't leave us room to
> partially ignore the column count or width, in case we decide in the
> future that the intrinsic size should not fully take them into
> account.
>
> So here is my new suggested text. The text no longer specifies that
> the intrinsic size only depends on the column count and the column
> width if the column count is non-auto. Nor does it specify that the
> intrinsic size is column count * column width if both are known.
> Instead, there is a new note that says simply that the used width
> depends on column count and width, without saying how.
>
> Summarized in table form:
>
> width      | c-count | c-width | old                      | new
> -----------+---------+---------+--------------------------+----------
> outside-in | auto    | auto    | no columns
> outside-in | auto    | W       | use W or slightly bigger
> outside-in | N       | auto    | use N
> outside-in | N       | W       | min(N, width/W) columns
> inside-out | auto    | auto    | no columns
> inside-out | auto    | W       | no columns               | undefined
> inside-out | N       | auto    | undefined
> inside-out | N       | W       | N * W                    | undefined
>
> Before I send it to the WG, can you check what you think of it?
> See attachment.
> (This corresponds to ACTION-539)

(Bert’s proposed changes are attached.)

Hi Bert,

I still believe that technical discussions should happen in public. Our 
thousand subscribers are used to filtering stuff they don’t care about. 
Adding www-style to CC, as well as dbaron and fantasai since they were 
both involved in the F2F discussion in Tucson.

It seems that your understanding of what happened during the F2F and why 
is not the same as mine, but I’ll skip arguing about that and focus on 
the proposed text:

> U is the used width of the multi-column element.
>
> Note: The used width U of the multi-column element may depend on the
> element's contents, in which case it also depends on the computed
> values of the 'column-count' and 'column-width' properties. This
> specification does not define how U is calculated. Another module
> (probably the Basic Box Model [[CSS3BOX]] or the Intrinsic &
> Extrinsic Sizing Module [[CSS3-SIZING]]) is expected to define this.

I’m uncomfortable with this wording as it implies that U is undefined.
What’s undefined is not U but the preferred widths. Multicol applies to 
block containers [1], and various kinds of block containers (from normal 
blocks to floats and flex items) each define how to determine their used 
width.

[1] http://lists.w3.org/Archives/Public/www-style/2013Feb/0536.html


Proposed text to replace the one quoted above:

> U is the used width of the multi-column element. It is the same as if
> the element were not multi-column.
>
> Note: In some cases (for example in the element is a float with
> 'width: auto') U can be based on the preferred width and minimum
> preferred width of the element, which are undefined at this level,
> but are expected to be defined in a later level or in the Intrinsic &
> Extrinsic Sizing Module [[CSS3-SIZING]]


Back to the proposal:

> Two assumptions are being made by the pseudo-algorithm:
>
>     that the block direction is unconstrained
>     that no column breaks are added through style sheets

Why do these assumptions matter? Is the algorithm just undefined if they 
don’t hold?

I suggest just removing the quoted text. The algorithm always define the 
used values of column-width and column-count. The actual number of 
columns can be different due to "overflow columns" as described in §8.2, 
but that does not need to affect the algorithm (or the used value.)


> In paged media, user agents may perform this calculation on a
> per-page basis.

Shouldn’t that "may" be a "must"? Consecutive pages can have a different 
size, so fragments of the same multicol element could have different 
used widths.


> However, both 'column-width' and 'column-count' are honored when the
> width of the element has not been determined depends on its contents.
> This can, e.g., be the case for table cells and floats.

There is no normative basis in css3-multicol anymore for this part of 
the note. It should be move to wherever the preferred widths are defined.


-- 
Simon Sapin