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

On 02/20/2013 03:00 PM, Simon Sapin wrote:
>
>> 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

s/may/can/ and otherwise I think the quoted note is fine.

> 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.)

I agree here.

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

Well, technically in CSS2.1 the UA is not required to handle variable-width
fragmentation. This is required only for Level 3 Fragmentation.

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

I think it's fine to leave it here, but s/honored/considered/ is needed.

Otherwise the edits in the patch you attached look alright.

~fantasai

Received on Thursday, 21 February 2013 00:57:09 UTC