How do I modify a dropdown box?
in [JavaScript]
|
Prev: FAQ Topic - How do I get a jsp/php variable into client-side javascript? (2010-05-03)
Next: The famous 'resend'
From: David Stone on 3 May 2010 08:49 In article <oRaGpaE+mp3LFw6p(a)J.A830F0FF37FB96852AD08924D9443D28E23ED5CD>, John G Harris <john(a)nospam.demon.co.uk> wrote: > On Sun, 2 May 2010 at 22:08:03, in comp.lang.javascript, Garrett Smith > wrote: > > <snip> > >First name: [_______________] > >Last name: [_______________] > >Birth date {YYYY-MM-DD): [_______________] > <snip> > > But accept > 2010-05-03 > 2010-5-3 > 2010/5/3 > 2010.5.3 > as equally valid. (Unless you actively want to lose customers). > > John Run into that before. As well as pages that reject credit card numbers unless there is a space every four digits (only a single field for input, but they don't tell you to include the delimiters they _require_). Not to mention myriad problems with telephone numbers. Or stupid forms that reject perfectly deliverable RFC-compliant e-mail addresses (e.g. fred+usenet(a)example.com) as "invalid". The list is endless...
From: Jukka K. Korpela on 3 May 2010 11:04 bruce wrote: > I have 3 dropdown boxes, Month, Day, Year. As usual, a URL would have helped. In particular, it would have helped to see whether this approach is feasible at all, since that depends on the intended audience and on the kind of dates to be entered. Note that to the majority of mankind, it is unnatural to enter a date in that order. But if the audience is more or less limited to certain northern parts of the American continent, you might adapt to the odd habits of its inhabitants. People have addressed the issue of date input design, which is understandable but mostly off-topic in this group. However, before considering the programming challenge, you should really first make an informed decision on the design problem. As a rule, there are two good ways to read dates: 1) Free text input with some instructions on format. This means that you need both client-side and server-side code to parse the data and to report errors. 2) Graphic calendars where the user can just click on a date. These require nontrivial programming and should be accompanied with some fallback considerations. So it isn't easy, and therefore you may consider easy ways of reading dates, despite the reduced usability. If you label each field properly, the odds of getting badly wrong data (e.g., July 4th when the user actually meant April 7th and thought he specified that) can probably be reduced to almost zero if month _names_ (not numbers) are used. > When I change the month, I > want the contents of the Day dropdown box be adjusted to the correct > days in the new month. I would expect to be able to use an onChange > event on the Month dropdown box. I don't know how to reset and reload > the Day dropdown box. There are several possible approaches. One of them is to dynamically modify the select element by removing or adding options. As a simpler approach, with some drawbacks (especially dependency on CSS) is to modify just the appearance of the options, e.g. setting their display property (in styles) to 'none' to remove an option from rendering. Yet another approach is to generate the entire Day dropdown box dynamically after the month has been selected. In each approach, you would need to consider what happens when the user changes the month selection - perhaps after having selected day. (Nasty, isn't it? What should happen if the user selected January 30, then changed month to February.) There's yet another tricky issue. How many days are there in February? It depends on the year, and in this context, we would expect the user to select year last... So what I'd suggest is that you let the Day dropdown have options up to 31 and you check later, e.g. at form submission, that the date selected is possible. For good usability, an error should be reported as early as possible. This would require several event handlers and you would need to decide what to do in error situations, in addition to reporting the error, of course. -- Yucca, http://www.cs.tut.fi/~jkorpela/
From: Ben C on 3 May 2010 11:38 On 2010-05-03, David Stone <no.email(a)domain.invalid> wrote: > In article ><oRaGpaE+mp3LFw6p(a)J.A830F0FF37FB96852AD08924D9443D28E23ED5CD>, > John G Harris <john(a)nospam.demon.co.uk> wrote: > >> On Sun, 2 May 2010 at 22:08:03, in comp.lang.javascript, Garrett Smith >> wrote: >> >> <snip> >> >First name: [_______________] >> >Last name: [_______________] >> >Birth date {YYYY-MM-DD): [_______________] >> <snip> >> >> But accept >> 2010-05-03 >> 2010-5-3 >> 2010/5/3 >> 2010.5.3 >> as equally valid. (Unless you actively want to lose customers). >> >> John > > Run into that before. As well as pages that reject credit card > numbers unless there is a space every four digits (only a single > field for input, but they don't tell you to include the delimiters > they _require_). Why they can't just delete the spaces or put them in themselves if they want/don't want them I don't know. > Not to mention myriad problems with telephone numbers. > > Or stupid forms that reject perfectly deliverable RFC-compliant > e-mail addresses (e.g. fred+usenet(a)example.com) as "invalid". > > The list is endless... Several times I've been told my mother's maiden name isn't allowed to contain digits.
From: Garrett Smith on 3 May 2010 16:22 Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> bruce wrote: >>> I have 3 dropdown boxes, Month, Day, Year. [...] >> 1) prevents the user from entering data when the browser is unable to >> execute the script script. > > No, it can be written so that it shows all items by default. Fortunately, > January has 31 days. > That is true for January, yes, but not February. The input will need server side validation. >> 2) "mm/dd/yy" and is ambiguous and leads to wrong data being entered. >> particularly when used by non-Americans. > > You are jumping to conclusions. They may as well be using mmm/dd/yyyy, in > which case it would not be ambiguous. > The format mm/dd/yyyy is also ambiguous. Proper labeling of the fields can avoid ambiguity. >> 3) Cumbersome for the user; user must tab to each field and enter the >> data by using arrow keys. > > But tabbed navigation is accessible by contrast, and in some browsers you > can type the number to highlight the item without using the arrow keys. > I very much prefer that over entering delimiters. > And I very much prefer typing one character and then hitting down arrow key, selecting a previously entered value from the list that my browser provides by pressing enter. I also like to be able to copy paste values to and from the input. >> Text input, with ISO-8601 date format works with no javascript > > Other date formats, too. > The format must be validated on the server no matter which approach is used. The ISO-8601 format can be easily understood worldwide and, unlike other formats, it is standardized. >> and can be unambigously understood, world-wide. > > There are other date formats for which this applies, too. > >> For the label text, include the ISO 8601 Extended format, as below. You >> may optionally use placeholder text in the input. >> >> First name: [_______________] >> Last name: [_______________] >> Birth date {YYYY-MM-DD): [_______________] > > Please don't. > Why not? [...] >> You may want also to use input type="date" with an HTML doctype in the >> document. > > No, you do not want to. That type of control is buggy. > Seems to on Opera for dates after 1582. >> Browsers that do not support that attribute value will default to text >> input. > > You cannot know that. There is no provision in the Specification for a > fallback to the default value if an invalid value is specified, so any > observed fallback behavior is proprietary. > The default value for this attribute is "text". If the browser does not recognize an attribute value, HTML 4 recommends that the browser ignore it. <http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.1> All browsers I know handle input that way; they seem to follow the recommendation; dropping the attribute value and using the default value. That fact allows HTML 5 to get away with specifying new types while providing some means to a fallback for the user to enter data. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Stanimir Stamenkov on 3 May 2010 16:43
Mon, 03 May 2010 08:49:35 -0400, /David Stone/: > Or stupid forms that reject perfectly deliverable RFC-compliant > e-mail addresses (e.g. fred+usenet(a)example.com) as "invalid". fred+usenet(a)example.com is not valid as real email address and should not be deliverable - the example.com domain being reserved for example purposes: http://tools.ietf.org/html/rfc2606#section-3 -- Stanimir |