[css-multicol] Contradictions about whether zero is allowed for 'column-width'

[rachelandrew]

In May 2011 @dbaron raised this issue against multicol:

http://dev.w3.org/csswg/css3-multicol/#cw seems to give two different answers as to whether zero is a legal value for column-width:
Computed value: the absolute length, zero or larger
and then:
Specified values must be greater than 0.

I feel quite strongly that zero should be allowed, because I'm strongly opposed to CSS having any value range restrictions that require an open range (i.e., one where the endpoints are not allowed).

I think open ranges are a problem both because:

(1) They seem likely to lead to interoperability problems if people want to try to get the "minimal value", since rounding may vary between implementations.

(2) We have multiple features that require clamping values to the allowed range:
(a) calc()
(b) interpolation in transitions or animations, when the cubic-bezier() timing function has Y1 or Y2 values outside of the 0-1 range and clamping to an open range does not make sense. Sensible clamping requires a closed range.

So I think either '0' needs to be allowed or, if that makes the algorithm nonsensical, the range restriction needs to be changed to start at some other value.

As far as I can tell this wasn't addressed, opening here for further discussion.

[rachelandrew]

There is discussion in 2013, raised by @tabatkins regarding column widths of 0. See column-width bound (>0) is illegal

[tabatkins]

Yeah, we've pretty strictly applied the "no open ranges" rule, except when compat restricts us (like in transform-origin). I think the right answer here is obvious - allow zero, require UAs to clamp to a UA-specific minimum value, suggested to be 1px.

[ewilligers]

I just came across this inconsistency while testing column-width animation, and was about to create an issue recommending that we accept any non-negative value, when I search and found that this issue had already been raised.

They seem likely to lead to interoperability problems

It has (Test):

Firefox accepts 0px and 0em as specified values for column-width. Other browsers reject these values.

Edge never gives 0px as a computed value of column-width (e.g. as the result of a calc expression, or when font-size is 0px), instead it gives a fraction of a pixel. Other browsers can give 0px as a computed value of column-width.

As Chrome and Safari can give 0px as a computed value, but don't accept 0px as a specified value, they don't round-trip.

[mstensho]

Allowing column-width:0 makes sense, but if column-gap is also 0 at the same time, we'll end up with an infinite used column-count, and there'll be no progression in the inline direction. Apart from that, the only interesting implication of infinite column-count that I can think of, spec-wise, is column balancing:

<div id="mc" style="column-width:0; column-gap:0;">
  <div style="height:10000px;"></div>
</div>

With auto height and column balancing and an infinite number of columns, we'll end up with a silly height of #mc. We have 10000px to distribute over ∞ columns, so even a height of 0 would do in that sense, except that then we'd have no block progression, and luckily a fragmentainer is required to be >= 1px tall [1]. So we'll "only" end up with 10000 columns?

[1] https://www.w3.org/TR/css-break-3/#breaking-rules

[css-meeting-bot]

The Working Group just discussed Contradictions about whether zero is allowed for 'column-width', and agreed to the following resolutions:

• RESOLVED: We allow 0 for column-width for the purpose of parsing, 1px is the minimum clamping value used for anything after parsing

The full IRC log of that discussion

