I suggest you ...

Permit a fallback to bootstrap for 'fueled' components.

Permit a fallback to bootstrap for 'fueled' components.

As example, we should be able to use bootstrap Datepicker instead of Fueled Datepicker because the last, contrary to the bootstrap original component, does not support very well i18n.

2 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Cedric A shared this idea  ·   ·  Admin →

    2 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Fuel UX controls can all be added individually vs as an entire library. In Fuel UX 2.0, this can be done using AMD (Require.js, etc). In the upcoming Fuel UX 3.0, the controls can be added individually using any method you choose (AMD, inline script tag, etc). By having the capacity to include only the controls you choose the idea of a fallback is no longer necessary. Thank you for the comment though as it confirms our decision to make including individual files easier and emphasizes the need for better documentation on how to do this.

      • Cedric A commented  · 

        The 'fueld' Datepicker component could be corrected, but the idea is that you can't predict which feature of the core bootstrap component could possibly induce troubles with fueled component. So there should be an "easy" fallback method to core bootstrap for almost every 'fueld' component.

        (Priority to end user rather than unified design)

      Feedback and Knowledge Base