Re: [fxtf-drafts] [motion-1] The definition of "containing box" for ray() function (#369)

The CSS Working Group just discussed `Definition of containing-box for ray()`, and agreed to the following:

* `RESOLVED: All of the offset-path values allow a coordinate box, treated the same as today's basic shape`
* `RESOLVED: move shane to former editors, add TabAtkins as a current editor`

<details><summary>The full IRC log of that discussion</summary>
&lt;myles> Topic: Definition of containing-box for ray()<br>
&lt;astearns> github: https://github.com/w3c/fxtf-drafts/issues/369<br>
&lt;myles> TabAtkins: There's not actually a definition of what containing box to use for ray(). It just says "the containing box" and that's not a term. It doesn't mean any thing. So what's the box? So we know how long the ray is. Where the 100% point is. There's a few possibilities<br>
&lt;myles> TabAtkins: We could just choose one. Maybe the containing block of the abspos. Or we can alter the grammar of the property a bit to have its containing box specified like how shape() does<br>
&lt;myles> TabAtkins: If we did so, we would be referring to the box of the parent element, not the box of the element being motion-pathed<br>
&lt;myles> chris: i prefer the second one<br>
&lt;myles> TabAtkins: me too<br>
&lt;myles> AmeliaBR: Would this also affect other ways of defining the path? So the path shape would also be repositioned to be relative to the containing block instead of relative to the initial position of the element that you're actually moving?<br>
&lt;myles> TabAtkins: Yes. That's what ewilligers is suggesting. URLs, rays, and paths also gain the ability to have an optional box<br>
&lt;myles> AmeliaBR: Is this a breaking change?<br>
&lt;myles> TabAtkins: Shapes already have this, that's part of the grammar. For paths, we can choose the default appropriately so paths don't change behavior. Whatever value that is, ray() should work the same way. IDR which value that is.<br>
&lt;myles> AmeliaBR: How does that apply to SVG if we're going up to the parent element<br>
&lt;myles> AmeliaBR: Are we going to the literal parent element like &lt;g>? Or relative to the view box?<br>
&lt;myles> heycam: Does this come back to the previous discussion about the box keyword that we moved into a different spec?<br>
&lt;myles> TabAtkins: We've already altered this spec for using the box keyword<br>
&lt;myles> heycam: So that should define how this works for SVG<br>
&lt;myles> AmeliaBR: It might not be the most intuitive if the parent is &lt;g> then the fill-box of that group might be a bit weird. But if we define it early before there's too much content using these properties ...<br>
&lt;myles> heycam: Was ray() added for rounded display?<br>
&lt;myles> TabAtkins: yes<br>
&lt;myles> heycam: If we have control over what box, then that satisfies that use case?<br>
&lt;myles> TabAtkins: I believe so.<br>
&lt;myles> astearns: Do we have a way forward here?<br>
&lt;myles> heycam: It feels slightly overkill having these keywords everywhere, but it's okay.<br>
&lt;myles> TabAtkins: My own objection to that is that they're all the same, shapes and paths and rays are all the same. I would like CSS to do it consistently right from the start<br>
&lt;myles> heycam: If you can specify the box in some, then it should be the default...<br>
&lt;fantasai> +1<br>
&lt;myles> TabAtkins: Yeah.<br>
&lt;heycam> s/the default/all/<br>
&lt;myles> astearns: Proposed resolution: All of the offset-path values allow a coordinate box, treated the same as today's basic shape (which I know is under-defined)<br>
&lt;myles> astearns: It is well-defined, it's just in a weird part of the spec, i will fix)<br>
&lt;myles> RESOLVED: All of the offset-path values allow a coordinate box, treated the same as today's basic shape<br>
&lt;myles> TabAtkins: shane is no longer part of CSSWG, can I replace him as an editor?<br>
&lt;myles> astearns: Will you actually be able to spend time on it?<br>
&lt;myles> TabAtkins: I'd like to fix it up. I can spend more than 0 time.<br>
&lt;myles> astearns: okay<br>
&lt;myles> RESOLVED: move shane to former editors, add TabAtkins as a current editor<br>
&lt;fantasai> ScribeNick: fantasai<br>
</details>


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

Received on Thursday, 23 January 2020 17:34:44 UTC