Re: [css-multicol] column-width bound (>0) is illegal

Le 2013-10-15 14:50, Tab Atkins Jr. a écrit :
> On Tue, Oct 15, 2013 at 11:14 AM, Gérard Talbot <www-style@gtalbot.org> 
> wrote:
>> Le 2013-10-15 11:38, Tab Atkins Jr. a écrit :
>>> Per our design patterns for CSS properties (apparently not written
>>> down anywhere, unfortunately*), we don't use open continuous
>>> intervals
>> 
>> I've read your message several times and I'm not sure I understand 
>> it... and
>> what you may mean with open continuous intervals.
> 
> Apologies, these are standard mathematical terms in English.
> 
> "Open" and "closed" intervals refer to whether the endpoint is
> included in the interval or not.  These may also be called "exclusive"
> and "inclusive" intervals.
> 
> "Continuous" was used to mean the opposite of "discrete".  The CSS
> <number> type is continuous - you can subdivide it as finely as you
> wish (though there are of course implementation-defined limits on the
> precision you can achieve), while the CSS <integer> type is discrete -
> there is a minimum distance between consecutive values.
> 

Okay. Clear now. Thank you for providing a full answer on this.


>>> , because then whether something is valid or invalid depends
>>> on unpredictable and UA-specific rounding behavior.
>>> 
>>> However, 'column-width' states that its value must be a <length>
>>> greater than zero.  This violates that constraint.
>> 
>> "
>> A length is a dimension. (...)
>> A dimension is a number immediately followed by a unit identifier. 
>> (...)
>> A number is either an <integer> or zero or more decimal digits 
>> followed by a
>> dot (.) followed by one or more decimal digits.
>> "
>> http://www.w3.org/TR/css3-values/#lengths
>> 
>> Are you saying that column-width must not be using a real number (eg
>> column-width: 12.5px;)?
> 
> No.  You're focusing on the wrong part of that sentence - the relevant
> part is the "greater than zero", which means that 0.1, 0.01, 0.001,
> 0.0000000...01 are all technically valid, but 0 is invalid.  The issue
> is that, in reality, at some point rounding or precision limits kick
> in, and a value that is "technically" greater than zero gets converted
> to zero, thus making the declaration invalid.  Because this point is
> impossible to predict ahead of time, and may differ between UAs and
> even within a single UA over time, it is bad to make the validity of
> the property depend on it.
> 
>>> I suggest that we instead state that there is a minimum size for
>>> columns (1px? ua-specific?), and that values less than this minimum
>>> are clamped to the minimum.  Values less than zero are still invalid,
>>> as they're nonsensical.
>> 
>> You say minimum is 1. The spec says greater than 0. Isn't those 
>> equivalent?
> 
> No.  There are an infinity of values between 0 and 1.
> 
>> http://test.csswg.org/suites/css3-multicol/nightly-unstable/html4/multicol-count-large-001.htm
>> 
>> http://test.csswg.org/suites/css3-multicol/nightly-unstable/html4/multicol-count-large-002.htm
>> 
>> In both these tests, the column-count is 1000 while the width of the
>> multi-column container is 192px. Is your message related somehow to 
>> these 2
>> tests ?
> 
> Not really, no.  Those are dealing with large column-count values.
> This message is about small column-width values.
> 
>> please put the text "css3-multicol" in the subject and not 
>> "css-multicol" in
>> the future.
> 
> Both are used in practice, and specs advocate a mixture of them.

Using only "css3-multicol" (or just 1 of the 2) is going to give more 
reliable results when searching the archives.

Status section says: "css3-multicol" and not "css-multicol".

http://dev.w3.org/csswg/css-multicol/

http://www.w3.org/TR/css3-multicol/


> Since "cssN-foo" is no longer the shortname pattern in use for specs,
> it would be odd to continue using it for the subject indicator.
> 
> ~TJ

Okay. I see your point.
Also the feedback line in dev.w3.org/csswg/css-multicol/ uses

"with subject line “[css-multicol] … message topic …” (archives) "

Gérard

Received on Tuesday, 15 October 2013 19:06:19 UTC