How to prefix keyframes

[jimisaacs]

I see a lot of issues about having support for @Keyframes, but I wanted to figure something out.

How in the world can I use LESS to simplify having to put multiple keyframe blocks for each browser "@-moz-keyframe", "@-webkit-keyframes", etc.? Is it possible, or even worth trying?

I've looked all over, and tried myself. I see some pretty complicated, and unusable solutions in my case. Basically I am wondering if we are required to copy and paste keyframes and prefix them, am I winning anything by using LESS for this type of CSS? The types of things I (and many other devs) build now days have many and many different kinds of animations per project.

I'm am at a loss here. Even if it is actually possible to use some sort of complicated mixin, still using a nested prefixed mixin inside a keyframe is kind of pointless, it would output something like:

@keyframes myAni {
    100% { 
        -webkit-transform: translate(100px, 0);
        -moz-transform: translate(100px, 0);
        transform: translate(100px, 0);
    }
}
@-webkit-keyframes myAni {
    100% { 
        -webkit-transform: translate(100px, 0);
        -moz-transform: translate(100px, 0);
        transform: translate(100px, 0);
    }
}
@-moz-keyframes myAni {
    100% { 
        -webkit-transform: translate(100px, 0);
        -moz-transform: translate(100px, 0);
        transform: translate(100px, 0);
    }
}

[lukeapage]

I can't think of a way :(

another reason to implement this #1199

[jonschlinkert]

👍

[jonschlinkert]

Rather than trying to create a dynamic syntax to solve this isolated problem, my suggestion is that Less.js automatically expand keyframes rules to include vendor-prefixed versions. So if a dev did this:

@keyframes slidein {
  0%, 50%, 100% {opacity: 0; }
  25%, 75% {opacity: 0; }
}

Less.js would automatically generate the vendor-prefixed versions in the CSS.

I am opposed to "auto-prefixing" for properties, but for keyframes it makes sense. This alone would cut down a ton of code in .less files, so it would be a big win for devs.

[chriseppstein]

This is the use case that caused Sass to introduce passing content to mixins. It enabled compass to support animations instead of putting that logic in sass.

[jonschlinkert]

@chriseppstein thanks. to clarify though, content is being passed specifically for the keyframe lists (e.g. 0%, 50%, 100% {opacity: 0; }), correct? Beyond the keyframe lists, SASS also has methods for dealing with the vendor prefixes and identifiers, and since all of the major challenges with keyframes have been addressed, it seems that passing in content is more advantageous within that construct. Or am I missing a crucial point here?

Whatever approach Less.js ends up taking to address keyframes it should result in a transformative net benefit to developers. IMHO, passing content into mixins is only a part of the equation, and unless we also address vendor-prefixed at rules, keyframe identifiers, and keyframe animations, then passing in content will only result in an incremental benefit.

To your point about adding logic, it seems like there is going to be some kind of trade-off here regardless of how we choose to solve the problem. Any advice on which problem is the most important to solve here?

[chriseppstein]

@jonschlinkert It's true. Passing content was useful because of the way the suite of features in Sass interact with each other. And beyond keyframes, we saw numerous ways that passing content blocks provided a general expressiveness to create abstractions that defined "containers" instead of the contents of those containers. As such, you can use mixins with content blocks to abstract selector hacks, media queries, css modules, etc.

Obviously Less will have to find it's own complementary concepts that mesh as seemlessly as possible with the existing feature set.

I'm not sure I understand your question about trade-offs. Our design goal for Sass is that it won't need a new release just because a browser adds a feature. We offload the knowledge of how what browsers capabilities are and how interop should work to frameworks built on Sass, because there is not "one true way" to address that problem and we want to allow room for frameworks to innovate in that space.

[matthew-dean]

The thing about passing content is that the use cases seem to be narrower. That is, rather than a generic catch-all construct that requires you to define mixins for each type of @ block and insert a @content block within that mixin, I'm wondering if there's a way for us to redefine properties and keywords so that they "auto-expand". But WITHOUT having to make Less manage those prefix extensions (especially since this has a high maintainability cost).

