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

On Mon, Feb 18, 2013 at 11:02:33PM -0500, Zack Weinberg wrote:

> >>§4.4.13, §4.4.14 (number-rest, number-fraction): The numeric value of
> >>a percentage token should be "the number produced by interpreting the
> >>number token's representation as a base-10 number" *divided by 100*.
> >>(It might be better to state this in css3-values "Percentage" section
> >>instead, but that's already in CR and doesn't say anything of the sort
> >>right now.)
> >
> >We can still make clarifications in CRs, but I think it’s pretty clear
> >what a percentage means. In my mental model though, the division by 100
> >only occurs when resolving a percentage relative to some other value.
> >The percentage’s own "value" goes up to 100, not 1.
> 
> This may be me projecting internal Gecko behavior onto the spec.  I
> don't care all that much what the official "value" of a percentage
> token is, since it's going to be reserialized as x% regardless.

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.

pjrm.

Received on Tuesday, 19 February 2013 12:41:04 UTC