Browse files

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

…ion option.
  • Loading branch information...
1 parent 5435c50 commit 612838a1518c8cdc80b5bace5d925f89c1e791a3 @scottgonzalez scottgonzalez committed Jul 19, 2010
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;;
- my: "left top",
- at: "left bottom",
- of: this.element,

brandonwittwer Nov 11, 2010

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


scottgonzalez Nov 11, 2010


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"
- });
+ $.extend({
+ of: this.element
+ }, this.options.position ));
menuWidth = ul.width( "" ).outerWidth();
textWidth = this.element.outerWidth();

6 comments on commit 612838a


jzaefferer 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 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 replied Jul 20, 2010

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.