Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Autocomplete: Added position option. Fixes #5153 - Autocomplete posit…

…ion option.
  • Loading branch information...
commit 612838a1518c8cdc80b5bace5d925f89c1e791a3 1 parent 5435c50
@scottgonzalez scottgonzalez authored
7 tests/unit/autocomplete/autocomplete_defaults.js
@@ -6,7 +6,12 @@ var autocomplete_defaults = {
delay: 300,
disabled: false,
minLength: 1,
- source: undefined
+ position: {
+ my: "left top",
+ at: "left bottom",
+ collision: "none"
+ },
+ source: null
commonWidgetTests('autocomplete', { defaults: autocomplete_defaults });
17 ui/jquery.ui.autocomplete.js
@@ -16,8 +16,14 @@
$.widget( "ui.autocomplete", {
options: {
+ delay: 300,
minLength: 1,
- delay: 300
+ position: {
+ my: "left top",
+ at: "left bottom",
+ collision: "none"
+ },
+ source: null
_create: function() {
var self = this,
@@ -269,12 +275,9 @@ $.widget( "ui.autocomplete", {
// TODO refresh should check if the active item is still in the dom, removing the need for a manual deactivate;;
- my: "left top",
- at: "left bottom",
- of: this.element,

what would it take to move of: for positioning into the options?

@scottgonzalez Owner

It would require changing the position plugin to accept functions that dynamically compute what element to position against and setting the context of that function in some logical way so that we can even figure out what element we want to position against.

This shouldn't happen anyway. Just because we don't list of in the defaults, doesn't mean you can't pass it as an option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
- collision: "none"
- });
+ $.extend({
+ of: this.element
+ }, this.options.position ));
menuWidth = ul.width( "" ).outerWidth();
textWidth = this.element.outerWidth();

6 comments on commit 612838a


Shouldn't the arguments to $.extend be switched? Or do we want to allow the user to specify the of-property?


I wanted it to be as flexible as possible. If the user really wants to specify a different element to position against, they can, but they'd have to intentionally do it. This probably allows for some crazy kind of complex autocomplete UI that somebody will think of one day :-P


Yeah, makes sense. We should apply the same logic elsewhere, eg. I'm pretty sure tooltip needs an update.


Scott, believe you or not: I am just in situation where autocomplete is on the top of dialog window, and suggestions are shown in the bottom in normal flow (I mean it has position: static). ye-ye, it's fantastic design ( So I am surely has to use position({ of: ...}) and some sort of height calculations :)


what would it take to move "of:" for positioning into the options? I've got a searchbox which does autocomplete, but the autocomplete widget needs to attach to the bounding box for the search area, not the field. We've customized our own control for this go around, with hard coded element reference, but moving it up to the options and defaulting it to this.element seems like a good idea.


Sorry for answering so late, but results list height can be different and absolute positioning will overflow content below. I see on milestone 3 "appendTo" option appears (defaults to "body") and I think it is very good idea.

Please sign in to comment.
Something went wrong with that request. Please try again.