search

bonfirejs / bonfire

1 stars 0 forks source link

Themability #4

Open vine77 opened 9 years ago

vine77 commented 9 years ago

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 commented 9 years ago

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

vine77 commented 9 years ago

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

vine77 commented 9 years ago

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.)
  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 commented 9 years ago

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?