Re: [whatwg] Input type=date UI discussion
On Wed, 13 Jul 2005, Jim Ley wrote: I don't really know what Jim meant (his question isn't comprehensible English) but at a guess, if he was asking whether pressing Enter in a date field should cause submission, that is up to the UA, as is IMHO quite clearly stated in the spec: http://whatwg.org/specs/web-forms/current-work/#enter-submit Nope, this only talks about TEXT controls, it doesn't mention date controls, the phrase submitting a form implicitly isn't defined other than by the one example. Changed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Input type=date UI discussion
Brian Wilson wrote: Some possible user interface realizations (draft) of the date widget: Input type=date popup: http://people.opera.com/brian/testfiles/input-date-popup.png I'd reverse the month and year input elements. - Year numbers, Month labels and day numbers should be localized strings. - If a value attribute is present, and valid, when the popup is invoked, the year/month/day indicated will all be pre-set. The year field will have initial focus. Please, if you want to put focus to year first, put that element as first in the popup. If we take the draft screenshot above and go to year first, it's unintuitive to go leftwards once the user hits TAB. - Display format for the field does not match submittal format...what should it be? According to user's localization information. For UNIX, this would be the locale pointed by environment variable LC_TIME (unless overridden by LC_ALL). I think the C locale should match ISO-8601 format. - Should the left-most day of the week be Sunday or Monday? Is this a localization issue? It's a localization issue. I think it's Monday for everything else but en_US. Standard ISO week starts at Monday. - Possible addition: Two additional function buttons not mentioned in the WF2 specification could aid usability: Current (set the date to the current date), and Reset (reset the date to the field's value before popup was invoked). I'd relabel Current to Today. Current sounds like OK to me (set input date value to currently selected value). I think that the Today button has no use if there's some default value. I'd use following buttons: [Reset/Today] [Cancel] [OK] (reverse Cancel and OK if required by platform guidelines for confirm and cancel actions). If default value is not set, there should be Today button. If default value is set, the Today button should be replaced with Reset. 4.1 Pointing Device Actions - Clicking anywhere on the widget generates the date chooser popup. OK - Clicking outside the calendar popup dismisses the popup and uses the current values in the popup as the new date value. This isn't good. How do I cancel? At least, put OK and Cancel buttons in the popup. - If the date selected in the popup is not valid according to the field's constraints, the value will revert to the last valid value. So, if I select a day outside valid range, the value will be silently changed (that is, unless I check the text in input after the popup went away). Not good. 4.2 Key actions - The widget display is read-only. Except for the listed key behaviors below, the widget is unresponsive to key input. - TAB moves focus to and from the date widget. Focus is received from previous element in the tabindex order (or the previous focusable element in the document order.) Focus is sent to the next focusable element in the tabindex order (or the next focusable element in the document order). - ENTER: Invokes the date chooser popup ENTER submits the form in most input elements. If the date input element looks like a button and it has focus ring, I think using ENTER to activate the popup is OK. If it looks like a text input or drop down list, then ENTER should submit the form instead (assuming, of course, that ENTER submits in normal text input in this UA). - DOWN arrow: Invokes the date chooser popup - Key actions within the date chooser popup - Popup initial focus: Year field. - TAB key dismisses the popup and moves focus to the next element in tabindex or document order - CTRL-TAB key moves between yr/month/day regions of the popup, in that order - ESC key dismisses the popup and reverts the value to the value it had before popup invocation. Yeah, here's the CANCEL action I was looking before! I assume that ESC hits the invisible Cancel button? - ENTER key dismisses the popup using the current date settings. Again, the ENTER key activates the invisible default OK button. Not good. - Year has focus: UP/DOWN = next/previous year. LEFT/RIGHT = no effect - Month has focus: UP/DOWN = next/previous month. LEFT/RIGHT = no effect - Day has focus: RIGHT/LEFT/UP/DOWN = navigate on day grid - Ex. Case: Month field has focus, value=December, UP key= increase year by 1, set month to Jan, set day focus to 1. Month field still has focus - Ex. Case: Month field has focus, value=July, Day=31, UP key= increase month field by 1 (August), set day field to 1st. Please, make it possible to enter a date with following key combination. E.g. for today enter 2005-07-13 That is, once the popup has been opened, the focus is in year by default. I input 2005 to set the year, press - to change to next field (the - isn't a valid input for this field so it can be used to change to next field in addition to TAB key. Apply the same logic for characters [.:/,]. Repeat for month and day. Notice that I should be able
Re: [whatwg] Input type=date UI discussion
On Tue, 12 Jul 2005, Dean Edwards wrote: Jim wrote: It's not a text box, it's an input type=datetime (say), I'm asking is if that should act the same as a text box w.r.t. to enter submitting the form? I think that is what it says in the spec. Ian? I don't really know what Jim meant (his question isn't comprehensible English) but at a guess, if he was asking whether pressing Enter in a date field should cause submission, that is up to the UA, as is IMHO quite clearly stated in the spec: http://whatwg.org/specs/web-forms/current-work/#enter-submit The spec just makes sure to define the behaviour in the case where it does happen, without limiting the cases where it may happen. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Input type=date UI discussion
Mikko Rantalainen wrote: - Clicking outside the calendar popup dismisses the popup and uses the current values in the popup as the new date value. This isn't good. How do I cancel? At least, put OK and Cancel buttons in the popup. Look at how a select works. Clicking outside the popup closes the popup but does *not* change the value. -dean
Re: [whatwg] Input type=date UI discussion
Dean Edwards wrote: ... ** The Platform is Important ** We are taking this into serious consideration when building an IE implementation. Where possible we are trying to replicate the look and feel of Windows. That's very good news. ... - Popup date chooser appearance: Days not in the current month on the day grid should be either an alternate color or grayed out to aid visual differentiation. We don't display them. Should we? The native version does. See the Date-Picker section of http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch08c.asp. Typing a date should be quicker than opening the calendar, in which case a major reason (perhaps the main reason) for opening the calendar would be *because* you want to correlate dates with days. ... in the input date widget. This value is not free-form editable. I disagree quite strongly with this. If we want to enable developers to build web applications then rapid data-entry is a must. I'd like to try to validate keyboard entry. Mikko Rantalainen's comments were spot on here -- typing 2005-07-14 or 2005/7/14 should Just Work (or equivalent depending on the order of date elements in your Regional Settings, if possible). ... - If the date selected in the popup is not valid according to the field's constraints, the value will revert to the last valid value. We will probably disallow the selection of invalid dates. Probably grey out the dates that are out of step or out of range. Good. ... - DOWN arrow: Invokes the date chooser popup Yes. That conflicts with the (IMO much more useful) behavior mentioned later: ... - Year has focus: UP/DOWN = next/previous year. LEFT/RIGHT = no effect - Month has focus: UP/DOWN = next/previous month. LEFT/RIGHT = no effect - Day has focus: RIGHT/LEFT/UP/DOWN = navigate on day grid - Ex. Case: Month field has focus, value=December, UP key= increase year by 1, set month to Jan, set day focus to 1. Month field still has focus If you really want to open the popup with the keyboard, you can use the spacebar. (As I mentioned above, the main reason you should want to do this with the keyboard is to look at what days fall on which dates, not for actual selection.) ... 6. Issues - - Look/Feel: Should popup have a Current date button? - Look/Feel: Should popup have a Reset button? Clutter we decided but it may fit in better with the design you have. Text fields, menus, radiobuttons etc don't have Reset buttons, so I don't see why a datepicker should. But text fields do have a shortcut menu with Undo as its first item. ... What side is th dropdown button on in Japan? Seriously, I want to know. :-) The right http://images.google.com/images?q=combo.box%20site%3Ajp. It should be on the left in Arabic locales, though http://www.jasonbock.net/JB/Images/ComboBoxArabicText.jpg. -- Matthew Thomas http://mpt.net.nz/
Re: [whatwg] Input type=date UI discussion
On 7/13/05, Dean Edwards [EMAIL PROTECTED] wrote: Matthew Thomas wrote: Dean Edwards wrote: We don't display them. Should we? The native version does. See the Date-Picker section of http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch08c.asp. OK. We'll show them greyed out. But please don't make us show the today squiggly.. :DG
Re: [whatwg] Input type=date UI discussion
On Thu, 14 Jul 2005, Matthew Thomas wrote: If you really want to open the popup with the keyboard, you can use the spacebar. (As I mentioned above, the main reason you should want to do this with the keyboard is to look at what days fall on which dates, not for actual selection.) There are various other keys that open the dropdown on Windows, notably Alt+Down, Alt+Up, and F4, all three of which toggle the state of a combo box dropdown. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Input type=date UI discussion
Jim Ley wrote: For example does my user agent which submits form purely under programmitic control with no user keyboard action required to fire the click event or not? I'd say that was submitting the form implicitly more so than pressing enter in a text field. I think the intention of the spec is that a form must always be submitted by a specific button. So if your UI allows you to submit a form e.g. by clapping your hands once, the onclick event is still fired on the default button and the name=value of the button is still submitted. Olav Junker Kjær
Re: [whatwg] Input type=date UI discussion
Dean Edwards wrote: - Date widget appearance: Once the date chooser popup widget has been dismissed, the date in its correct localized format will be displayed I agree but localisation is hard for us. I'm not sure how we are doing that yet. Olav? Thats the easy part. Using the built-in toLocaleDateString() method on the Date object, we get the date in unambiguous localized format (month names spelled out). The hard part is parsing free-form date input, since the localization is not reversible - the built-in parse method don't support parsing the localized format. Therefore we are probably going to support only numeric date input (like 7-8-2005), parsed based on localization settings. Since the user might be unsure what format to enter the date in, it's important with the date picker (so you can pick a date without typing), and with the unambigous localized feedback. I agree that free-form input is quite nice, eg. if you have to enter your own birth date, its much faster to type than to pick. - Should the left-most day of the week be Sunday or Monday? Is this a localization issue? Yes it is. Should depend on the users locale. (This might be a bit tricky to show if a calendar is used for picking a week, since ISO weeks always start monday.) /Olav
Re: [whatwg] Input type=date UI discussion
Olav Junker Kjær wrote: I agree that free-form input is quite nice, eg. if you have to enter your own birth date, its much faster to type than to pick. I really would like to see date widgets allow direct keyboard entry. It's a very important feature for data entry systems. -dean
Re: [whatwg] Input type=date UI discussion
On 7/12/05, Dean Edwards [EMAIL PROTECTED] wrote: Jim Ley wrote: On 7/12/05, Dean Edwards [EMAIL PROTECTED] wrote: Well the customisation is just colours and chrome style. We'll attempt to guess the chrome style and replicate it. What I really mean is that we are copying the windows controls in terms of layout and the way they respond to keyboard/mouse events. There is no consistent response to keyboard and mouse events in windows, it's customisable. Please do not make the mistake that Mozilla made for the first 2 years of its life where its menus were unusable on windows if they'd changed the mouse configuration. Windows window manager customisation is not just look. You should either use the windows common controls, or you should have something that cannot be confused for the normal controls. Yeah. We are copying the windows common controls. As I say, please use them, or doing something different, copying something and getting it only 90% right (which is all that is practical as if you're doing this with zero install, that's all you have access to) then it's worse than being completely different. I said anything *in* the popup window. Yes, I understand that, I fail to see why a popup month view should not be usable by the assistive technologies, and more importantly how will you know what assistive technologies are being used? I'll say again AIUI, certain input modes and screen reading type things require a window to have focus to work. This is just my understanding, but I'm reasonably confident of it. The WF2 controls for IE will all be operable by keyboard. Think of a select box. The individual options are not focusable but they are navigable. The control has focus, just like in windows, the common date control gains focus. So Enter in a text box should submit a form, the same as if it was an input type=text? Is this in the spec? What are you asking? A text box should behave like a text box? It's not a text box, it's an input type=datetime (say), I'm asking is if that should act the same as a text box w.r.t. to enter submitting the form? Jim.
