Why won't this @mixin work?

[nixnerd]

I’m trying to write a mixin that thinks for me when it comes to vendor prefixes. This contains all the prefixable things I use the most and it’s SUPPOSED TO work, based on what arguments I feed it. Here it is:

@mixin vendors($prop, $value) {
    $webkit: -webkit-$prop;
    $moz: -moz-$prop;
    $ms: -ms-$prop;
    $o: -o-$prop;

    @if $prop == border-radius or box-shadow or text-shadow or border-image{
        $prop: $value;
    }

    @else if $prop == transition or animation{
        $webkit: $vlaue;
        $prop: $value;
    }

    @else if $prop == transform{
        $webkit: $value;
        $ms: $value;
        $prop: $value;
    }

    @else{
        $prop: $value;
    }
}

Why won’t it work? What am I missing?

[__]

You need to use interpolation when you use variables as (or in) property names:

@mixin vendors($prop, $value) {
    $webkit: -webkit-#{$prop};
    $moz: -moz-#{$prop};
    $ms: -ms-#{$prop};
    $o: -o-#{$prop};

    @if $prop == border-radius or box-shadow or text-shadow or border-image{
        #{$prop}: $value;
    }

    @else if $prop == transition or animation{
        #{$webkit}: $vlaue;
        #{$prop}: $value;
    }

    @else if $prop == transform{
        #{$webkit}: $value;
        #{$ms}: $value;
        #{$prop}: $value;
    }

    @else{
        #{$prop}: $value;
    }
}

Tested with:

#id{
    @include vendors( border-radius, 1em )
}

Results in:

#id {
  border-radius: 1em; }

I don’t know why it was “doing nothing” originally. I would have expected an error (at least, an error message would have been helpful).

[Alen]

Joe buddy let Grunt or Gulp take care of prefixing, why would you even want to maintain this when you can abstract it and let the community keep up with changes.

Also, you’re depending on this one mixing to do all the work, when you should really separate the concerns and be more descriptive.

If something goes wrong or if you’re getting unexpected results, tinkering with one mixing you might break other stuff. Single point of faliure.

See you guys more often after 2nd. Still roaming. :)

[nixnerd]

Please explain how Grunt will help this situation. I know everybody uses it… I don’t. Mainly because I didn’t want to install it from the AUR. But if its worth it….

[nixnerd]

Never mind… I can use npm… Which I’d rather do anyway.

[nixnerd]

See you guys more often after 2nd. Still roaming. :)

Are you on the road @alenabdula?

[__]

Last I heard:

Logged in roaming from Europe (during biggest floods in Bosnia)

and, back on-topic:

let Grunt or Gulp take care of prefixing, why would you even want to maintain this when you can abstract it and let the community keep up with changes.

I you want grunt/gulp for all they offer, that’s great. But if you really only need to solve this problem, I’d suggest using one of the wide variety of prefixer-type mixins in major sass libraries (compass and bourbon both have them, for example).

[nixnerd]

I’d suggest using one of the wide variety of prefixer-type mixins in major sass libraries

Maybe I haven’t seen the right ones but I was looking at Compass’ site the other day. All their vendor mixins seem to add unnecessary prefixes. I don’t want a whole s*** load of unneeded CSS lines. You know what I mean? Before that, I was using this tool where you run your compiled CSS through it and it adds needed prefixes. But, even it was adding things I didn’t need, plus, you have to add a manual step… which sucks. Who wants to take their compiled CSS and then run it through something like that? No thanks.

What’s so bad about writing my own mixin for prefixes? I would think that if anything… LESS prefixes will be needed in the future. So, worst case scenario, my mixin will only become outdated by being too thorough. Or am I thinking about this wrong?

BTW, I’m not done with this mixin. There’s a few things I want to add.

@Traq, that for your help BTW.

@AlenAbdula, glad to hear you’re ok.

[__]

vendor mixins seem to add unnecessary prefixes. […]
I would think that if anything… LESS prefixes will be needed in the future.

I agree. And, taken together, I would say this means that “unnecessary” prefixes aren’t really a problem.