One of the disappointing things to me about LESS and SASS is that CSS needs to be rewritten in a different syntax construct for the same (type of) output. (That is, that background-size: value needs to be rewritten as .background-size(@value))

Like @jonschlinkert, I would like to write this:

@keyframes slidein {
  0%, 50%, 100% {opacity: 0; }
  25%, 75% {opacity: 0; }
}

...and have it just work (give me the prefixes I want). How do we achieve that? One option is that the code is auto-rewritten by the parser, but I think @chriseppstein's observation is correct: that this is a self-limiting approach.

However, I think there's another option that hasn't been explored very much, which I started to explore in #1342: that we allow the author to "redefine" keywords and properties, and assign them to mixins. Such that needing that output doesn't require rewriting your CSS3 code, and at such time when browsers had matured beyond needing prefixes, that you coud remove the mixin, and all of your code would remain valid. I think it's a powerful pattern for extending CSS authorship in a way that can be more intuitive than mixin calls.

So, for example, say I could write something like this code:

@define @keyframes() {
  @-webkit-keyframes @params @block;  //Just spitballing that what follows the keyword up to the first brace could be assigned to a var, and the braced value assigned to another var, but not sure it's needed
  @keyframes @params @block;
}

animation(@value) { 
  animation: @value;
  -webkit-animation: @value;
}

Then, I write absolutely straightforward CSS3. No special mixin syntax in sight:

@keyframes OPACITY_FADE {
  0%   { opacity: 0.25; }
  25% { opacity: 1; }
  100% { opacity: 0.25; }
}
.box {
  animation: OPACITY_FADE 1s infinite;  
}

// Outputs:

@-webkit-keyframes OPACITY_FADE {
  0%   { opacity: 0.25; }
  25% { opacity: 1; }
  100% { opacity: 0.25; }
}
@keyframes OPACITY_FADE {
  0%   { opacity: 0.25; }
  25% { opacity: 1; }
  100% { opacity: 0.25; }
}
.box {
  animation: OPACITY_FADE 1s infinite;  
  -webkit-animation: OPACITY_FADE 1s infinite;  
}

Like #1342, the values I use in my CSS are passed to my defined mixins. Technically, I could use this construct to create all new keywords, properties, and block containers, but I can also powerfully use this to gracefully support properties, the way we use unobtrusive JavaScript. It's unobtrusive LESS. And it requires no special maintenance of which properties need prefixes.

I think this could be a really powerful pattern, and people would get excited to a) use the CSS they already know, b) write CSS-like syntax to create complex output. I would liken it to the Web Components work that's happening in HTML5, where I can define complex markup, but then call it with a single simplified element the same way I write any other element.

I don't know about you @jonschlinkert, but I'm really excited about the idea of component-based architecture. ;-)

Anyway, that's my $0.02.

[jimisaacs]

@matthew-dean The part that I'm still confused about is how this would work for prefixed styles within the keyframe rules. Do you have an example for an animation using transform, -webkit-transform, etc. ?

[matthew-dean]

@jimisaacs Absolutely. It would look something like this:

transform(@value) {
    -webkit-transform: @value;
    -moz-transform: @value;
    -ms-transform: @value;
    -o-transform: @value;
    transform: @value;
}
.rotate {
  transform: rotate(45deg);
}

The "value" is assigned to a single-variable mixin. If an author is worried about conflicts, or unintended consequences of overriding properties, they could also do this:

-prefix-transform(@value) {
    -webkit-transform: @value;
    -moz-transform: @value;
    -ms-transform: @value;
    -o-transform: @value;
    transform: @value;
}
.rotate {
  -prefix-transform: rotate(45deg);
}

The syntax / usage for mixins as properties seems clearer than the @Keyframes example, so I think the @Keyframes syntax would need some refinement. You should direct other questions about mixin property syntax to Issue #1342. I referenced it here because it makes sense to apply a similar concept in redefining keywords so that they can "auto-expand", but at the total control of the LESS author.

[chriseppstein]

One of the disappointing things to me about SASS is that CSS needs to be rewritten in a different syntax construct for the same (type of) output.

This is a Sass feature. It makes it easier to understand what's happening. Transparent behaviors that override existing syntax, create debugging complexity and developer confusion. The problem here is that the syntax is so different from the property itself. So I want to bring something like this to sass:

