Re: [css3-values] Required minimum precision

On Thu, 28 Jun 2012 21:21:47 +0200, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> During the last telcon, we claimed that we hadn't posted our proposal
> for required minimum precision.  We're dumb - it was already in the
> draft: <http://dev.w3.org/csswg/css3-values/#limits>.
>
> So, we need to either approve this, edit it, or defer it to level 4.
>
> Thoughts?  Can implementors please take a look and let us know if
> these limits are acceptable minimums?

Ignoring for a moment whether or not this matches what we currently
implement,
here are some comments.

1) in all the places that say "2^24 - 1", switch to "2^23 -1". 24 bits is
what
we're aiming for.

2) Just like % and numbers, precision on lengths, angle, time and
frequency should only be mandated within a range.

3) "6.2.  Times: the ‘<time>’ type and ‘s’, ‘ms’ units" and "9. Appendix A"
contradict eachother.

"Properties may restrict the time value to some range. If the value is
outside the allowed range, the declaration is invalid and must be ignored."

vs

"Values outside the supported range must be clamped into the supported
range."

4) For things with a unit, the wording is unclear:

4.a) Does minimum precision of 1ms mean you have to support 0.001s as
well? Does a required 0.1px imply
you must support 0.0010417 inches? I wouldn't want that. The minimum
precision should be specified in terms of the value stripped of its unit.

4.b) Minimum maximum values are all expressed in terms of the smallest
unit allowed for the dimension. Unlike 4.a, this is a good thing that
needs to stay. Because at some points we convert lengths into pixels,
requiring support 2^23-1 inches would not be good.

5) I am not entirely sure we want to require support for sub-pixel
precision lengths. It definitely is nice to have, but is it really
necessary?

6) "Values specified with an unsupported amount of precision must be
rounded to the closest supported value; except that values that are not
equal to, but would round to, either zero or the boundary of a closed
range, are rounded away from that value rather than to it."

At parse time, it would be possible to require this. I am far from
enthusiastic doing the necessary changes in the parsing code, but I can
see why it could be interesting to have, so I'll just be mildly opposed to
it, not outright objecting.

On the other hand, I am absolutely against having that constraint anywhere
else than parsing. FPUs can't enforce that requirement, so we'd have to
have extra conditional logic at every place any calculation is done, and
this is just not acceptable. It would require a significant (and long
term) coding effort, and impact performance.

      - Florian

Received on Friday, 29 June 2012 10:58:05 UTC