Re: [fxtf-drafts] [motion-1] the description of contain flag in ray() function (#363)

The CSS Working Group just discussed `[motion-1] the description of contain flag in ray() function`, and agreed to the following:

* `RESOLVED: use half width/height for horiziontal/vertical rays, interpolate for other angles`
* `RESOLVED: for sides value, have snugness`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> https://drafts.fxtf.org/motion-1/#valdef-ray-contain<br>
&lt;fantasai> TabAtkins: when we first talked about motion path, I didn't realize how much needed fixing<br>
&lt;fantasai> TabAtkins: first thing was that contain flag was overcomplicated and didn't do what we wanted it to do<br>
&lt;fantasai> TabAtkins: I proposed some simplifications, supported by FF and Blink implementations<br>
&lt;fantasai> TabAtkins: Basically you take the larger of width or height, and subtract that from the ray<br>
&lt;fantasai> TabAtkins: in the common case of you start the ray from the center and get digits around a clock face, they will sit a consistent distance from the edge no matter what angle you're using<br>
&lt;fantasai> TabAtkins: in other cases where elements aren't round or ???<br>
&lt;fantasai> TabAtkins: you'll get similar behavior, it will be direction-agnostic, but not exactly the same as the old spec<br>
&lt;fantasai> TabAtkins: but should be close<br>
&lt;fantasai> florian: if old spec didn't do what it meant to do, not losing anything, but can we gain something and do what old spec meant to do?<br>
&lt;fantasai> TabAtkins: I don't know what it meant to do<br>
&lt;fantasai> TabAtkins: afaict, it was optiized for the sides value for ray, which made the ray ?? angle-dependent<br>
&lt;fantasai> TabAtkins: old spec if rectangular, you would get snug against the edge of the box<br>
&lt;fantasai> TabAtkins: for any other case, it was just wrong<br>
&lt;fantasai> TabAtkins: because it made sure that rectangle fit against the element<br>
&lt;fantasai> TabAtkins: square fits into circle more closely when axis-aligned and less so when  [missed]<br>
&lt;fantasai> TabAtkins: so I think it was one way to interpret the way the intent, but a bad way<br>
&lt;fantasai> fantasai: If you're working with rectangles (or ellipses) rather than circles and squares<br>
&lt;fantasai> fantasai: you won't get a snug fit because of the difference in width/height -- we're only using the smallest, so it fits in one axis and not in the other<br>
&lt;TabAtkins> s/smallest/largest/<br>
&lt;fantasai> fantasai: what if we used widht in horizontal axis and height in the other<br>
&lt;fantasai> fantasai: and then interpolated between the two at the angles in-between?<br>
&lt;fantasai> TabAtkins: That's identical if element is square, but not unreasonable if element is off-square<br>
&lt;fantasai> TabAtkins: it does mean we regain angle dependence, but not strictly a bad thing...<br>
&lt;fantasai> TabAtkins: I guess I'm ok with that. Do a sinusoidal interpolation between half width and half height<br>
&lt;fantasai> florian: that sounds like a good idea to me too<br>
&lt;fantasai> astearns: so proposal is to change spec to use half of width/height and iterpolate between the two?<br>
&lt;fantasai> TabAtkins: yes, then a wrinkle based on that<br>
&lt;fantasai> astearns: objections? concerns?<br>
&lt;fantasai> RESOLVED: use half width/height for horiziontal/vertical rays, interpolate for other angles<br>
&lt;fantasai> TabAtkins: old spec worked great for the "sides" value of ray, always fit against containing block edges<br>
&lt;fantasai> TabAtkins: worked badly for other things<br>
&lt;fantasai> TabAtkins: when I simplified, doesn't quite work as well for sides<br>
&lt;fantasai> TabAtkins: but thought it was acceptable loss<br>
&lt;fantasai> TabAtkins: but if we're regaining angle dependence, I think it's OK to break simplicity a tiny bit more<br>
&lt;fantasai> TabAtkins: and say that for sides value, we do calculate the intersection bit<br>
&lt;fantasai> TabAtkins: much easier in this case because it's rectangle against rectangle<br>
&lt;fantasai> TabAtkins: old one wanted coord geomtery is harder<br>
&lt;fantasai> TabAtkins: question is how much pull in the box to make it actually fit<br>
&lt;fantasai> TabAtkins: that's relatively easy math, I can put in the spec<br>
&lt;TabAtkins> s/coord/chord/<br>
&lt;fantasai> astearns: sounds reasonable<br>
&lt;fantasai> astearns: proposed for sides value we will have snugness<br>
&lt;fantasai> astearns: objections?<br>
&lt;fantasai> RESOLVED: for sides value, have snugness<br>
&lt;fantasai> TabAtkins: that's it, just need a decision on the initial value of offset-position<br>
&lt;fantasai> florian: Last time we worked on this, was triggered by work on round display<br>
&lt;fantasai> florian: that faded, but Jihye is back maybe we can ask her to review?<br>
&lt;fantasai> TabAtkins: I did some issue archeology, so pretty sure I captured intent, but happy to ask her for review<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 13 March 2023 14:48:49 UTC