In raw CSS:
.foo {
background: -webkit-linear-gradient(red, green) left repeat;
background: linear-gradient(red, green) left repeat;
-webkit-transition: all 0.8s;
-moz-transition: all 0.8s;
transition: all 0.8s;
color: green;
}
The equivalent in scss & bourbon
.foo {
@include background(linear-gradient(red, green) left repeat);
@include transition(all 0.8s);
color: green;
}
I find the mixture between native attributes (color:
) and pre-processed functions (@include ...
) to be odd. I'd rather they extend the native language:
.foo {
background: bb-linear-gradient(red, green) left repeat;
bb-transition: all 0.8s;
color: green;
}
Or probably better:
.foo {
bb-background: linear-gradient(red, green) left repeat;
bb-transition: all 0.8s;
color: green;
}
IMO that becomes more difficult to read. With the @extend keyword present, there is a clear gap between what is a mixin and what is native to the CSS language. My concern is with your method, native CSS features and those defined by the user become blurred and therefore more difficult to use.
Example:
Without exact knowledge of the CSS spec, there is a potential to not realise what a declaration is doing (Admittedly this is a poor example, but it's the best I could come up with off the top of my head).
Also, unless you force a user to prefix everything, it leaves you open to the dangers of a new CSS spec that just happens to follow the same naming convention that your mixin has defined - what happens then?
One other point - how do things like
clearfix()
fit into that naming convention?Compiles to