Good observation Mist. My suggestion would be to use double classes on the elements that use a name swap. For example "btn-es-success" could be something along the lines of "es btn-success". This way we can still specifically access the ES element with the following selector: .es.btn-es-success {code: value;}

There is probably a better way than that, but I agree that if ES is going to be as bootstrap 3 as possible, it should work well with bootstrap templates. Mine is custom, so for now I'm okay. But if I have a client down the road who uses one made by someone else, I could see how I would have a lot of work cut out for me.

Yes, they did a great job focusing on a "ready-made" (one-type-fit-all) system that can be integrated in pretty much any joomla template but if you have a joomla template that is already using latest Boostrap 3 and you already invested some time to customize this template to your requirements, you will run into troubles, as i am doing right now.

Simply put, small and quick example, even if they change "btn-es-success" into "btn-success" by heavy modifying the original bootstrap class, there will be conflicts with templates that are already using boostrap 3. Not to mention that "btn-success" looks totally different on EasySocial pages than other sections within the site that use the joomla's template bootstrap 3.

I will vote for a more logical approach.
We have Bootstrap 3: Great ! ... but
Design the products templates to make use of the "core" boostrap 3 classes and provide an option to use StackIdeas boostrap customization or inherit joomla's template boostrap 3.
Design the forms, pop-ups and pages, basically everything, using core bootstrap grid system (col-*) instead of customs classes and declarations.

This way, one that will use a boostrap 3-ready template ... will have all stackideas products "blended" in their design.

I'm inclined to agree the buzzword "Bootstrap 3" may have been sensationalized leading to the misunderstanding that EasySocial component would ride and reuse existing Bootstrap framework from Joomla!.

Our intention wasn't to strictly follow or reuse existing to Bootstrap classes, but rather to use Bootstrap as a backbone (you could call it forking) to build a much more sophisticated template architecture.

We use Bootstrap because it is a familiar-friendly framework for everyone.
We switched from Bootstrap 2 in v1.1 to Bootstrap 3 in v1.2 because we felt the urgency to migrate so that we are not left behind.

You might have noticed in 1.2, the stylesheets are organized by sections, and each of these sections has an individual section variables.
See: http://screencast.com/t/0RvAaAXZ0k4H

This is just the tip of the iceberg. We've got this accomplished in 1.2, so that in future versions, it becomes easier for us to build a "Template Customizer UI" which uses things like color pickers, sliders, etc.

As for the issue that you're describing in your post, we're toying on the possibility of importing your Joomla! theme's Bootstrap variables into EasySocial's forked Bootstrap, which goes along with the "Template Customizer UI" that we're planning to build.

Once we've got this running solid on EasySocial, then we can unify all the other products to ride on the same template architecture, which will simplify the process for third-party template developers to build compatible templates for all StackIdeas products.

P/S: I might be leaking too much internal plans for EasySocial.

I pretty much got the clear picture now.
Any magic you guys do, think about implementing a solution that can be hassle free for third-party templates.
In my current setup i run Bootstrap 3 in my custom joomla template and i also have some other template custom css file that basically customize the boostrap. My template already has all the styling needed for everything bootstrap 3 related stuff, all the fields, buttons, grid, interface elements ... basically everything.

EasySocial should blend in perfect with my existing bootstrap 3 stuff, but in current behavior i get conflicts.

Thanks for the explanation Jensen.

Hello Mist,

Most of the time, you are getting conflicts is because the template maker that are adopting Twitter Bootstrap is redefining a lot of styles from Bootstrap 3 rather than extending them. Take for instance, .btn-success . Some template clubs even go to the extend of applying "float:left" on this class because it suits their template. Hence, we derived from the original .btn-success class and used .btn-es-success so we can have minimal conflicts.

Makes sense to me Mark. Glad to hear this part was well thought out.

Yep, thanks for updating Josh