W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > April 2017

Re: [fxtf-drafts] [motion] No model for interaction of `offset-position` and shapes

From: shans via GitHub <sysbot+gh@w3.org>
Date: Sat, 22 Apr 2017 09:27:12 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-296360745-1492853230-sysbot+gh@w3.org>
We discussed this at length after the f2f. Essentially we realized that there's a matrix of desirable behaviors:

(1) the offset element can be positioned either relative to its container, or relative to its laid out position
(2) the path can be defined with units relative to the container, or with units relative to the element (note that SVG content is currently unable to provide relative units and so is a subset of both of these)

For paths and rays, offset-position: auto opts into element-relative positioning, while other offset-position values anchors the path inside the container (note that there is some discussion about exactly how this should work for paths, one mechanism is that paths implicit moveto is to (0,0) if none is specified, and that the coordinate space for a motion path is zeroed at the offset-position.)

We could allow the same behavior for basic shapes with a position (circles and ellipses) if we specified that omitting position information for these shapes falls back to the position specified in offset-position.

This is not true of other shapes or geometry boxes, however - they're always defined relative to the container and don't have a position.

In other words, we have:

|  | no relative coordinates | coords relative to container | coords relative to element |
| position rel to container | path()*, url() | ray(), circle(), ellipse(), other shapes, boxes | |
| position rel to element | path()*, url() | ray(), circle()@, ellipse()@ | |

* assuming we can "start" paths at the offset-position
@ if circles and ellipses fallback on offset-positioning for position

Given that nothing operates relatively to elements yet, we think this can be deferred to L2. That leaves the following problems:
(1) paths can't be specified relative to the container. One suggestion for fixing this was to define a CSS path syntax.
(2) there's no simple rectangle or polygon shape that can be positioned relative to the element. CSS path syntax somewhat fixes this, but for rectangles we thought that adding a new rect() type that included a position and width/height information would be useful.
(3) we need to specify the fallback behavior for circle and ellipse
(4) we need to specify path() positioning and make sure it makes sense

@tabatkins @fantasai @jihyerish did I capture our discussion correctly?

GitHub Notification of comment by shans
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/78#issuecomment-296360745 using your GitHub account
Received on Saturday, 22 April 2017 09:27:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 November 2018 00:45:57 UTC