[css3-values] required ranges for values

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.

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.

  # 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 22:49:17 UTC