-
Notifications
You must be signed in to change notification settings - Fork 669
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
[css-shapes-2] Minor comments on shape() #5841
Comments
cc @noamr @tabatkins |
I meant "can produce either of two segment types". |
I agree that consistency is of value, but I also dislike how SVG path animations are so restrictive, and I wish there was something we could do about it. Maybe we can word it in a way that releases this from this restriction? :( My original thought was, instead, to treat all path segments (except move to/by) as cubic bezier curves - quadratic curves (and arcs?) would have the 2 control points at the same spot, and lines would have the two control points within the line, evenly distributed. This would allow nice smooth animations between lines/quadratic/cubic cutves/arcs without the author having to manually declare all of them as cubic bezier curves. Maybe this can also be backported to SVG, with an opt-in attribute to maintain backwards compatibility.
Right.
I specified it like this because the word by/to is important in order to understand the meaning of the rest of the coordinates. But I agree that it might make more sense to have the end point at the end of the phrase. |
Okay, I've done an editorial pass over the spec, and specified the animation behavior. As a first draft, I just made sure it works the same as path(), as far as I can tell per https://www.w3.org/TR/SVG2/paths.html#TheDProperty. It's not very clear what the actual rules are - should the three line commands interpolate? The two quadratics and the two cubics?
I actually prefer the current ordering, where all the commands immediately list their ending point and then have their extra info if needed; I think it reads well with the by/to keywords. SVG's ordering made more sense with its implicit command chaining, imo. |
Per animation, if we can change up the path interpolation rules, I'm all for letting lines/quadratics/cubics all interpolate together (as cubics), tho we'd have to choose where the control points are for the lines - I think they can go literally anywhere on the line without affecting anything? If so, I guess they should either both be in the middle, or maybe the first at the starting point and the second at the ending point? But I'd really like to maintain the ability for path() and shape() to interpolate together, so this would change the path() interpolation rules too. |
Well, I guess we could let path() keep the SVG interpolation rules when interpolating with another path(), and use the looser rules only when interpolating shape() with itself or path(). |
I think both in the middle would interpolate in a more natural way with quadratic curves, staying quadratic throughout the animation, and would be easy to understand. |
I think this would work |
Apologies, I missed the latter part of the list. I'm OK with these suggestions:
It's more verbose but would make it closer to SVG. |
|
Well the remaining complaint is about spelling out cubic vs quadratic, but I think that "smooth quadratic curve to" can maybe start going over the verbosity borderline? |
I think Dean's complaint is pretty much resolved by the idea that only string-to-string animation uses the strict already-defined SVG animation pairing, while animating to/from a shape() function can use a looser variant that allows animating the curve types together. We should maintain the current nice usability from the degree choice being based on the arguments. |
…rcs/curves Closes w3c#5841
…rcs/curves Closes w3c#5841
@astearns @atanassov Can we close this at editors discretion and merge @noamr's PR or should we put this at the discussion for the CSSWG? WebKit is currently implementing shape: https://bugs.webkit.org/show_bug.cgi?id=238371 |
Another comment: the Similarly, you can't use |
It's a good idea, Perhaps we can open an issue it can be added on top of the current spec without a backwards-compat problem? Otherwise we'll just pile more things on this list of small issues |
Proposed resolution: merge PR #9797:
|
For animation, let's please not forget #10195 which is kind of a no-brainer.
Or we can just re-use |
The CSS Working Group just discussed
The full IRC log of that discussion<TabAtkins> noamr: A few years ago there were some comments about shape() syntax, wanted to reoslve them<TabAtkins> noamr: One is we use keyword `via` to describe intermediate points in beziers <TabAtkins> noamr: Proposal is `using` instead, which amkes sense - you dont' go via the points, you just use them to create the curve <TabAtkins> noamr: Other was to allow reordering the arguments, since they're distinguished by keyword <smfr> q+ <TabAtkins> noamr: Third is to also allow <position> rather than just <coord-pair> <TabAtkins> noamr: Currently we use `by` and `to` - `by` is relative segment, `to` is absolute. So idea is if you use `to` you can use <position>, like `to top left` <TabAtkins> noamr: These all make sense to me <TabAtkins> noamr: There's also an animation question, I think we can defer that <astearns> ack smfr <TabAtkins> smfr: I agree with all of these <TabAtkins> smfr: ONe thing, if you say `to` or `by` the end and control points are either all relative or all absolute <TabAtkins> smfr: It makes sense to me to be able to specify control points relative to the end point <TabAtkins> smfr: That would complicate the syntax, and needs something for quadratics <TabAtkins> smfr: But in general it makes sense to allow moving beziers and leave control points alone becuase they're relative to the endpoints <TabAtkins> noamr: I think we can address that in a separate issue <TabAtkins> smfr: Right, just want to make sure we're not stopping my thing from working in the future <TabAtkins> noamr: Yeah, it wont' <TabAtkins> astearns: I suggest we move the <position> issue to the new issue about smfr's issue <TabAtkins> astearns: And for now just resolve on what's in the PR - reordering grammar, and using instead of via <TabAtkins> fantasai: I think we try to use prepositions, and this is a verb, so I'm not super into `using` <fantasai> I don't particularly love 'using', we usually use prepositions not verbs <TabAtkins> smfr: Nobody ships this yet, we can change things. It might change with the relative-control-points thing. <TabAtkins> fantasai: I'm fine with the PR for now. <TabAtkins> RESOLVED: Accept Noam's PR (switch to `using`, allow reordering grammar) |
Following up on |
Filed #10649 |
I was a few seconds late providing review feedback on #5711 . It's probably easier to read my comments inline there, but I'll repeat them here.
shape
syntax is a mapping to SVG path primitives. It should probably call out the fact that thecurve
operator actually produces two segment types, so it may not be possible to smoothly animate between twocurve
s.curve
andsmooth
might actually be the same segment type as far as animation is concerned! Confusing!via
is a good term for bezier control points. The curve does not (typically) go through those points, which is what the definition of via would suggest. Maybeusing
is a better term?The text was updated successfully, but these errors were encountered: