[fxtf-drafts] [motion] Editorial Comments

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

== [motion] Editorial Comments ==
- [ ] Needs an overview that ties together all the properties into a 
coherent mental model, that the reader can keep in mind while learning
 about each part in more depth, perhaps at the beginning of Chapter 4.
 Something like
  > The Motion Path module allows specifying the position of a box as 
the distance (`offset-distance`) of the box's anchor point 
(`offset-anchor`) along a geometrical path (`offset-path`) defined 
against the coordinates of its containing block. The box's orientation
 can optionally be specified as a rotation with respect to the 
direction of the path at that point.
- [ ] Audit all instances of "element" to make sure it is correctly 
using the term "box" and/or "containing block" (or an equivalent term 
that encompasses the SVG model). "element" and "containing element" 
are not correct terms to use for layout specs, only for DOM specs, 
css-cascade, and other things that actually talk about the element 
tree. See https://www.w3.org/TR/css-display-3/#intro

- [ ] In the definition of `<angle>` paths, group the various 
parameters under a single entry for `ray( <angle> && <size>? && 
contain?)`.  You can then have sub-entries for each parameter. Right 
now the parameters are at the same level as e.g. `<basic-shape>`, 
which isn't right.

- [ ] You use the term "path" with a very specific definition: the 
path being, specifically, the path specified by the `offset-path` 
property and used for positioning the box under the system described 
in this module. But the term "path" is very generic and has many 
meanings throughout CSS and SVG. I recommend using a more specific 
term, that has this specific meaning, and use that consistently 
throughout. This will make the spec much tighter in its definitions, 
without relying solely on hyperlink formatting. Same issue with 
"distance".

- [ ] On a related note, "anchor point" should be a defined term.

- [ ] Given that the "computed distance" in the Offset Processing 
section is not the computed value of any property, I think you should 
use a different term here.


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

Received on Saturday, 5 November 2016 03:12:41 UTC