.cover {
  +background-size: cover
}

Which would be syntactic sugar for @include background-size(cover).

Unfortunately + creates some syntactic ambiguities so we'll probably have to pick a different syntax.

[matthew-dean]

Sorry sorry, now I get your question. I missed the bit about transforms within keyframes syntax. Hmm... working through it, that may be a more complex issue, since we'd want to change at least variables on the content.

@define @keyframes() {
  @-webkit-keyframes @params {
    @prefix-webkit: true;
    @content;  // looks more unavoidable at this point
  }
  @keyframes @params {
    @prefix-webkit: false;
    @content;
  }
}

// ...etc with mixins that have guards to add prefixes based on the value of @prefix-webkit

[matthew-dean]

Transparent behaviors that override existing syntax, create debugging complexity and developer confusion.

Even for the developers that created the overrides? o_O

I don't see how it's any more confusing than running something like -prefix-free, except that you've DEFINED the prefixing behaviors, so you should have MORE awareness of what's happening in your code. Unless you downloaded a mixin library which did this for you, in which case it has the exact same result as running -prefix-free., only you can more easily modify the rules that modify those prefixes. So, I don't see how that argument makes sense. Nothing would "magically happen" without your knowledge or without you at least setting up a library, which should document exactly what will happen.

LESS already converts simple code declarations into more complex ones; this is just a method that allows you to use a syntax you are familiar with, as you pointed out.

[chriseppstein]

Even for the developers that created the overrides? o_O

yes. even for the developer that created the overrides. Or the developer who takes over your project, or the one you just added to your team. Sass is built for growth and maintainability over long time frames. How you built the project you worked on two years ago isn't always fresh in your mind.

I don't see how it's any more confusing than running something like -prefix-free

I didn't claim that it was less confusing than prefix-free -- I have the same critique of that project.

you should have MORE awareness of what's happening in your code.

You should. But maybe it's imported and maybe two years have past.

Unless you downloaded a mixin library which did this for you, in which case it has the exact same result as running -prefix-free.

I build such a mixin library. And we don't have the same problem as prefix-free because we keep our syntax distinct.

So, I don't see how that argument makes sense.

It's true, the strawman argument you're using doesn't make much sense.

Nothing would "magically happen" without your knowledge or without you at least setting up a library, which should document exactly what will happen.

Knowledge is often an ephemeral thing. Reading docs is not most people's first step. I always advocate for clarity for the reader, at the low cost of an extra few characters for the writer. Anyways, that's our philosophy for Sass, if Less wants to be magical like stylus then by all means, go ahead. I'm of the opinion that a little less magic and a little more syntax is good for developers, but reasonable people can disagree about what experience they want to optimize.

[matthew-dean]

Easy, friend, I think we agree on some important aspects. For instance, this syntax is close to my proposal:

.cover {
  +background-size: cover
}

Considering the dash starts a prefix now, it might make more sense to do this:

.cover {
  -background-size: cover;
}
-background-size(@values) {
  -webkit-background-size: @values;
  -moz-background-size: @values;
  background-size: @values;
}

Also, my only use case for mixin properties without dashes or dots was not just for property overrides. Yes, I considered that it has some potential for abuse. But that's not the only reason why defining custom properties might be valuable. And (while we're on the subject of strawmen), if an author is concerned about what they'll forget two years from now, and not be able to understand what they've done, they can define custom properties just as you've said, with a custom mixin name, or a dash syntax, or the traditional dot syntax. The point is simply that the developer can define the custom property.

However, the great irony in all of this is that a lot of these solutions seem to apply to prefixing, and we're nearing a time when: a) many vendors are supporting unprefixed properties, b) browser vendors and W3C are working to transparently solve the problem of prefixes. (http://www.sitepoint.com/css3-vendor-prefix-crisis-solutions-2/)

For keyframe animations, -webkit is the only other value required, which is not much duplication. For backgrounds and borders (like background-size), no prefixing is needed any longer (http://caniuse.com/#feat=background-img-opts). It doesn't mean it's not worth exploring, but any new feature added just (or mainly) to support prefixing does potentially have a reduction of value over time.