RE: [css3-values] required ranges for values


[Kang-Hao (Kenny) Lu:]
> 
> The current draft has this to say
> 
>   # For repeated component values (indicated by ‘*’, ‘+’, or
>   # ‘#’), UAs must support at least 30 repetitions of the component.
>   # If a property value contains more than the supported number of
>   # repetitions, the declaration must be ignored as if it were invalid.
> 
>   # UAs must support ‘calc()’ expressions of at least 30 terms, where
>   # each ‘number’, ‘dimension’, or ‘percentage’ is a term. If a
>   # ‘calc()’ expression contains more than the supported number of
>   # terms, it must be treated as if it were invalid.
> 
> For the number '30', I should note that in my support of the restyling
> effort[1], I already used about '60' gradients as background. I don't
> think my example is common but I think it's a valid user case and I don't
> want my example fail to work just because this mysterious restriction. Is
> there any evidence that providing a finite number here would help make
> more conforming user agents? I should note that there's no limit for the
> size of the CSS document and the number of rules and declarations it could
> contain.

I missed this change; where does this number come from?

> Having said that, based on testing, calc() in IE9 supports only about 20
> terms, so... I am willing to trust the data from a Microsoft person here.
> 
>   # Properties may restrict the percentage value to some range. If the
>   # value is outside the allowed range, the declaration is invalid and
>   # must be ignored. For unrestricted values, UAs must support at least
>   # up to ±2^30%; unsupported values must be clamped to the closest
>   # supported value.
> 
> Based on getComputedStyle, IE9 only supports up to 0.01 * 2^31% =
> 21474836.48%, which is less than 2^30% = 1073741824% . I haven't tested
> the others, but I don't think we care this too much to the point that we
> really want to make IE9 non-conforming. I suggest we lower this number for
> IE.

Likewise, how was this limit chosen?
> 
>   # Properties may restrict the number value to some range. If the
>   # value is outside the allowed range, the declaration is invalid and
>   # must be ignored. For unrestricted values, UAs must support at least
>   # up to ±2^30; unsupported values must be clamped to the closest
>   # supported value.
> 
> Besides 'animation-iteration-count', 'flex-order' and 'font-size-adjust-
> prop', all other <number>-accepting properties eventually becomes a
> "length", and ±2^30 is too big for "length", which doesn't have an
> explicit number in the corresponding section at the moment. (Only tested
> with 'line-height' on Firefox)
> 
> 
> Various types have
> 
>   # 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)
> 
> 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().
> 
> (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...)
> 
> [1] http://lists.w3.org/Archives/Public/spec-prod/2012AprJun/0005

> 
> 
> Cheers,
> Kenny
>

Received on Tuesday, 17 April 2012 23:58:30 UTC