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 09:46:22 UTC