W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > December 2016

Re: [fxtf-drafts] [motion] Inconsistency in offset-path contain

From: Jihye Hong via GitHub <sysbot+gh@w3.org>
Date: Wed, 21 Dec 2016 06:23:18 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-268446332-1482301396-sysbot+gh@w3.org>
> When we change this to
offset-path: angle(60deg contain);
then my question can be reworded: Where is the element now placed?

If we have an example with the following:

```
container size: 200px 200px;
element size: 0px 0px;
offset-position: center; /* 100px 100px */
offset-path: angle(60deg contain);
offset-distance: 150%; /* 150 px */
```

Then the element would be placed at **187px 50px**. (Assuming 
50*sqrt(3) is 17)
![image](https://cloud.githubusercontent.com/assets/6636090/21377703/e100d510-c783-11e6-818d-6203a4aa5a62.png)


When calculating the position with `contain` and considering the size 
of the element, there could be 2 ways:
- Case A: 
Until one of the edges of the element meets the end point of the path,
 move the element towards offset-position with letting the anchor 
always be on the path.
- Case B: 
Until the entire element stays inside the path, move the element 
towards offset-position with letting the anchor always be on the path.

For example, if the size of the element in the example above changes 
0px 0px to 40px 40px (20% 20%),
the element would: 
  (let 20 / SQRT(3) = 12, 20 * SQRT(2) = 28, 14 * SQRT(3) = 24)

- Case A: move left 20px and bottom 12px to **167px 62px**.
![image](https://cloud.githubusercontent.com/assets/6636090/21377909/6dc4269a-c785-11e6-94bd-7b6c268ea674.png)

- Case B: move left 24px and bottom 14px to **163px 64px**.
![image](https://cloud.githubusercontent.com/assets/6636090/21377917/76aa9d16-c785-11e6-9a89-3067f38c66e6.png)

> If the "entire element stays inside the path", and the anchor must 
remain on the path, the element moves to 163px 64px. The top right 
corner of the element becomes 183px 44px, which is 100px from 
offset-position.

You calculated the position by Case B, and I also agree with that - 
Case B is more suitable than Case A, because the result of Case B is 
the best possible outcome when the clipping problem is solved.

I think I need to update the spec with:
- Describing that `contain `adjusts the total length of the path not 
the offset-distance of the element
- Algorithm (Case B) for calculating the position when using `contain`

> such as when the element is larger than the containing element.

In this case, no matter how the element moves, it can't avoid being 
clipped.
So the element could be positioned along the path with having the 
smallest clipped area by moving the shortest distance.

For example, the element like below would be placed at **120px 89px**.
```
container size: 200px 200px;
element size: 240px 240px;
offset-position: center; /* 100px 100px */
offset-path: angle(60deg contain);
offset-distance: 150%; /* 150 px */
```

(let 110/SQRT(3) = 64)

![image](https://cloud.githubusercontent.com/assets/6636090/21379265/fd2f337e-c78f-11e6-81c2-ecefd3159886.png)


-- 
GitHub Notification of comment by jihyerish
Please view or discuss this issue at 
https://github.com/w3c/fxtf-drafts/issues/22#issuecomment-268446332 
using your GitHub account
Received on Wednesday, 21 December 2016 06:23:24 UTC

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