Re: [css3-values] required ranges for values

On Tue, Apr 17, 2012 at 3:48 PM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> wrote:
>  # unsupported values must be clamped to the closest supported value.
>
> First of all, if an implementation implements <number> with a floating
> point value, is clamping here clamping to the biggest finite number or
> the Infinite (no clamping)? (I should note that in Firefox, Infinity% is
> possible)

Infinity is infinitely far away from any finite value, so by
definition it can't be the "closest supported value" unless you
started with infinity. ^_^


> If the answer to the question above is "the biggest finite number", I
> the spec should mention when clamping happens. It's especially unclear
> whether and when this is done in a calc(). (I think clamping is done for
> each 'counter-increment') I suggest we say this happens when a value is
> parsed and make it undefined in a calc().

Clamping at parse-time for normal values is good.

For calc(), we agree that it's fine to leave the precise clamping
behavior undefined, but we at least need to specify that you *do* need
to clamp, and can't ever overflow.

> (If we seriously want to spec this, we need to decide a base unit for
> calculations in calc(), which seems rather undesirable.)
>
>
> In general, I don't think we care too much about some of these issues,
> so I suggest we move all these statements to a new section and just mark
> it "informative". (It's also not clear to me how you write tests for
> "the declaration must be ignored as if it were invalid" if these are
> unlimited...)

These limits exist solely to help testing, actually.  ^_^  They give
us a reasonable range of values that we can test against.  Otherwise,
tests can fail just because we accidentally chose "too large" of a
number for a particular implementation.  You're allowed to support
higher numbers than the minimum range.  Hell, if you wanted to use
bignums and computable reals for your implemention, that's fine.

Anyway, these have been logged.  For calc(), we've made the change we
outlined above.

~TJ

Received on Wednesday, 18 April 2012 00:17:58 UTC