Skip to content
Permalink
Browse files

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

…ion option.
  • Loading branch information...
scottgonzalez committed Jul 19, 2010
1 parent 5435c50 commit 612838a1518c8cdc80b5bace5d925f89c1e791a3
Showing with 16 additions and 8 deletions.
  1. +6 −1 tests/unit/autocomplete/autocomplete_defaults.js
  2. +10 −7 ui/jquery.ui.autocomplete.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 });
@@ -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
this.menu.deactivate();
this.menu.refresh();
this.menu.element.show().position({
my: "left top",
at: "left bottom",
of: this.element,

This comment has been minimized.

Copy link
@brandonwittwer

brandonwittwer Nov 11, 2010

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

This comment has been minimized.

Copy link
@scottgonzalez

scottgonzalez Nov 11, 2010

Author Member

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.

collision: "none"
});
this.menu.element.show().position( $.extend({
of: this.element
}, this.options.position ));

menuWidth = ul.width( "" ).outerWidth();
textWidth = this.element.outerWidth();

6 comments on commit 612838a

@jzaefferer

This comment has been minimized.

Copy link
Member

replied Jul 20, 2010

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

@scottgonzalez

This comment has been minimized.

Copy link
Member Author

replied Jul 20, 2010

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

@jzaefferer

This comment has been minimized.

Copy link
Member

replied Jul 20, 2010

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

@warmrobot

This comment has been minimized.

Copy link

replied Oct 28, 2010

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 :)

@brandonwittwer

This comment has been minimized.

Copy link

replied Nov 11, 2010

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.

@warmrobot

This comment has been minimized.

Copy link

replied Dec 4, 2010

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.
You can’t perform that action at this time.