S.T. said:
Are you attempting to communicate something of meaningful value there,
or do you just like random links?
[...]
I thought David was complaining I was imagining the US is very mm/dd/yy
centric. I often lose track of what he's talking about though.
It would be stupid to use yyyy-mm-dd formatting in this app.
Gee, I didn't know the rest of the world was a Database.
Are you honestly unable to follow along. Intranet app. Who cares about
the rest of the world in that context?
Is there a dropdown in that datepicker? I don't see it.
Not by default. Add {changeYear: true} when you initialize it and it
will have one. Same for month dropdown. There's a number of examples in
the right sidebar on
http://jqueryui.com/demos/datepicker/
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.
You've gone from "Not keyboard accessible! The calendar should be
navigable by the keyboard keys." to not liking the shortcut keys they
use. That's a step up.
I'd tend to agree the key bindings are not intuitive. The stated plan is
full WAI-ARIA support by version 2.0, hopefully be the end of the year.
At that stage keyboard nav will presumably follow the reasonably
standard
http://www.w3.org/TR/wai-aria-practices/#datepicker
ARIA isn't high on my own list of concerns, but is another example of
why I don't view jQuery UI as ready for primetime yet, instead using it
sparingly for in-house stuff.
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.
You've gone from showing your own calendar 'widget' to complaining that
calendars widgets are pointless?
Sometimes they're not needed, sometime they provide quite a bit of
utility. And I have no need to anticipate "everyone" -- just the 25 or
so people using my intranet app.
Hopefully the server side programmers aren't dumb enough that they want
mm/dd/yy and can actually handle a standard ISO-8601 format.
You're suggesting I force data entry to use yyyy-mm-dd, despite the fact
that's not a convention they're used to using and never see on the data
they're entering, because I don't want to accommodate on the back-end?
Makes no sense.
function ISODate($date) {return date("Y-m-d",strtotime($date));}
No big deal.
I know I would not do that. I would provide an ID for the container so
it can be customized in CSS. e.g.
Yeah, I'd prefer if they gave me the option to pass the container an ID
if I specified one -- easier and more reliable to write CSS rules for
non-standard usage.
#myInput-list {
width: 10em;
}
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.
The container does not have an ID? What is it appended to? Can you use
descendant selector?
Container is an absolute positioned ul with a class .ui-autocomplete. On
their demo looks like appended to body. On my app appears appended after
I would rather have the option of:
#myInput, #myInput-list {
width: 10em;
}
to make the same width if I want that. It doesn't seem that hard to
configure, not to me at least. Then again, I can see how others would
have problems iwht it.
Something along those lines is what I'm hoping they do, however my
particular preferences may not match the goals of a general purpose set
of widgets. If the end result works for my needs, great. If not, isn't
hard to find an alternative or roll my own.
