D
David Mark
Garrett said:S.T. said:
Are you attempting to communicate something of meaningful value there,
or do you just like random links?
[...]
Perhaps I didn't explain what they're doing. Data entry people get
rate sheets via PDF, Excel file, fax, postal mail, etc. It might look
something like rates seen in:
http://bit.ly/aEFHfB
All these rates, perhaps a thousand pages worth from hundreds of
different sources, have to be merged into a database. There is no
standard format for rate sheets. Some will have dates as column
headers, others may have dates as row headers. Some will have multiple
date ranges that have an identical rate lumped together in a single
column/row, others will show all date ranges in chronological order
regardless of duplicate rates, and so on.
The only thing truly consistent is these rates are NEVER provided
yyyy-mm-dd. In the case of US properties, mostly what we handle,
they're almost always mm/dd/yy(yy). A few we receive, especially
Canadian, will be dd mmm yyyy (5 Sep 2010). But mostly, it's the
mm/dd/yyyy
So what?
So it shows that S.T. hasn't thought about what he is writing, which
illustrates a problem and dismisses the obvious solution.
Gee, I didn't know the rest of the world was a Database.
Is there a dropdown in that datepicker? I don't see it.
That one is correct.
That one is correct.
There are only two shortcut keys that are correct. The rest - Are you
kidding? ctrl+page up to select previous year, plus other such wacky
shortcuts. Who is going to remember and use that stuff? It is junk.
Yep.
Why can't I just type the date in a normal standard input? Just get rid
of that horrible junk and give me a text box so I can type it in. Don't
prevent the user from entering a standard format. Don't anticipate that
everyone is as dumb and wants the mm/dd/yy format.
Hopefully the server side programmers aren't dumb enough that they want
mm/dd/yy and can actually handle a standard ISO-8601 format.
Hope springs eternal.
I know I would not do that. I would provide an ID for the container so
it can be customized in CSS. e.g.
#myInput-list {
width: 10em;
}
Why would you do that? The width of the drop down would certainly need
to be dynamic. The width of the input would typically be the minimum
(for aesthetic reasons), but often it may need to grow from there to
accommodate the suggestions.
Let it be as wide as it needs to be. An Autocomplete could have images.
I have right here in front of me a demon that has images large text and
when the object is focused outside the viewport (by user hitting DOWN
arrow key), then scrollIntoView brings it into view. Not desirable, but
less bad than the user not seeing it at all.
I don't quite follow that (and definitely don't see where the
scrollIntoView method would come into play).