W3C home > Mailing lists > Public > www-style@w3.org > February 2013

Re: [css3-syntax] value of PERCENTAGE tokens (Re: Critique of Feb 15 draft

From: Simon Sapin <simon.sapin@kozea.fr>
Date: Tue, 19 Feb 2013 17:11:44 +0100
Message-ID: <5123A440.20503@kozea.fr>
To: Peter Moulder <peter.moulder@monash.edu>, www-style@w3.org
Le 19/02/2013 13:40, Peter Moulder a écrit :
> Without having tested, I wouldn't rule out that it can make a difference
> due to different rounding behaviour: dividing in advance will typically
> introduce rounding error, and I can't be certain that that error would
> happen to be undone when we get around to multiplying (by width of
> containing block or whatever): i.e. I'm not certain that x *
> percentage.value and x * percentage.value / 100 would always get the same
> result, or rather whether the resulting assigned coordinates would always
> be the same.
> If a fractional difference can arise, then I wonder whether that fractional
> difference might make a noticeable layout difference where logic involving
> comparisons arises, e.g. "can this float fit here".  (Imagine a set of two or
> more floats and/or inline-blocks with percentage widths that theoretically add
> up to 100%.  Perhaps worse might be where they theoretically really do add
> up to slightly more than 100%, like 6 * 16.666667%; though I don't know how
> common that is.)
> The difference may well be rare in practice; I'm just saying that a priori
> there's at least some value in delaying division because I think that it
> would tend to be less subject to rounding error in at least some cases
> (though maybe only pathalogical cases, I don't know); and that (perhaps in
> contradiction to that) there's some value in applying whatever value
> representation existing implementations use, so that at least
> implementations are a*little*  more likely to get the same result for the
> 6 * 16.666667 case.
> Another, very minor, consideration in case it breaks a tie is that dividing
> in advance results in slightly shorter (so more readable) source code, not
> to mention some miniscule advantages in object code size and energy use.

These are all valid concerns for implementations, but rounding due to 
precision limits has typically been left undefined in CSS specs. I don’t 
think that Syntax or Values need to say anything about this.

Simon Sapin
Received on Tuesday, 19 February 2013 16:12:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:26 UTC