search

sliptree / bootstrap-tokenfield

A jQuery tag/token input plugin for Twitter's Bootstrap, by the guys from Sliptree
http://sliptree.github.io/bootstrap-tokenfield/
Other
859 stars 238 forks source link

Hint overflows input field boundary #161

Open amnesia7 opened 10 years ago

amnesia7 commented 10 years ago

I'm using tokenfield with typeahead.js.

Tokenfield appears to adjust the width of .tt-input according to how much space is available within the main input field boundary but it doesn't seem to adjust the width of .tt-hint which continues to be the original size (ie the full width).

Let's say I have several tokens selected already and for this reason am most of the way across the form field. I then start typing a long token name and typeahead autocompletes it using the hint. Since the hint has not been width adjusted the autocompleted hint goes beyond the right hand side of the form field.

Is this expected or a bug? Should it chop/hide the end of the hint as it does with the input until you create the token?

Col

mryellow commented 10 years ago

Looking at the same issue today, thought that it was a case of Bootstrap grid system messing it up however seems your description is more accurate.

This seems to be the culprit. Enough going on there that a miscalculation seems likely. https://github.com/sliptree/bootstrap-tokenfield/blob/master/js/bootstrap-tokenfield.js#L887-L889

mryellow commented 10 years ago

In update:

Nowhere do I see this.$input being a tt-hint field, or any spots which touch it's width.

Ok this might be typeahead issue, they aren't as good at handling parent styles and bootstrap, none of the cool code like tokenfield that goes and grabs label styles etc.

mryellow commented 10 years ago

https://github.com/twitter/typeahead.js/issues/958

With some debugging in typeahead the flow is a little mixed up, maybe on tokenfield end actually....

I wonder if we can delay when buildDom in typeahead gets called somehow.

mryellow commented 10 years ago

Demo:

http://e3e3.com/issue/test.html

http://e3e3.com/issue/tfissue.jpg

Seems that when everything is set from value attribute rather than setTokens it gets in early enough to beat typeahead to the width calculation.

mryellow commented 10 years ago

Anyone who knows these codebases better than me think that the solution might be to recall typeahead buildDom after a setTokens, or from tokenfield update method? I don't see too much of this scope crossing going on, so might just be the wrong approach.

So far looking like this is the only value stuff that will beat typeahead to the punch.

// Create initial tokens, if any
this.setTokens(this.options.tokens, false, ! this.$element.val() && this.options.tokens )

https://github.com/sliptree/bootstrap-tokenfield/blob/master/js/bootstrap-tokenfield.js#L166

So would appear the tokens option or value is the only real solution.

mryellow commented 10 years ago

hmmm ok that's fine at first, then adding a token pushes it off the right again.... Every new token is going to have to adjust the width calculation in typeahead somehow.

From J. Harding (typeahead): "Alternatively, in v0.11, you'll have full control over the DOM components used for the input, hint, and results. In theory, this should give you the flexibility needed to integrate typeahead.js with tokenfield."

ragulka commented 9 years ago

Hello guys, sorry to be late for the party. I've been quite busy with other projects. This may well be an issue with typeahead, but maybe also with my implementation of setting the input width.

So did you make a test with the buildDom approach yet?

mryellow commented 9 years ago

Haven't had a chance to really dig into it, good enough for debugging other stuff I've had to look at first.

Typeahead is a bit less advanced when it comes to pulling apart existing DOM (or dealing with bootstrap) and moving styles into new elements, which makes it all a little messy. Tokenfield handles this really well, clickable labels etc etc.