[fxtf-drafts] [motion] defining "computed distance" (aka "used distance")

fantasai has just created a new issue for 
https://github.com/w3c/fxtf-drafts:

== [motion] defining "computed distance" (aka "used distance") ==
> To determine the computed distance for a given path and distance:
>
>  Let the total length be the total length of path with all 
sub-paths.
>
>  - If distance is a length: Let upper bound be equal to the total 
length.
>    Otherwise: Let upper bound be equal to 100%.
>  - If path is an unbounded ray: Let computed distance be equal to 
distance.
>    Otherwise: if path is an <angle> path with contain: Let computed 
distance be equal to distance, clamped by -upper bound and upper 
bound.
>  - If path is any other unclosed interval: Let computed distance be 
equal to distance clamped by 0 and upper bound.
>    Otherwise: path is a closed loop: Let computed distance be equal 
to distance modulus upper bound.

This section confuses me a lot, I can't quite tell what it's trying to
 do.

First off, I suggest moving it into the `offset-distance` section, 
since it's effectively defining that value.

Secondly, why are you defining separate behaviors for lengths vs 
percentages? calc() can combine the two, so definitely something is 
wrong with your definition here.

Third, I don't think that rays with/without contain should be handled 
differently here. (That's filed separately over in 
https://github.com/w3c/fxtf-drafts/issues/61 though.)

Fourth, how about instead of defining upper bound as "total length" 
(of the path), just reusing the already-defined "total length of the 
path"? Introducing multiple terms that mean the same thing is 
unnecessary cognitive load...

p.s. Use U+2212 for minus signs, particularly if you're negating a 
variable: it's clearer what's going on than using U+002D which often 
looks more like a hyphen.

Maybe once you sort all that out it'll be readable enough. :)

Please view or discuss this issue at 
https://github.com/w3c/fxtf-drafts/issues/74 using your GitHub account

Received on Saturday, 5 November 2016 03:36:43 UTC