- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Aug 2017 07:57:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Name for frames() function.`, and agreed to the following resolutions:
* `RESOLVED: Renames frames to steps, argument name TBD.`
<details><summary>The full IRC log of that discussion</summary>
<iank_> Topic: Name for frames() function.<br>
<iank_> Github: https://github.com/w3c/csswg-drafts/issues/1301<br>
<glazou> https://github.com/w3c/csswg-drafts/issues/1301<br>
<iank_> birtles: So we specified a frames() timing function, makes sense for a usecase, animation that has discrete frames, and the start and end of the animation doesn't match, and the animatin repeats.<br>
<iank_> birtles: And for that use-case, frames() is a very good way of describing the timing, very obvious name, the counting , the number that you put in that function is the number of frames, unlike steps() where you count the number of jumps.<br>
<iank_> birtles: My concerns with frames, is<br>
<iank_> birtles: 1) very good in that context, not suitable in other contexts, e.g. not a good name for gradients.<br>
<iank_> birtles: 2) Having a different function name for something very similar can be confusing, e.g. frames() to a css transition, has almost idential result to steps() timing function<br>
<iank_> birtles: likewise there has been a proposal for a 4th type of timing function where ... jumps happen at both ends of the interval.<br>
<iank_> birtles: if we introduce that (seems likely) we'd do it as an extension to steps.<br>
<fantasai> Illustration of the 4 options: https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310571203<br>
<iank_> birtles: means we'd have 4 timing functions, 3 named steps, one frames(), seems inconsistent<br>
<iank_> birtles: Also frames() has bad discoverability, within devtools, (autocomplete)<br>
<iank_> birtles: if you have a steps timing function, and doesn't quite look right, you'd just try and change that TF, not easy to "find" the frames TF instead.<br>
<iank_> birtles: concered that they wouldn't discover frames, and then would have to use a different way of counting.<br>
<glazou> s/concered/concerned<br>
<iank_> birtles: My prefered way of doing this would be to extend steps.<br>
<iank_> birtles: Even though we know that way of counting isn't ideal<br>
<fantasai> birtles: for the particular use case of a repeating frame-based animation that doesn't go back to where it starts<br>
<iank_> Rossen: So looking at the community twitter, that rachael did, frames() was solidly a preference from designers.<br>
<iank_> fantasai: They are only concerned with what they do, not trying to make consistent with the rest of CSS<br>
<iank_> fantasai: I agree with birtles points, agree that its easier to learn the set if its an extension to steps() instead of a new function, (frames())<br>
<iank_> birtles: If you are animating a spinner, and its rotating, you'd want a steps TF, if you use frames() it'll double the length of the other points.<br>
<fantasai> Was pointing out that polling people for their preferred syntax for that particular use case isn't going to take into consideration the interaction with the rest of the system, which is our job here in the WG.<br>
<fantasai> For people who want a function to do the one thing that they're trying to do, yeah, frames() might be nicer. But in general people have to learn more than just the one case<br>
<fantasai> and then for almost the same but not quite cases, they have to switch to steps()<br>
<fantasai> which doesn't seem very helpful<br>
<iank_> Rossen: So the current name in the spec is steps()?<br>
<iank_> birtles: No frames()<br>
<iank_> Rossen: Any other opinions? otherwise can resolve and move on....<br>
<iank_> Rossen: No?<br>
<iank_> Rossen: Any objections to renaming frames() to steps()?<br>
<iank_> birtles: We'd still need to work out the name of the argument.<br>
<iank_> birtles: Some of the proposals have been distribute.<br>
<iank_> astearns: We could resolve on using steps, instead of frames, and work out param names later.<br>
<iank_> fantasai: <showing examples on github issue><br>
<astearns> s/later/separately/<br>
<iank_> fantasai: <https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310571203><br>
<iank_> Rossen: Are there any objections to renaming frames() to steps()?<br>
<iank_> fantasai: In favour.<br>
<astearns> +1<br>
<iank_> RESOLVED: Renames frames to steps, argument name TBD.<br>
<fantasai> fantasai^: These are the four options under consideration for this set of timing functions. The first two exist already, the second two are proposed.<br>
<iank_> fantasai: The next thing is that we have the 'start', 'end'... we need two more keywords.<br>
<iank_> fantasai: We need to be clear of the distiction between the two new keywords.<br>
<astearns> inside/outside, inclusive/exclusive also mentioned<br>
<iank_> fantasai: Proposal to use the space keywords, which we use for distributing space, e.g. 'space-between', 'space-evenly'<br>
<iank_> fantasai: Could also use 'space-around'<br>
<iank_> fremy: space-around only has half of the space....<br>
<iank_> fantasai: we could space-* keywords, could use another word other than space?<br>
<iank_> birtles: could drop the space- prefix, e.g. between, evenly, etc.<br>
<iank_> dino: I'd prefer that anyway, we are going to have to look this up anyway<br>
<iank_> fantasai: At least you've learn't alignment, then we can transfer the knowledge to different area.<br>
<tantek> I've read the entire github issue and I'm still not sure about which of the options are better.<br>
<iank_> astearns: There is the option using the start, end syntax, to start, end, both, none.<br>
<iank_> dbaron: start, end made the most sense for 1 step.<br>
<iank_> <general talking about arg names><br>
<Bert> ('center' seems nice and short, transition in the middle rather than at the start or end...)<br>
<iank_> Rossen: We can always continue this in the discussion.<br>
<iank_> Rossen: We are already going against tabs strong pushback, it also doesn't sound like we have clear winners on arg names.<br>
<iank_> birtles: Could we at least list the current candidates?<br>
<iank_> birtles: 1) distribute and justify naming.<br>
<iank_> Florian: 2) distribute and stretch<br>
<iank_> birtles: 3) space-evenly, space-between<br>
<iank_> dbaron: 4) center, stretch<br>
<Rossen> steps( <integer>, [ trim-start | trim-end | trim-both | no-trim ]<br>
<iank_> birtles: 5) both, neither<br>
<iank_> Rossen: 5) trim-start, trim-end, trim-both, no-trim<br>
<fantasai> fantasai: Problem with distribute and justify is that they are two words that mean almost the same, and aren't used to make a distinction anywhere else in CSS.<br>
<iank_> Rossen: 6) trim-start, trim-end, trim-both, no-trim*<br>
<fantasai> fantasai: (We also have text-justify: distribute as a legacy thing, which is really not helping here)<br>
<iank_> birtles: Don't like the trim names b/c when you use them you typically don't drop the endpoints, you see the endpoints.<br>
<iank_> Bert: 7) short, long.<br>
<iank_> astearns: 8) include, exclude<br>
<fantasai> fantasai: Problem with using center is that both space-around and space-evenly are centering methods, but they are different. It's not clear which one this is.<br>
<fantasai> I really don't like 1/2/4/7.<br>
<iank_> Rossen: If folks are passionate about this, they can take this offline, and come back to the group, I really want to include TabAtkins , unfortunate to re-resolve this later<br>
<fremy> My pref would be 3 or 4<br>
<iank_> Rossen: Lets close this, if we have a clear set of keywords by the end of the F2F, we can resolve on a later day.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-319597773 using your GitHub account
Received on Wednesday, 2 August 2017 07:57:42 UTC