My first thought is "does that mean that we pick one and then make the rest extensions?" I think people wouldn't be thrilled by the project if they didn't get "out of the box" styling for their component, right?

@brianfeister Ya, thats what my thought would be. I see all over some bugs in certain ones, people wanting to add new ones, etc. Its a lot of maintain and harder to add new features/bug fixes rapidly.

Ya, there will always be people complaining; where do you draw the line is the question? Maybe phase it out?

Related to #186

I agree that the current approach is difficult to maintain. Maybe we should open a branch to start testing some different approaches. Anyone up for the challenge to start this?

My only concern is submodules - if we submodule these alternate themes, we can expect lots of issues to be opened by beginners who have a harder time grasping submodules. Is there any chance we could have the themes exist as branches and have users checkout a specific build via bower install ui-select#{theme-name}, leaving Bootstrap as the main theme for users who don't check the project out via a specific hash? I feel like this is possible, but I'm a bit foggy on the details. We would probably want to write a grunt script that does releases and ensures the alternate theme branches get the latest src code from master and then rebuilds the alternate theme branches and pushes on each release.

@brianfeister Agreed.

@dimirc Ya, its gonna kinda be a somewhat major undertaking but I think it will help w/ a lot of things. I'll create a branch for this and get it kicked off.

right now it seems that bootstrap.css is required no matter which theme is selected. is that correct or am i using it wrong? i've been playing around with ui-select for use with semantic-ui as the primary css framework, so i would also like to see a neutral default theme on top of which theme-specific css can be added.

@clairity Do you have a semantic-ui theme for angular-ui-select?