Opened 14 years ago
Closed 5 years ago
#3272 closed task (patchwelcome)
ComboBox: standardize dropdown placement
Reported by: | bill | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | 1.13 |
Component: | Dijit - Form | Version: | 0.9 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by )
The drop down list can flutter between being above and below the <input> box depending on how much room there is on each side _and_ how much data is in the list. As you type the position can switch.
Since our drop downs auto-size to the space available, let's make the drop down always go below the <input> box, unless the space below the input box is really cramped (say, less that 100px).
Attachments (1)
Change History (16)
comment:1 Changed 14 years ago by
Summary: | Autocompleter/Select: standardize dropdown placement → ComboBox: standardize dropdown placement |
---|
comment:2 Changed 14 years ago by
comment:3 Changed 13 years ago by
I think always going to the largest area will prevent flutter, be easy to program, and minimize user scrolling.
comment:4 Changed 13 years ago by
Ok, so right now the placement code prioritizes placement based on a first come first serve basis. place is called with the bottom position first so that is why we see fluttering. If we removed that part of the code it would stick to the largest area.
comment:5 Changed 13 years ago by
The placement code works correctly for most drop downs, like Calendar or Menus. This is a special case because the drop down list is of a variable height (ie, unlike Calendar, it needs a scrollbar). So let's not change the drop down code for the general case.
As per Doug's suggestion to always go to the largest area, I posted http://dojotoolkit.org/forum/dijit-dijit-0-9/dijit-development-discussion/drop-down-placement-combobox-filteringselect-soli to see what others thing. Like to get some more input on this.
Changed 13 years ago by
Attachment: | 3272.patch added |
---|
place.js checks all possible popup positions to see where there is the most viewable space, making popup placement more consistent. Fixes #3272.
comment:6 Changed 13 years ago by
Bill I changed the patch I sent you. Because I removed the break in place.js I had to make sure tooltip-type popups exit the code with the "best" orientation at the end.
comment:7 Changed 13 years ago by
You know I'm concerned that my algorithm messes up the Menu test because any submenus that you open on the right half of the page appear to the left no matter what.
comment:8 Changed 13 years ago by
And similarly I think it would be really arbitrary for submenus to start popping to the left or on top when you still have 100px available to you.
comment:9 Changed 13 years ago by
Milestone: | 1.0 → 2.0 |
---|
comment:11 Changed 12 years ago by
Milestone: | 1.3 → 1.4 |
---|
bumping 1.4 tickets to 1.5, and most 1.3 tickets to 1.4
comment:12 Changed 11 years ago by
Description: | modified (diff) |
---|---|
Milestone: | 1.4 → future |
comment:13 Changed 10 years ago by
Component: | Dijit → Dijit - Form |
---|
comment:14 Changed 6 years ago by
Owner: | haysmark deleted |
---|---|
Status: | new → assigned |
comment:15 Changed 5 years ago by
Milestone: | future → 1.12 |
---|---|
Resolution: | → patchwelcome |
Status: | assigned → closed |
Given the lack of activity in the past 8 years, I'm closing this as patchwelcome.
EXT flutters too:
http://www.extjs.com/deploy/ext/examples/form/combos.html
Fluttering is the industry standard; why deviate?