Themability

[vine77]

We may want to consider removing dependencies on a particular style framework, using an extensible theme framework, or only copy component-specific styles as needed from Semantic UI, Bootstrap, AdminLTE, or Primer.

[ahouchens]

What about https://github.com/sgasser/ember-cli-materialize? Do we need to go in this direction?

[vine77]

It looks like ember-cli-materialize and ember-paper both get high marks.

[vine77]

I think we have a few options:

1. Just pick a UI framework, and allow theming at the the CSS level, dependent on the framework choice. (Remove dependency on AdminLTE and move necessary styles to specific component addons.)
   • Bootstrap
   • Foundation
   • Semantic UI
   • UIkit
2. Leverage Semantic UI more fully, which already includes themes based on Google Material, Bootstrap, GitHub, and Amazon. Look at the existing Ember integration at Semantic-UI-Ember.
3. Allow theming at the component level.

[ahouchens]

Will we be able to reach the first alpha milestone (demo-able) faster if we select a single UI framework? If so - let's just do that. However my thoughts are that if it's not much additional work to use Semantic UI then all components in the bonfire ecosystem will use whatever theme is specified at the highest level. This would give masterful easy control for changing and updating css styles.

If there is one thing I've learned about the CSS styles consumed by an app - they need to be extremely easy to change - because aesthetics quickly become outdated. Proposal: Allow the user easy pathways (bonfire generators) to create their own semantic UI themes, and in the future allow components to be configured with their own themes that override the highest level theme. What are your thoughts?