Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[motion] Should omitted <size> just extend to the containing block edge? #73

Closed
fantasai opened this issue Nov 5, 2016 · 4 comments
Closed
Labels

Comments

@fantasai
Copy link
Contributor

@fantasai fantasai commented Nov 5, 2016

Decides the position of the end point of the path. ... If omitted it defaults to closest-side.

I think it's quite reasonable that someone might want to position along a polar ray between the initial point and the edge of the containing block at a non-orthogonal angle. Simplest way to allow this would be that if an omitted size argument were left out, the ray extends to the edge of the containing block at the specified angle. Constraining 100% to match regardless of <angle> would require a keyword, but I don't think this is unreasonable. In particular it'd be less surprising in cases where the initial position chosen as one of the corners (or along an edge), which is a fairly common and reasonable case, but would result in a (surprising) path distance of zero.

@jihyerish

This comment has been minimized.

Copy link
Contributor

@jihyerish jihyerish commented Dec 21, 2016

someone might want to position along a polar ray between the initial point and the edge of the containing block at a non-orthogonal angle.

Previously, Motion Path Spec described that the end point of the path is the point where the ray with <angle> meets the edge of the containing block.
But this caused the inconsistency in offset-path when the <angle> is different but the percentage value of offset-distance is the same.
So I thought the default value as closet-side can solve the inconsistency, it makes the calculated position of the element constant with the changes in <angle> of the path.

Specifying furthest-corner for <size> can position the element along a polar ray between the initial point and the edge of the containing block at a non-orthogonal angle.

It's hard for me to find the better option than closet-side for the default of <size>.

@jihyerish

This comment has been minimized.

Copy link
Contributor

@jihyerish jihyerish commented Apr 21, 2017

In particular it'd be less surprising in cases where the initial position chosen as one of the corners (or along an edge), which is a fairly common and reasonable case, but would result in a (surprising) path distance of zero.

On that case, can we choose the closet side among the edges which don’t adjacent to the element?

@css-meeting-bot

This comment has been minimized.

Copy link
Member

@css-meeting-bot css-meeting-bot commented Apr 21, 2017

The CSS Working Group just discussed https://github.com/w3c/fxtf-drafts/issues/73.

The full IRC log of that discussion
<shane> Topic: https://github.com/w3c/fxtf-drafts/issues/73
<shane> Github Topic: https://github.com/w3c/fxtf-drafts/issues/73
<fantasai> ericwilligers, I think the proposal was to move <position> inside the ray() fuction and delete offset-position or add the none-based positioning feature to something else?
<TabAtkins> jihye: offset-based positioning properties describe tehe path the element is on, various ways
<TabAtkins> jihye: ray() defines a line segment starting from the position, going in the defined direction
<TabAtkins> jihye: It has 3 params - angle, size, contain.
<TabAtkins> jihye: size is where the path ends.
<TabAtkins> jihye: When talking about size, have to know the path length
<TabAtkins> jihye: To resolve %s
<TabAtkins> jihye: So most important factor is <angle> in ray(); I want consistency with %s here, so if all you do is animate the angle, the % resolves to the same length the whole time.
<TabAtkins> fantasai: So question is what the behavior is when you *omit* the size keyword.
<TabAtkins> fantasai: Earlier you just draw the ray until you hit an edge, it's that long.
<TabAtkins> fantasai: Current spec it defaults to closest-side.
<TabAtkins> fantasai: So my suggestion is adding an option (or defaulting it) to get back the "cast the ray to the edge of the box" behavior.
<TabAtkins> [explicitly unminuted discussion about whether it makes sense to be the default]
<TabAtkins> fantasai: It's not clear, fi the "measurement angle" is different from the angle you're actually using, why 100% stops at the given point.
<TabAtkins> shane: I think that's not usually the case - mostly it'll be used to position things around a circle around the box.
<ericwilligers> Can we make the <size> non-optional?
<TabAtkins> ChrisL: I agree with shane - i think it's usually the case that you're using this feature for polar-positioning multiple things.
@css-meeting-bot

This comment has been minimized.

Copy link
Member

@css-meeting-bot css-meeting-bot commented Apr 21, 2017

The CSS Working Group just discussed ericwilligers we'd still need to decide the default, and agreed to the following resolutions:

  • RESOLVED: <size> argument of ray() is required.
  • RESOLVED: Name the "cast to the side you're pointing at" value "sides"
The full IRC log of that discussion
<astearns> topic: ericwilligers we'd still need to decide the default
<TabAtkins> fantasai: That's *a* use-case yes, maybe the most common one.
<shane> Github Topic: https://github.com/w3c/fxtf-drafts/issues/73
<TabAtkins> ChrisL: Yeah, and why not make the most common use-case be the easiest thing to do?
<TabAtkins> Florian: [gives example of putting the start-point in the corner instead, where closest-side will send all %s to 0.]
<TabAtkins> shane: I think the default of a polar-positioning feature should be a circle.
<TabAtkins> astearns: What about making size always required?
<TabAtkins> fantasai: [doesn't like requiring it]
<ericwilligers> No default would be needed for function  ray(<angle> && <size> && contain?)
<TabAtkins> TabAtkins: [heh, fantasai wants a default, but prefers a different default than anyone else]
<TabAtkins> shane: Straw poll?
<TabAtkins> fantasai: I'm against making it required, but won't oppose it. I will oppose defaulting it to closest-side.
<TabAtkins> RESOLVED: <size> argument of ray() is required.
<TabAtkins> [discussion of naming the keyword]
<Rossen> sidez
<TabAtkins> RESOLVED: Name the "cast to the side you're pointing at" value "sides"
ewilligers pushed a commit to ewilligers/fxtf-drafts that referenced this issue May 13, 2017
The size argument of ray() is no longer optional.

The new keyword 'sides' indicates an angle-specific path length that
extends to the ray's intersection with the containing box.

Discussed in the CSS Working Group:
w3c#73 (comment)

Resolves w3c#73
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.