[motion-1] The definition of "containing box" for ray() function

[BorisChiou]

The definition of <size> in ray() is:

Decides the path length used when offset-distance is expressed as a percentage, using the distance to the containing box.

I guess this is pretty similar to containing block, right? So should we choose a different edge based on position property? Or just always use border edge or padding edge? It seems always using padding edge may make sense becuase it looks like contain flag doesn't expect the element overlaps the borders, but I'm not sure.

If the element is an SVG element (e.g. <rect>), how do we define this containing box on SVG layout? Perhaps we need a better definition for this.

[ewilligers]

Note that the path can also be defined using <basic-shape> || <geometry-box>. <geometry-box> is meaningless for a containing block: the containing block is a rectangle, not a box.

We could say that paths refer to the containing block, or the SVG root element for SVG layout, and remove <geometry-box> from the syntax.

Alternately, we could say that ray paths refer to the reference box of the parent element, and <geometry-box> similarly refers to a box of the parent element.

[BorisChiou]

I see. Thanks for these suggestions. My preference is the 2nd option:

Alternately, we could say that ray paths refer to the reference box of the parent element, and <geometry-box> similarly refers to a box of the parent element.

IMO, It seems this is easier to understand because containing block is sometimes too complicated for users. Besides, using the reference box (e.g. from transform-box property) of the parent element should also be easy for developers for both CSS and SVG layout.

@heycam and I had a quick disscussion about this issue. @heycam, do you have any prefernece or feedback for this? Thanks.

[heycam]

I'm unsure that using the reference box (as specified by the transform-box property) is the right thing to do, since -- assuming there is a use case for selecting different reference boxes for ray()s -- you won't necessarily want to use the same box for your transform as for your offset-path.

So what I want to know is what kinds of effects do we expect authors to want to create using ray(). I'm actually a little surprised that you can't specify a <length> value for the size. (Although if we had the bearing commands in SVG Paths we could achieve the same effect with path()...)

[ewilligers]

Perhaps we should change the grammar from

none | ray() | path() | <url> | [ <basic-shape> || <geometry-box> ]

to

none | [ <url> | ray() | path() | <basic-shape> ] || <geometry-box>

and change

The <geometry-box> specified in combination with a <basic-shape> provides the reference box for the <basic-shape>. If no reference box is specified, the border-box will be used as reference box.

to

The <geometry-box> provides the reference box for the path. If no reference box is specified, the border-box will be used as reference box.

The early spec (before ray()) had something like that.

We still need to explicitly say which element is referenced by the geometry-box.

[heycam]

I think the choice of reference box won't affect path(), since you can't use percentages in the path data. For url() I guess it does matter, since you might reference say a shape with percentage values for its geometry, like<circle cx="50%" cy="50%" r="100"/>.

I'm still not super sure what the use cases are for selecting which reference box to use. But if we do have a box in the property value, it makes sense to have it for all values that can be affected by it.

As for which element it refers to, does it always make sense to use the parent element? What about in the (presumably not uncommon case) of the element being absolutely positioned?

[tabatkins]

Agreed in general that we should go ahead and apply the reference-box stuff to all the values that it could use. I also think it should indeed refer to the parent element.

[css-meeting-bot]

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

The full IRC log of that discussion

<myles> Topic: Definition of containing-box for ray()
<astearns> github: https://github.com//issues/369
<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
<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
<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
<myles> chris: i prefer the second one
<myles> TabAtkins: me too
<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?
<myles> TabAtkins: Yes. That's what ewilligers is suggesting. URLs, rays, and paths also gain the ability to have an optional box
<myles> AmeliaBR: Is this a breaking change?
<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.
<myles> AmeliaBR: How does that apply to SVG if we're going up to the parent element
<myles> AmeliaBR: Are we going to the literal parent element like <g>? Or relative to the view box?
<myles> heycam: Does this come back to the previous discussion about the box keyword that we moved into a different spec?
<myles> TabAtkins: We've already altered this spec for using the box keyword
<myles> heycam: So that should define how this works for SVG
<myles> AmeliaBR: It might not be the most intuitive if the parent is <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 ...
<myles> heycam: Was ray() added for rounded display?
<myles> TabAtkins: yes
<myles> heycam: If we have control over what box, then that satisfies that use case?
<myles> TabAtkins: I believe so.
<myles> astearns: Do we have a way forward here?
<myles> heycam: It feels slightly overkill having these keywords everywhere, but it's okay.
<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
<myles> heycam: If you can specify the box in some, then it should be the default...
<fantasai> +1
<myles> TabAtkins: Yeah.
<heycam> s/the default/all/
<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)
<myles> astearns: It is well-defined, it's just in a weird part of the spec, i will fix)
<myles> RESOLVED: All of the offset-path values allow a coordinate box, treated the same as today's basic shape
<myles> TabAtkins: shane is no longer part of CSSWG, can I replace him as an editor?
<myles> astearns: Will you actually be able to spend time on it?
<myles> TabAtkins: I'd like to fix it up. I can spend more than 0 time.
<myles> astearns: okay
<myles> RESOLVED: move shane to former editors, add TabAtkins as a current editor
<fantasai> ScribeNick: fantasai

[fantasai]

Just want to note, we have to be sure not to break the original use case which was for polar positioning for abspos. There were long discussions about the meaning of 100% in some of the F2F minutes and www-style.