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.

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.

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()...)

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.

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?

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.

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

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.

Okay, I've made some Editorial Decisions here.

• The element being referenced by coord-box is the element establishing the containing block for the transformed element. We can't rely on parent element, as if the parent is, say, an inline, it doesn't have a reasonable box to look at. And when the transformed element is abspos, this'll be the abspos containing block, which is definitely what we want for the common ray() case.
• When used in an SVG context, I just treat all instances of coord-box as being view-box. SVG doesn't have a useful notion of "parent" or "containing block" here; "nearest viewport" is the closest thing that makes sense, and the view-box keyword does the job there without requiring me to invent anything new.

Is it now possible to implement such an animation based on the new offset-path syntax? demo

It's as possible now as it always was.

@tabatkins Can this be done with the ray() function when the parent element has an indeterminate width and height? If I understand correctly, something like this?

@keyframes test {
  0% {
    offset-path: ray(0deg) border-box;
  }
  
  100% {
    offset-path: ray(360deg) border-box;
  }
}

You'll want ray(0deg sides), but yes.

Tho hm, I don't think the animation of ray() is properly defined anywhere. The behavior is pretty obvious - if the keywords match, then we animate the angle; otherwise we use discrete.

Yes, ray(0deg sides) will not take border-radius into account.

For the above example, the current use of offset-path: content-box would be more appropriate and only needs to address this issue #513.