In practice, the only prefixes that you would need to avoid are those where the old syntax would literally screw up the new syntax. I think there actually are some edge cases where this happens, but I don’t have specific examples.

Otherwise, what’s the harm in supporting some old browser version that nobody uses anymore?

What’s so bad about writing my own mixin for prefixes?

Nothing. Just might be easier to use an existing solution (what with programmers being lazy, and all*). And, as Alen said, you also offload the task of maintaining it (which is good, …unless it isn’t. but isn’t everything?).

* I really have to force myself to remember this, from time to time. I could spend a few weeks making something really awesome, or a few minutes downloading someone else’s something which is (for all practical purposes) functionally equivalent, if only mostly awesome.

[nixnerd]

I agree with all of that. I’m trying to code lean and mean these days, which causes me to sometimes focus on minimalism over anything else… almost to a fault. This mixin might seem a little verbose and maybe it’s not written in the most efficient way. But it’s goal is to save lines upon lines of unneeded prefixes.

I actually SPECIFICALLY wrote this for my new site because it will need a ton of prefixing for some animations I want to do.

In this post, @ChrisCoyier says this:

One mistake I sometimes see is that people just use all the major prefixes on every CSS3 property. It appears they have a generic mixin that they just put everything through that slaps on the prefixes. If you’ve seen something like -o-border-radius, that’s what I mean. That has never existed and never needs to go into your CSS.

My first instinct was to use a Compass mixin to handle it. But he has a point that those mixins are ‘dumb’ for lack of a better word and make no distinction between properties. Therefore, you get prefixes that aren’t necessary now and in fact have NEVER been necessary.

Although… in the end, what does it really matter? You’re talking about a few extra kilobytes… IF THAT by having the extra code. And I guess if it doesn’t break anything… who cares? Especially on this site… it’s flat design with no images. There might be a few SVGs but most of the graphics are pure CSS… which means a crazy small site. I’m shooting for the whole thing to be under 50KB.

You know me dude, this is mostly a philosophical exercise… I still might use it though. If nothing else, now I know I need to use interpolation… which I don’t know why I didn’t think to do that.

Thanks!

[__]

[some prefixer mixins] make no distinction between properties. Therefore, you get prefixes that aren’t necessary now and in fact have NEVER been necessary.

Look at how bourbon did it. Their prefixer mixin is an (internal) utility function, and each mixin that does something that needs prefixing calls it, passing which prefixes to use as an argument. The developers keep things up-to-date on each release.

If nothing else, now I know I need to use interpolation… which I don’t know why I didn’t think to do that.

I knew you’d have to use it to get a var to be part of a string, but I didn’t know that you had to use it no-matter-what in the property position. That threw me off for a bit.

I guess if it doesn’t break anything… who cares?

Indeed. Though I think it’s entirely reasonable to get something “best practice” to start with, and then you can “not worry about it” later.

[nixnerd]

Look at how bourbon did it…

I see. But, all that does is save me a bit of typing (which is cool and all). I still have to manually input which prefixes to add though. That’s the bit I’m trying to get away from. I want to not have to think and just focus on building the page.

You know what I mean?

[__]

Well, they don’t do

+prefixer( border-radius, 5px, webkit moz ms )

but rather, beforehand

=border-raduis( $radius )
    +prefixer( border-radius, $radius, webkit moz ms )

and then

+border-radius( 5px )

…if you follow. (not that any of that was actual code.) It’s extra work that you might not want to put into your own solution, but it is a level of abstraction that does a good job of solving the “shotgun prefixer” problem.

[nixnerd]

But wouldn’t that still require me to say WHICH vendors I’d like to include on any given call of that mixin?

[__]

You’d need to specify it once, but not each time you use it. What’s going on is you don’t use the prefixer mixin, you use (e.g.) the border-radius mixin, which knows which prefixes to specify when it calls prefixer.

This probably isn’t something you would want to do, when writing your own—after all, there’s no point in copying bourbon’s solution word for word. Just use it if that’s how you want it done. But, depending on how long you want your mixin to last, how flexible/ extensible you want it to be, it would be a good approach: breaking tasks into smaller units and delegating.

[Author]

Posts