Typeahead input with form-inline

[drozzy]

So I tried to use typeahead with Bootstrap's .form-inline style Forms, but because of the hidden div, the control causes any subsequent input fields to start at a new line.

I'm no css guru. but is there an easy way to fix this?

[petebacondarwin]

This is a problem that I found too. Spent some time trying to get a fix
going but to no avail. :-(

On 25 March 2013 03:05, drozzy [email protected] wrote:

So I tried to use typeahead with .form-inlinehttp://twitter.github.com/bootstrap/base-css.html#formsstyle Forms, but because of the hidden div, the control causes any
subsequent input fields to start at a new line.

I'm no css guru. but is there an easy way to fix this?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/262
.

[drozzy]

My current solution is to use grids - and put the typeahead input into it's own cell of span4, but it does look rather ugly :-)
We need us a css expert.

[pkozlowski-opensource]

@drozzy did you try this with vanilla bootstrap? From what I can see they are also attaching dropdown with matches after an input (https://github.com/twitter/bootstrap/blob/master/js/bootstrap-typeahead.js#L64).

Could you give it a try and eventually open an issue in the bootstrap's repo?

[pkozlowski-opensource]

Reproduce scenario is anyone is curious to have a look: http://plnkr.co/edit/HEZlMT?p=preview

[redaemn]

@drozzy A simpler solution could be to wrap the typeahead inside a div that has the same style as the .form-inline input. Take a look at this: http://plnkr.co/edit/mraNmT?p=preview

Here I used inline css but you got the idea.

The problem is just that bootstrap define a css rule for .form-inline input that sets a display: inline-block; that puts all the <input> on a single line; our typeahead is an <input> but it's followed by a div that contains the menu, the rule doesn't apply to it, it has display: block; by default and all the next input are displayed on a new row. The wrapping div with the dispaly: inline-block; makes the trick.

Obviously this is just a fix to make it possible to use typeahead in this scenario, starting from this maybe we could think about a good way to modify the typeahead so that this won't happen.

[petebacondarwin]

Really this is a bug in twitter bootstrap, me thinks

On 26 March 2013 23:01, Gabriele Rabbiosi [email protected] wrote:

@drozzy https://github.com/drozzy A simpler solution could be to wrap
the typeahead inside a div that has the same style as the .form-inline
input. Take a look at this: http://plnkr.co/edit/mraNmT?p=preview

Here I used inline css but you got the idea.

The problem is just that bootstrap define a css rule for .form-inline
input that sets a display: inline-block; that puts all the on a
single line; our typeahead is an but it's followed by a div that
contains the menu, the rule doesn't apply to it, it has display: block;by default and all the next input are displayed on a new row. The wrapping
div with the dispaly: inline-block; makes the trick.

Obviously this is just a fix to make it possible to use typeahead in this
scenario, starting from this maybe we could think about a good way to
modify the typeahead so that this won't happen.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/262#issuecomment-15494389
.

[redaemn]

@petebacondarwin no, it's not a twitter bootstrap bug. Take a look here: http://plnkr.co/edit/hqyMjF?p=preview

The twitter bootstrap typeahead works correctly because the dropdown-menu somehow does not "break" the display: inline-block; set by the .form-inline input rule

edit: it seems that the typeahead dropdown menu from twitter bootstrap is just a <ul> with position: absolute instead the dropdown menu from angular-ui is wrapped inside a <div> with position: relative; IMHO this could be the problem...

[pkozlowski-opensource]

Oh dear, the joy of positioning... Thnx @redaemn for looking into this one... I think I've taken markup for the template from some other PR and didn't spend too much time on it. Honestly it was nice since didn't require me to calculate positioning as original typeahead does.

I won't be able to get back to this one anytime soon (as we've got a work-around and I would like to focus on functionality fixes first) but it would be awesome if anyone would like to look into this one.

[redaemn]

@pkozlowski-opensource yes, I think that we will need to calculate positioning inside the directive; would it be a problem?

Also, I'm trying to use ng-show to show or hide the menu but I'm having some problem: the menu is display: none by default (bootstrap css) and all that ng-show seems to do is add an inline display: none when the expression is false and remove it when it's true... that doesn't work!! It should force a display: block or something when the expression is true. Is this the right behavior of ng-show or am I missing something?!?

[redaemn]

I started to look into a framework fix for this one (just for fun) but how am I supposed to dynamically position the menu based on the <input> position if I can't use .position(), .outerHeight() or any other jQuery functions? angular.element alone does not support any of this... this could be hell...

[petebacondarwin]

That's probably why Pawel didn't implement it in the first place!

On 27 March 2013 22:28, Gabriele Rabbiosi [email protected] wrote:

I started to look into a framework fix for this one (just for fun) but how
am I supposed to dynamically position the menu based on the position if I can't use
.position(), .outerHeight() or any other jQuery functions? angular.elementalone does not support any of this... this could be hell...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/262#issuecomment-15557248
.

[pkozlowski-opensource]

This can be fixed by #326
http://plnkr.co/edit/HEZlMT?p=preview

@redaemn Thnx for the experiments in #276, this was good inspiration. Finally I did something similar but extracted relevant code to a separate service. There was also a problem with watching DOM properties which is slow.

[redaemn]

@pkozlowski-opensource happy to have been of help!! :D I thought that probably watching could be too slow but I didn't spent any time thinking about a better solution, it was just the first idea that came to mind.