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

The CSS Working Group just discussed `Motion Path`, and agreed to the following resolutions:

* `RESOLVED: offset-position offsets the shape when the offset-path is a geom/shape.`
* `RESOLVED: Undo previous resolution, we're still thinking about this`

<details><summary>The full IRC log of that discussion</summary>

```
<fantasai> Topic: Motion Path
<TabAtkins> ScribeNick: TabAtkins
<jihye> https://github.com/w3c/fxtf-drafts/issues/51
<TabAtkins> shane: 4 issues I"d particularly like to discuss today; we can do the rest of the 16 if we have time
<TabAtkins> shane: The four I'd like to discuss are relevant to our impl plans
<shane> Github Topic: https://github.com/w3c/fxtf-drafts/issues/78
<TabAtkins> shane: Interaction between <shape> for path, and offset-position specified.
<TabAtkins> shane: One suggestions is when using a <shape>, offset-position is ginored.
<TabAtkins> shane: Other is to apply to offset-position as the initial offset.
<Rossen> <4 engineers trying to operate a whiteboard>
<TabAtkins> fantasai: Don't have a strong opinion, but if you can do something useful with it, that's nice.
<TabAtkins> Florian: Any difficulty with that?
<TabAtkins> fantasai: Various shapes have a start position as a possible param. So what does it mean if you have that?
<TabAtkins> RESOLVED: offset-position offsets the shape when the offset-path is a geom/shape.
<TabAtkins> fantasai: So offset-position isn't an offset, it's a position. How do you turn it into an offset?
<TabAtkins> fantasai: [elaboration on this]
<fantasai> fantasai: positioning sysntax is a position wrt four sides of a box; it's not privileging the top left corner. Don't want to turn it into a description of an offset from the top left corner.
<TabAtkins> [circle(... at <pos>) describes the center of the circle. offset-position is also a position. Adding them together is non-obvious.)
<TabAtkins> astearns: What if we let offset-position *replace* the shape's position, when defined?
<TabAtkins> shane: Eh, that doesn't seem desirable.
<TabAtkins> TabAtkins: So core if points and points don't add together.
<TabAtkins> Florian: Unless you can turn them into a vector.
<fantasai> fantasai: What if you don't specify a psotioin in the circle?
<fantasai> TabAtkins: Falls back to center
<fantasai> fantasai: Why not use the offset-position?
<fantasai> TabAtkins: ...
<TabAtkins> shane: [revisits Alan's suggestion again]
<TabAtkins> [mumbly discussion of whether the box keywords are useful here]
<fantasai> fantasai: There's no use case afaict, adding it for completeness is excess implementation and testing work.
<fantasai> TabAtkins: But consistency!
<fantasai> back to original topic
<fantasai> shane: Suggestion to have offset-position overrides position in the shape
<fantasai> Rossen: Why use a separate position property?
<fantasai> fantasai: Because it's there
<TabAtkins> TabAtkins: What makes it special here, vs any other place that uses the shape functions?
<fantasai> TabAtkins: If we want to make path() easier to use, should do that generally
<fantasai> TabAtkins: It would be great to have coords in path via css box coordinates generally
<fantasai> shane: feels wrong, not sure how to explain why I think this...
<fantasai> TabAtkins: If I use offset-position to set the start coord, why not use it to set other coords?
<fantasai> shane: I think in general for the use cases here, the path doesn't need to be shaped wrt the box, but often you want the start position to be wrt box
<fantasai> shane: Usually you want the path to be absolutely sized
<fantasai> TabAtkins: Sure, they're all useful
<fantasai> TabAtkins: box coords are a superset of abs coords
<ericwilligers> In Blink's shipped implementation, if people use position absolute and set left/top, then path('m 0 0 ... ') starts from left/top.
<fantasai> TabAtkins: I think it's just weird that in this one instance of the path function, doing something special is weird
<fantasai> TabAtkins: Create a CSS-friendly version of path syntax, that takes <position> with units and such
<fantasai> shane: Paths are hard to read and write
<fantasai> shane: You usually tkae it out of an authoring tool
<fantasai> shane: Paste it in... but then want to move the path around
<fantasai> TabAtkins: You alter the first to digits of the path...
<fantasai> shane: But if you're building a site where you're taking data from somewhere else, don't want a manual fixup
<fantasai> fantasai: I think shane's got a good point
<fantasai> TabAtkins: But if you want to use path elsewhere in CSS, then this is a problem
<fantasai> shane: What you're suggesting doesn't fix it for path(), but it's also useful and we should do both.
<fantasai> TabAtkins: Could say that path() takes an "at <position>" after the path, just like other shapes do
<fantasai> TabAtkins: Should go back to offset position only offsetting ray
<fantasai> shane: then position should go into the ray function
<fantasai> TabAtkins: just what I was about to say
<fantasai> fantasai: That's not the only thing offset-position does
<fantasai> T_T
<TabAtkins> fantasai: So offset-position is not only for setting the position of the ray(), it's for positioning a box position-like (which you can't do with abspos).
<ericwilligers> So is the view that offset-position is to only be relevant for ray() and none, and not for path() and basic-shape?
<fantasai> TabAtkins: The purpose of offset-position is to give you a translte function that acts like a background position, so that 0% and 100% map to aligning to opposite edges of the container
<astearns> ericwilligers: we're not happy with that
<fantasai> TabAtkins: That appears to be only necessary use of it here; shapes can just tkae an explicit position
<fantasai> TabAtkins: So maybe have a different feature for this
<astearns> RESOLVED: Undo previous resolution, we're still thinking about this
<ericwilligers> See Figure 11 in https://drafts.fxtf.org/motion-1/#offset-anchor-property    where offset-position and offset-anchor are useful with offset-path none.
<TabAtkins> (In other words, we could just move *all* the positioning functionality into the offset-path functions - path("..." at <pos>), ray(... at <pos>). Then there's nothing left for offset-position to do *in this module*, so we can address the fucntionality it still has elsewhere.
```
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/78#issuecomment-296078871 using your GitHub account

Received on Friday, 21 April 2017 05:46:52 UTC