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: Thomas 'PointedEars' Lahn on 3 May 2010 17:25 Garrett Smith wrote: > 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. You miss the point. January is the first month. If the first item of a SELECT element is selected by default by the UA (there is no requirement for that), then there is no problem with the date control showing 31 days. > The input will need server side validation. Yes, but that is beside the point. >>> 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. Read again. > Proper labeling of the fields can avoid ambiguity. Unambiguous text, too. >>> 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. You realize, of course, that with a single date control that will be all the dates you have ever entered in that browser (unless limited history alleviates that problem), provided the control's name is right. It might turn out not to be so useful after all. > I also like to be able to copy paste values to and from the input. For *date* controls? Well, suit yourself, but it is arguably less accessible and more ambiguous to let the user type in delimiters. At least use three (or more) controls instead of just one. >>> 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. However, you cannot validate what you cannot tell from one another, so an unambiguous date format is mandatory one way or the other. > The ISO-8601 format can be easily understood worldwide So can other date formats. > and, unlike other formats, it is standardized. Irrelevant. The worm must be tasty for the fish, not for the fisherman. We've been over this. >>> 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've been told already. > [...] >>> 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. Exactly. >>> 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 section is not normative. You are not recommending invalid markup because user agents can ignore it, are you? > 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. You want to read that Working Draft for a change and stop citing it as anything other than work in progress. F'up2 ciwa.html PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: bruce on 3 May 2010 21:11 On May 3, 5:25 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Garrett Smith wrote: > > 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. > > You miss the point. January is the first month. If the first item of a > SELECT element is selected by default by the UA (there is no requirement for > that), then there is no problem with the date control showing 31 days. > > > The input will need server side validation. > > Yes, but that is beside the point. > > >>> 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. > > Read again. > > > Proper labeling of the fields can avoid ambiguity. > > Unambiguous text, too. > > >>> 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. > > You realize, of course, that with a single date control that will be all the > dates you have ever entered in that browser (unless limited history > alleviates that problem), provided the control's name is right. It might > turn out not to be so useful after all. > > > I also like to be able to copy paste values to and from the input. > > For *date* controls? Well, suit yourself, but it is arguably less > accessible and more ambiguous to let the user type in delimiters. > At least use three (or more) controls instead of just one. > > >>> 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. > > However, you cannot validate what you cannot tell from one another, so an > unambiguous date format is mandatory one way or the other. > > > The ISO-8601 format can be easily understood worldwide > > So can other date formats. > > > and, unlike other formats, it is standardized. > > Irrelevant. The worm must be tasty for the fish, not for the fisherman.. > We've been over this. > > >>> 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've been told already. > > > [...] > >>> 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. > > Exactly. > > >>> 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 section is not normative. You are not recommending invalid markup > because user agents can ignore it, are you? > > > 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. > > You want to read that Working Draft for a change and stop citing it as > anything other than work in progress. > > F'up2 ciwa.html > > PointedEars > -- > realism: HTML 4.01 Strict > evangelism: XHTML 1.0 Strict > madness: XHTML 1.1 as application/xhtml+xml > -- Bjoern Hoehrmann Okay, you have made this into a fantastic discussion, BUT, the solution as I request, is what I want. My code is for a scheduling system for the Tennis courts and the Cabana of my Homeowner's Association consisting of 200 families. My input page has 9 drop down boxes and a submit button. The date drop down boxes (Month, Day, Year) are preloaded with "Today's" date. The remaining drop down boxes are Start time and End time boxes are (Hour, Minutes, AM/PM). Start time is set to the current time. Minutes are (0, 15,30, 45) only. End time is set to 2 hours after the start time. These are loaded on the server using PHP. My validation is done on the Server using AJAX. If validation fails, an error message, via AJAX is returned. If validation passes, the data is stored in the database and a table with all reservations returned, again via AJAX. So, I reiterate may request. Can someone direct me to prototype that shows me how I can change the Day drop down box to the correct number of days when the month is selected. Thank you.... Bruce
From: David Mark on 3 May 2010 21:40 bruce wrote: [...] > > Okay, you have made this into a fantastic discussion, BUT, the > solution as I request, is what I want. My code is for a scheduling > system for the Tennis courts and the Cabana of my Homeowner's > Association consisting of 200 families. > > My input page has 9 drop down boxes and a submit button. The date drop > down boxes (Month, Day, Year) are preloaded with "Today's" date. The > remaining drop down boxes are Start time and End time boxes are (Hour, > Minutes, AM/PM). Start time is set to the current time. Minutes are > (0, 15,30, 45) only. End time is set to 2 hours after the start time. > These are loaded on the server using PHP. > > My validation is done on the Server using AJAX. If validation fails, > an error message, via AJAX is returned. If validation passes, the data > is stored in the database and a table with all reservations returned, > again via AJAX. > > So, I reiterate may request. Can someone direct me to prototype that > shows me how I can change the Day drop down box to the correct number > of days when the month is selected. > I don't know of any such prototype. but you should ask yourself if you should be fooling around with Ajax before you've learned how to do basic DOM manipulation (e.g. populating a SELECT control). I know that must sound harsh, but it is what you need to hear at this point. I highly recommend you write the initial version without script. Then, if it is really necessary, add some scripted enhancements as your present skills allow.
From: Garrett Smith on 4 May 2010 00:30 bruce wrote: > On May 3, 5:25 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> > wrote: >> Garrett Smith wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> Garrett Smith wrote: >>>>> bruce wrote: >>>>>> I have 3 dropdown boxes, Month, Day, Year. [snip massive overquote] [snip signature] > Okay, you have made this into a fantastic discussion, BUT, the > solution as I request, is what I want. My code is for a scheduling > system for the Tennis courts and the Cabana of my Homeowner's > Association consisting of 200 families. > Not a help desk. > My input page has 9 drop down boxes and a submit button. The date drop > down boxes (Month, Day, Year) are preloaded with "Today's" date. The > remaining drop down boxes are Start time and End time boxes are (Hour, > Minutes, AM/PM). Start time is set to the current time. Minutes are > (0, 15,30, 45) only. End time is set to 2 hours after the start time. > These are loaded on the server using PHP. > Nine select boxes. That's wonderful. > My validation is done on the Server using AJAX. And when that fails? Based on the question you are asking, you should not be attempting any Ajax. The technical solution to what you are asking is not all that hard. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 4 May 2010 00:38
Ben C wrote: > 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: [...] >>> But accept >>> 2010-05-03 >>> 2010-5-3 >>> 2010/5/3 >>> 2010.5.3 >>> as equally valid. (Unless you actively want to lose customers). >>> The other formats are nonstandard open to arbitrary interpretation. >>> 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. > Although I am guessing here, it might be considered a liability of the web site for providing an unauthorized credit card number that is not what the user entered, where the user may claim that he did not enter that number. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |