Prepare for Bootstrap v4 beta

Bootstrap v4 beta seems to be round the corner and we need to asses impact on the existing widgets as well as the documentation site.

Widgets (tested with https://github.com/twbs/bootstrap/commit/b14c5cc4b8c23c5630d2520cab7e5d8ef1556049)

• - accordion => update to the new cards markup
• - alert
• - buttons
• - carousel
• - collaps
• - datepicker
  • btn-secondary => btn-light?
• - dropdown
  • - dropup is no longer the thing as poper.js is used for positioning
  • needs to use positioning service?
• - modal
• - pagination
• - popover
  • popover-title => popover-header
  • popover-content => popover-body
  • add arrow element
  • positioning is off for the top and left cases
• - progresssbar
• - rating
• - tabset
• - timepicker
• - tooltip
• - typeahead

Demo

• - update responsive classes
• - component doc pages
  • API / Examples titles need class update when selected
  • there is not enough “breathing room” in example cards (margins) => probably card structure change

Cleanup

• remove temporary reference to the Bootstrap CSS from RawGit

[pkozlowski-opensource]

@jnizet I’m going to merge your PR and cut first beta. All your points about Bootstrap 4 validation are … valid but AFAIK there is more work in the pipe for subsequent betas. Let’s see how things evolve on the Bootstrap side and then decide.

[jnizet]

I submitted an additional PR that displays green/red validation feedback, in the timepicker, typeahead and rating demos.

But to add the appropriate border to the timepicker input fields, I don’t see any nice solution. I also have the feeling that the painting isn’t really dry on the bootstrap side, because we lost many functionalities with that change: no icons anymore, no color applied to labels anymore, no warning state anymore.

• we can’t AFAIK add CSS rules for the inputs of the timepicker in the demo, since due to isolation, the rules wouldn’t apply. Even if we could, we would have to duplicate bootstrap CSS
• we could add a global css rule to the demo css. But once again, we would have to duplicate bootstrap CSS.
• to avoid duplicating bootstrap css, we would need to add .is-invalid to the inputs, in the timepicker component itself. But we can’t make that choice on behalf of the user: maybe it should be set when the control is invalid. Maybe it should be set when it’s invalid and touched. Or when it’s invalid and dirty.

So my guess is that the least ugly solution, if bootstrap doesn’t let us reuse the old .has-danger classes, would be to add an input to the timepicker. Something like

<ngb-timepicker [invalidWhen]="ctrl.dirty && !ctrl.valid" .../>

that would add the .is-invalid bootstrap class to the inputs based on a condition chosen by the user. But then we should do the same for .is-valid.