- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Mar 2018 16:44:09 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Contradictions about whether zero is allowed for 'column-width'<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1741<br> <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.<br> <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?<br> <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.<br> <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.<br> <dael> Rossen: I see.<br> <TabAtkins> (staying in irc to avoid noise)<br> <TabAtkins> The problem with disallowing 0 *syntactically* is that it makes an open range, which we don't allow<br> <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.<br> <TabAtkins> Just add a ua-defined minimum<br> <dael> Rossen: I'd hate that magic.<br> <TabAtkins> Yeah<br> <TabAtkins> We use that "magic"elsewhere<br> <dael> Rossen: If we have an explicit floor let's have it be 1 or whatever. THe magic value would only increase interop gaps.<br> <dael> Rossen: So it better be explicit. Since today is 3.14 let's make it 3.14<br> <dael> Rossen: What makes sense here? What should we do?<br> <TabAtkins> I'm fine with an explicit noon-zero min, it's just arbitrary.<br> <florian> I support allowing 0, and requiring any number smaller than 1px being rounded to 1px<br> <dael> Rossen: dbaron or rachelandrew do you have a proposal?<br> <dael> rachelandrew: For me 0 does make sense to allow but I don't have impl experience to know if it causes problems elsewhere.<br> <dael> florian: I wrote my proposal in IRC.<br> <dael> Rossen: By allowing 0 we round it to 1px regardless?<br> <dael> florian: yes<br> <fantasai> I agree with not making this minimum syntactic<br> <dael> Rossen: So allowing 0 is parsing but clamp to 1px.<br> <dael> florian: Right. And this is error handling. Really no one creates columns of 0.01px<br> <astearns> +1<br> <dael> Rossen: Opinions on this proposal? Allow 0 for parsing but keep clamping at 1px<br> <dbaron> sounds fine to me<br> <fantasai> I would go with less than 1px if we can<br> <dael> plinss: Can it be some epsilon value?<br> <TabAtkins> Thus my "UA-defined minimum" wording previously...<br> <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.<br> <fantasai> 0.5px?<br> <dael> plinss: UNderstood. I won't argue too strong. I think 1px might be too big in some cases.<br> <dael> Rossen: Let's cross the bridge when we get there.<br> <dael> plinss: Author can set smaller.<br> <dael> fantasai: They can't.<br> <dael> florian: But columns smaller then 1px isn't text layout. They're trying to do canvas so they should use canvas.<br> <TabAtkins> Yeah, that's silly. There's zero call for 1px columns, even.<br> <dael> plinss: There's situations where 1px isn't what you thik a pixel is. They're doing microprinting.<br> <TabAtkins> But it's a reasonable chesterton fence<br> <dael> plinss: But I don't think it's that big of a deal.<br> <dael> jensimmons: Are column widths animatable?<br> <dael> astearns: In threory they probably are.<br> <TabAtkins> Yes, they are.<br> <dael> dbaron: It is. It doesn't get performance optimizations, but it is animatable.<br> <florian> I'm ok with tab's variant (UA defined epsilon) as well, but I tend to side with Rossen, and would prefer interop<br> <dael> myles: But doing that isn't a strong argument. It can't be negative.<br> <TabAtkins> I don't care. Fine with explicit 1px minimum.<br> <dael> jensimmons: It's an argument to make it not 0.<br> <dael> Rossen: If you're animating between 0 and 10 I guess, but this would happen for any sort of clamping we choose.<br> <TabAtkins> (If it were possible I'd want a syntactic restriction to 1px, but it's not really.)<br> <dael> jensimmons: Yes, thinking it through and it makes sense. Animating from 1px to 12my is possible, but from infinity is not.<br> <jensimmons> *12em<br> <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<br> <dael> Rossen: Objections?<br> <dael> RESOLVED: We allow 0 for column-width for the purpose of parsing, 1px is the minimum clamping value used for anything after parsing<br> <dael> rachelandrew: I'll make the edit<br> <dael> florian: Is clamping at used time or contribute value time?<br> <dael> Rossen: It has to be used value<br> <dael> florian: Could be earlier.<br> <dael> Rossen: Sure. You can do it at parse time if you want to.<br> <dael> florian: You're going for interop so maybe we can define.<br> <dael> Rossen: I don't believe it will be observable either way.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1741#issuecomment-373091628 using your GitHub account
Received on Wednesday, 14 March 2018 16:44:12 UTC