how i feel css pre-processors should be: extending the language via namespaced (prefix) attributes & functions - NOT via @include stuff

ex.md

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;
}

Or even:

.foo {
  bb-background-gradient: (red, green) left repeat; /* entirely custom "replacement" */
  bb-transition: all 0.8s;
  color: green;

True, but the power of @extend lies in its ability to create custom mixins:

.foo {
    @extend transition-down(all 2s);
}

.bar {
    @extend transition-up(all 2s);
}

See I'm thinking these should be seen as native extensions of the CSS language, not hacks on top. An equivalent could be:

.foo {
  ewp-transition-down: all 2s;
}

.bar {
  ewp-transition-up: all 2s;
}

Here you've defined a custom ewp-transition-up attribute/property.

The ewp- prefix just being a vendor namespace, could easily be bb- for bourbon, twbs- for twitter bootstrap for example.

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:

.foo {
        background-gradient: (red, green) left repeat;
        background: linear-gradient(red, green) left repeat;
}

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?

.bar {
    @include clearfix();
}

Compiles to

.bar:after {
    clear: both;
    content: "";
    display: table-cell;
}

Turns out, this language I've been dreaming up exists: Stylus!

See this: http://codepen.io/anon/pen/oLyDt/ and this: http://codepen.io/anon/pen/JmAIL/

Notice how I've defined my own "mixins", and they're used just like native properties. I can also, if I so wish, override the native properties to either a) provide polyfills for prefixes; b) troll