<dael> Topic: Contradictions about whether zero is allowed for 'column-width'
<dael> github: https://github.com//issues/1741
<dael> rachelandrew: I dug this out of the archives and has various comments. Is 0 allowed for column width. dbaron wrote some stuff that came out of the email archives. THere were a few comments on that post.
<dael> rachelandrew: There was a comment that said if column-width and column-gap are 0 we'd have an infinite situation. So does the range restriction change or do we allow?
<dael> Rossen: dbaron is the point that having 0 width columns that if they are 0 width then everything will be fragmented and pushed forward? If ew I think we addressed in fragmentation where we defined meaningful progress and you always need ot make progress in direction of consuming content.
<dael> dbaron: I was concerned about the # of columns you get. If you don't have column count it comes from column width and in this case would be infinite.
<dael> Rossen: I see.
<TabAtkins> (staying in irc to avoid noise)
<TabAtkins> The problem with disallowing 0 *syntactically* is that it makes an open range, which we don't allow
<dael> florian: I believe that's why we at some point said - is not okay, but that makes a difference between 0 and 0.00000001 so we said that 0 is allowed but may round to a small value.
<TabAtkins> Just add a ua-defined minimum
<dael> Rossen: I'd hate that magic.
<TabAtkins> Yeah
<TabAtkins> We use that "magic"elsewhere
<dael> Rossen: If we have an explicit floor let's have it be 1 or whatever. THe magic value would only increase interop gaps.
<dael> Rossen: So it better be explicit. Since today is 3.14 let's make it 3.14
<dael> Rossen: What makes sense here? What should we do?
<TabAtkins> I'm fine with an explicit noon-zero min, it's just arbitrary.
<florian> I support allowing 0, and requiring any number smaller than 1px being rounded to 1px
<dael> Rossen: dbaron or rachelandrew do you have a proposal?
<dael> rachelandrew: For me 0 does make sense to allow but I don't have impl experience to know if it causes problems elsewhere.
<dael> florian: I wrote my proposal in IRC.
<dael> Rossen: By allowing 0 we round it to 1px regardless?
<dael> florian: yes
<fantasai> I agree with not making this minimum syntactic
<dael> Rossen: So allowing 0 is parsing but clamp to 1px.
<dael> florian: Right. And this is error handling. Really no one creates columns of 0.01px
<astearns> +1
<dael> Rossen: Opinions on this proposal? Allow 0 for parsing but keep clamping at 1px
<dbaron> sounds fine to me
<fantasai> I would go with less than 1px if we can
<dael> plinss: Can it be some epsilon value?
<TabAtkins> Thus my "UA-defined minimum" wording previously...
<dael> Rossen: What's wrong with 1px? It's much easier to explain and be interop on. If we do epsilon one browser will give you a different value then another. I'd rather be interop even in this weird edge case.
<fantasai> 0.5px?
<dael> plinss: UNderstood. I won't argue too strong. I think 1px might be too big in some cases.
<dael> Rossen: Let's cross the bridge when we get there.
<dael> plinss: Author can set smaller.
<dael> fantasai: They can't.
<dael> florian: But columns smaller then 1px isn't text layout. They're trying to do canvas so they should use canvas.
<TabAtkins> Yeah, that's silly. There's zero call for 1px columns, even.
<dael> plinss: There's situations where 1px isn't what you thik a pixel is. They're doing microprinting.
<TabAtkins> But it's a reasonable chesterton fence
<dael> plinss: But I don't think it's that big of a deal.
<dael> jensimmons: Are column widths animatable?
<dael> astearns: In threory they probably are.
<TabAtkins> Yes, they are.
<dael> dbaron: It is. It doesn't get performance optimizations, but it is animatable.
<florian> I'm ok with tab's variant (UA defined epsilon) as well, but I tend to side with Rossen, and would prefer interop
<dael> myles: But doing that isn't a strong argument. It can't be negative.
<TabAtkins> I don't care. Fine with explicit 1px minimum.
<dael> jensimmons: It's an argument to make it not 0.
<dael> Rossen: If you're animating between 0 and 10 I guess, but this would happen for any sort of clamping we choose.
<TabAtkins> (If it were possible I'd want a syntactic restriction to 1px, but it's not really.)
<dael> jensimmons: Yes, thinking it through and it makes sense. Animating from 1px to 12my is possible, but from infinity is not.
<jensimmons> *12em
<dael> Rossen: Proposal: We allow 0 for column-width for the purpose of parsing, 1px is the minimum clamping value used for anything after parsing
<dael> Rossen: Objections?
<dael> RESOLVED: We allow 0 for column-width for the purpose of parsing, 1px is the minimum clamping value used for anything after parsing
<dael> rachelandrew: I'll make the edit
<dael> florian: Is clamping at used time or contribute value time?
<dael> Rossen: It has to be used value
<dael> florian: Could be earlier.
<dael> Rossen: Sure. You can do it at parse time if you want to.
<dael> florian: You're going for interop so maybe we can define.
<dael> Rossen: I don't believe it will be observable either way.

[dbaron]

I tend to think that for animation, the clamping should be at used value time rather than computed value time.

[rachelandrew]

So in terms of wording for the spec. The current wording for computed value is correct "the absolute length, zero or larger"?

And this new wording should replace, "Specified values must be greater than 0" with something like:

"Specified values of 0 are allowed, however the used value of any value less than 1px will be clamped at 1px."

[ewilligers]

"Specified values of 0 are allowed, however the used value of any value less than 1px will be clamped at 1px."

It needs to be clear if specified values may be negative (no) or between 0 and 1 (yes).

We could have the common wording "Negative values are not allowed." and "the absolute length" instead of having unusual wording for the specified and computed values. And add "Used values will be clamped to a minimum of 1px."