@caesar2164 I don't agree with that logic. 

Mixins and extends shouldn't be chosen for the purpose of differentiating whether something is related to a theme or a general re-usable styling element (this is what I'm assuming you're referring to as a "class"). That differentiation should happen within our other Sass/CSS practices - such as breaking things up into a core set of Sass rules/styles and overriding/extending with theme-based Sass after (what we're all doing in general with this theme add-on).

Here's a simple example of how extends and mixins are used, alongside how they render - https://coderwall.com/p/7p7w2a.  Also, here's another rundown on how they're different - http://blog.kiskolabs.com/post/5445752361/extend-your-sass. Using extends for static shared css rules has a few benefits:

* **Bloat** - less bloat and redundancy from rendered rule to rule
* **Code Clarity** - differentiation to front end developers on when a value/argument needs to be passed in for proper use (extends don't take arguments, thus in an app/site that leverages extends, it would be clearer when arguments/settings, due to the @include(arguments) syntax are needed when using a mixin vs. a site/app that used mixins for everything.)
* **Definition/Use in Context** - extends can be defined in the appropriate context of our Sass architecture - we have a lot of global/utility classes/extends defined in the example I provided, but I have also started creating classes to extend in other places, namely in our typography settings (https://github.com/edx/edx-platform/blob/master/cms/static/sass/elements/_typography.scss) for Studio. This helps in managing base rules by grouping them by purpose.

**If this will cause you headaches now in getting things going for 6/11, it can wait until a follow-up with theming is done. Its important we are all on the same page as a team on how to create re-usable and foundational styling rules longer-term**

I'm happy to talk this over more on HipChat or a video chat too.