Re: [whatwg] input type=number for year input
On Thu, Feb 20, 2014 at 9:19 PM, Jonathan Watt jw...@jwatt.org wrote: For what it's worth I just tried the following in Chrome, and if I type in 12,34 then increment using the spinner it resets to zero, seeming to indicate that the , was rejected. Is that expected? data:text/html,input type=number step=0.01 lang=fr It's expected. Form controls in Google Chrome doesn't respect lang attribute for now. Form controls are always localized for browser's UI locale. We accepted entering grouping separators in the past. But we stopped it because users had to know their locale correctly. e.g. 1,234 has different meaning in French locale and English locale if we support grouping separators. So essentially you assume any separator that is a decimal separator in any locale is a decimal separator all cases? Even that approach would seem to have the potential for unexpected results for users; for example, a user types in 1,234 meaning 1234 but the input takes the value 1.234. Or maybe I misunderstand? You're right. Such confusion can happen even in WebKit/Blink implementation. However, it's much better than accepting both of grouping separator and decimal separator IMO. -- TAMURA, Kent Software Engineer, Google
Re: [whatwg] input type=number for year input
Hi, The current WebKit/Blink behavior is: - Accept both of the ASCII digits and localized digits - Accept both of the standard decimal point '.' and a localized decimal point - Not accept grouping separators and don't show grouping separators We showed grouping separators in the past. But we stopped it because grouping separators disturb some use cases. We accepted entering grouping separators in the past. But we stopped it because users had to know their locale correctly. e.g. 1,234 has different meaning in French locale and English locale if we support grouping separators. On Wed, Feb 19, 2014 at 8:09 AM, Jonathan Watt jw...@jwatt.org wrote: When implementing input type=number for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as 1,234. This is causing a problem for at least media wiki, because they use input type=number for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIXaction=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators. -- TAMURA, Kent Software Engineer, Google
Re: [whatwg] Forms-related feedback
I know I'm proposing a strange thing. Some use-cases are just workarounds and there are ideal solutions. On Tue, Sep 24, 2013 at 5:35 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 21 Aug 2013, TAMURA, Kent wrote: On Sat, Jul 13, 2013 at 6:39 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 Jan 2013, TAMURA, Kent wrote: On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Sep 2012, TAMURA, Kent wrote: * For date, datetime, datetime-local, month, time, week, the attribute returns a string in a field. If a field is text-editable, it should return user-editing string like email and number. If a field has a fixed localized date/time string chosen by a date/time picker, the attribute should return the localized string. [...] - We can enable text field selection APIs for email, number, and other types How would this work when the control isn't a text control? I don't understand. For example, consider a date control that is actually three separate text fields (year month day); how do you envisage the selection API working and how would rawValue help with this? I think it's ok that rawValue doesn't work with form controls without any text. One of use cases of rawValue would be to handle user input errors. I think non-text form controls should be clever enough to avoid bad user input. For example, users can't set bad values to input[type=range]. I still don't understand how this would work. You suggest that it should work for type=date, but how? What happens when it's mutated by script, for instance? I really don't understand the purpose here or how it would work to achieve that purpose. As for type=date, rawValue should return what a user see. What if the user sees a calendar with a date circled? Or the string your birthday? (Exposing that would be a privacy violation.) Or what if the user doesn't see anything (because it's not a visual UA), but every time the user focuses it, the user agent plays a tune from one of Vivaldi's four seasons, followed by a trill to indicate how far into the season the date is? I have no good idea for them. However I don't think UA provides some of such UIs. The specification allows to implement any UI for form controls, but web authors won't accept UIs which are drastically different from existing implementations. For example, existing implementations of input[type=date] have about 1-line height by default. If a UA provided an inline-calendar-style implementation and it requires 300px height, web authors would have a hard time to design their pages. Value set by script or not doesn't matter. I mean, how would the user agent parse the script's new value. It's implementation-specific even now, and unrelated to this proposal. I saw some questions/requests of a way to get a localized date string in crbug.com and stackoverflow.com. One of reasons one wanted to get it was that there are no ways for script to get localized date format used in type=date. One wanted to get the format to use consistent date format in a web page, another wanted to get the format to focus on specific field in type=date (Note that a type=date instance in Google Chrome contains multiple focus targets.) Providing localisation is definitely something we should do, but rawValue isn't a sane way to do it. You don't want to have the format a date API be create an input element, sets its value, and read it back. Yeah, this usecase is for a workaround. We don't need rawValue if we have a formal way to set/get date formats. As for type=number, I heard a web author wanted to get invalid value typed by a user in order to show friendly error message without HTML interactive form validation. The point of type=number is that the browser can do this, no need to reimplement it. (If an author does want to reimplement it, Web Components are presumably the long-term solution: reimplement the widget.) I don't think Web Components becomes widely available in 10 years. Web authors want to replace UA-builtin form validation UI now. Do you think web authors should not use new input types if they don't like builtin form validation UI? On Tue, 11 Sep 2012, TAMURA, Kent wrote: Yes, I'd like to enable selection API for at least type=email and type=number. All of their existing implementations are text fields. I haven't seen a request to suport selection API for type=email, etc.. However lack of selection API looks a defect to me. Why does the page need to touch the selection? It must be same as input[type=text]. e.g. - A page author wants to select the whole value or nothing of an email form control when it gets focus. Why is that a valid thing for a page to be doing? The browser should take care of doing that, not the page. If the page does it, it'll be different on each page and the user will get confused. We can't force it. Web authors do what
Re: [whatwg] Forms-related feedback
On Sat, Jul 13, 2013 at 6:39 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 Jan 2013, TAMURA, Kent wrote: On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Sep 2012, TAMURA, Kent wrote: * For date, datetime, datetime-local, month, time, week, the attribute returns a string in a field. If a field is text-editable, it should return user-editing string like email and number. If a field has a fixed localized date/time string chosen by a date/time picker, the attribute should return the localized string. [...] - We can enable text field selection APIs for email, number, and other types How would this work when the control isn't a text control? I don't understand. For example, consider a date control that is actually three separate text fields (year month day); how do you envisage the selection API working and how would rawValue help with this? I think it's ok that rawValue doesn't work with form controls without any text. One of use cases of rawValue would be to handle user input errors. I think non-text form controls should be clever enough to avoid bad user input. For example, users can't set bad values to input[type=range]. I still don't understand how this would work. You suggest that it should work for type=date, but how? What happens when it's mutated by script, for instance? I really don't understand the purpose here or how it would work to achieve that purpose. As for type=date, rawValue should return what a user see. Value set by script or not doesn't matter. In Google Chrome, rawValue should return a localized date value such as 21/08/2013. I saw some questions/requests of a way to get a localized date string in crbug.com and stackoverflow.com. One of reasons one wanted to get it was that there are no ways for script to get localized date format used in type=date. One wanted to get the format to use consistent date format in a web page, another wanted to get the format to focus on specific field in type=date (Note that a type=date instance in Google Chrome contains multiple focus targets.) As for type=number, I heard a web author wanted to get invalid value typed by a user in order to show friendly error message without HTML interactive form validation. On Tue, 11 Sep 2012, TAMURA, Kent wrote: Yes, I'd like to enable selection API for at least type=email and type=number. All of their existing implementations are text fields. I haven't seen a request to suport selection API for type=email, etc.. However lack of selection API looks a defect to me. Why does the page need to touch the selection? It must be same as input[type=text]. e.g. - A page author wants to select the whole value or nothing of an email form control when it gets focus. Why is that a valid thing for a page to be doing? The browser should take care of doing that, not the page. If the page does it, it'll be different on each page and the user will get confused. We can't force it. Web authors do what they want. https://code.google.com/p/chromium/issues/detail?id=263910#c3 This is an actual case. I talked with him, and he said datalist didn't work in his case because he wanted to show images on choices. - A user entered an email address with unacceptable domain name. A page author wants to move the caret to the beginning of the domain name. How is that possible in the case of a custom e-mail widget where the e-mail address isn't shown, but a user picture and name is shown instead? I think rawValue isn't necessary in such UI. However all of existing type=email implementation is a text field. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Forms-related feedback
On Mon, Jan 14, 2013 at 2:19 AM, Ian Hickson i...@hixie.ch wrote: On Sun, 13 Jan 2013, TAMURA, Kent wrote: So, I think it's impossible for us to build reasonable UI for type=datetime. It should be removed from the specification. In the simplest case, the UI for type=datetime doesn't need to be different from the UI for type=datetime-local. Any differences, IMHO, would be just accessible from (e.g.) a context menu (to allow the user to actually pick a time zone). Google Calendar's event editor page has a pretty good type=datetime widget (though in their case it has two widgets combined into one, for start and end). I don't think it works well because of daylight saving time. * If the type=datetime UI asks a UTC datetime, type=datetime-local is enough and type=datetime is unnecessary. * If the type=datetime UI asks a local datetime, UA needs to convert local datetime to UTC datetime, of course. However, it's very hard to implement. ** The UI needs extra work for edge cases of daylight saving time - standard time switching. ** A local computer doesn't have complete information of daylight saving time period of every year. * If the type=datetime UI asks a datetime and a timezone offset value, many users don't understand it. The Google Calendar's UI is equivalent to type=datetime-local with an optional timezone selector. I don't know how Google Calendar handles future changes of daylight saving time period. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Forms-related feedback
On Tue, Jan 8, 2013 at 9:47 AM, Ian Hickson i...@hixie.ch wrote: However, I'm not sure how this can be presented to the user. In the example above I suggested that time input UI should be accompanied with local time zone (Europe/Helsinki in my example). However, that would suggest that this info would be transferred to the server and that the server is expected to follow political time zone changes to that timezone. The user could be assuming that he has defined a specific time in a specific timezone (an absolute time as far has he knows). In the reality, the server would like to transfer *the responsibility* for the possible future time zone changes to the user -- the server expects user to come by and modify the absolute time in case the user local timezone has been modified since entering this absolute time. I have absolutely no idea how on earth this could be explained to casual user. And even if it could be explained, I'm pretty sure the end user wouldn't be happy with that responsibility. Yeah. Indeed. The next best choice would be to have datetime-with-timezone but unfortunately (1) Official database for all timezones does not exist (2) Official timezone names (or labels) do not exist (3) Timezones are subject to future political decisions The problems (1) and (2) make transferring the timezone information from the end user to the server very problematic and the problem (3) makes any work to fix (1) and (2) a bit pointless. This is because even if UA could successfully inform the server about the correct timezone, the server could be using a week old timezone data that is not up to the latest political events. Or the server might be using latest timezone data but the UA could be using three year old data. In either case, the absolute time in UTC could be different for the server and UA. Indeed. So, I think it's impossible for us to build reasonable UI for type=datetime. It should be removed from the specification. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] 'datetime-local' and 'datetime' comments
On Thu, Nov 22, 2012 at 2:15 PM, Ian Hickson i...@hixie.ch wrote: What do you think would be a good UI? Does something that would allow selecting a date/time in the current user's TZ and then have the information sent to the server in UTC would be a good UI? That would probably be a reasonable first UI. A more mature UI would also let you pick the time for a specific other time zone (e.g. because you know you'll be there), or compare multiple time zones at the same time to pick a time convenient for multiple people, etc. I have made some UI ideas, but I still have no reasonable one. It's very hard because there are various levels of user knowledge and local computer knowledge. User-A: He doesn't know there are multiple timezones in the world. User-B: He knows there are multiple timezones, and doesn't know his timezone offset. User-C: He knows there are two timezone offsets in his region; the standard time and the daylight saving time. User-D: He knows the start date and the end date of the daylight saving time. User-E: He knows there is an invalid time and ambiguous time when we switch between the standard time and the daylight saving time. Note: 2012-03-11 2:30 a.m. didn't exist in USA, and there were two 2012-11-04 1:30 a.m. User-F: He knows timezone offsets of the standard time and the daylight saving time. Computer-A: It doesn't know its local timezone offset. Computer-B: It knows its local timezone offset. Computer-C: It knows the start date and the end date of the daylight saving time according to the latest law about the daylight saving time. Computer-D: It knows them for the past years too even if the law was changed. Computer-E: It knows them for the future years too! If UI depended on a local timezone, we would need Computer-E and extra handling for invalid/ambiguous time. If UI was independent from a local timezone, only User-D/E/F could use it. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] 'datetime-local' and 'datetime' comments
I think I can do it for WebKit if WHATWG specification and W3C specification are changed so. On Thu, Nov 15, 2012 at 2:23 AM, Mounir Lamouri mou...@lamouri.fr wrote: On 13/11/12 09:42, TAMURA, Kent wrote: The current UI implementations of Opera, iOS, and Chrome-Android spoil the HTML standard. Web authors hardly have motivation to use type=datetime. They can add 'UTC' text, and their code can append 'Z' to values easily. I agree that the type names are not good. People must think type=datetime is a combination of type=date and type=time. It's not too late to rename datetime-local to datetime because the number of type=datetime or type=datetime-local in the Web is terribly smaller than the number of type=date. Tamura, do you think Webkit/Chrome can do this change? Gecko/Mozilla would be willing to implement 'datetime' that way and not implement 'datetime-local' but having other vendors committed to this change would be helpful and prevent us from going alone in this path. Cheers, -- Mounir -- TAMURA Kent Software Engineer, Google
Re: [whatwg] 'datetime-local' and 'datetime' comments
The current UI implementations of Opera, iOS, and Chrome-Android spoil the HTML standard. Web authors hardly have motivation to use type=datetime. They can add 'UTC' text, and their code can append 'Z' to values easily. I agree that the type names are not good. People must think type=datetime is a combination of type=date and type=time. It's not too late to rename datetime-local to datetime because the number of type=datetime or type=datetime-local in the Web is terribly smaller than the number of type=date. On Tue, Nov 13, 2012 at 2:00 AM, Mounir Lamouri mou...@lamouri.fr wrote: Hi, We've been working on implementing date and time input types attributes at Mozilla this summer and we found out that 'datetime-local' and 'datetime' have a quite odd behaviour. 'date' and 'time' are both timezone agnostic types: you just set a time and date and we assume that it is relative to something. So, it seems somewhat natural to assume that 'datetime' would be simply those types added to each other. Instead of that, 'datetime' has a notion of timezone and 'datetime-local' is the timezone agnostic type. In addition of being more intuitive, it seems that a huge majority of date/time usage are timezone agnostics because, usually, the timezone is implicit. For example, booking flight/train tickets. There is however some use cases I can think of, like scheduling a meeting, where, sometimes, you might want to mess with timezones. But those are quite rare. Furthermore, there are currently two implementations for 'datetime' and 'datetime-local' I can think of: - Opera: 'datetime' is like 'datetime-local' except that there is a greyed 'UTC' text next to the datetime picker; - Chrome Android: 'datetime' is exactly like 'datetime-local'. I haven't checked what is actually sent when the form is submitted by those implementations. Last but not least, I have never seen any [good and simple] UI allowing me to pick a date and time in a specific time zone. As far as I know, there are no native UI for those things even on mobile where there are UI for date and time pickers. As a conclusion, given the lack of good UI and good implementations, I think we should change the behaviour of 'datetime' to match the behaviour of 'datetime-local' so developers don't use the former and falsely expect the behaviour of the later. Also, I would suggest that we remove 'datetime-local' from the specifications. If later if find out that we really need a date-time picker that is not timezone agnostic, we could add something. For the moment, given the state of the implementations and the very tiny use cases that could solve, I think having this type would hurt more than help. Thanks, -- Mounir -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Incomplete user-input in some input types
A. In such case, make input.validity.typeMismatch true, or B. Introduce new IDL attribute to ValidityState. input.validity.invalidUserInput? C. Just validity.valid becomes false. An implementation would have an internal flag like invalidUserInput, but it won't be exposed via IDL. C would have less impact to the standard. If no one has concern about this idea, I'd like to implement C in WebKit. On Thu, Sep 13, 2012 at 3:18 PM, TAMURA, Kent tk...@chromium.org wrote: Proposal: Making an input element invalid state if the input has an invalid string specified by a user with browser UI. An invalid string means a string which doesn't match to a required format defined by a type. e.g. If a user typed - to input[type=number], input.validity.valid would be false and form submission would be prevented. A. In such case, make input.validity.typeMismatch true, or B. Introduce new IDL attribute to ValidityState. input.validity.invalidUserInput? This behavior should be applied to the following types: number, color, date, datetime, datettime-local, month, time, and week Background: If an input type is implemented as a text field, it is very hard for UA to reject invalid strings for the type. For example, - is not a valid floating-point number, but UA can't prevent users from typing -. So the field can contain invalid strings though its value IDL attribute is empty. If a user tries to submit the form in such situation, the field is valid unless the required attribute is specified. WebKit clears the invalid string when the field loses focus or the form is submitted. A sanitized value (empty string) is submitted. Opera doesn't clear the invalid string. It silently submits a sanitized value (empty string). IE10 has a behavior similar to WebKit. However if a user type -1abc, -1abc is submitted. I don't like clearing user input. It's not a good user experience. Users don't expect their input strings are cleared by UA. Also, I don't like submitting empty value silently. Users expect their input strings are submitted. I think the best UI is to notify users about a field has an invalid string, and give a chance to correct it. Applying the standard form validation mechanism must be reasonable. -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google
[whatwg] Incomplete user-input in some input types
Proposal: Making an input element invalid state if the input has an invalid string specified by a user with browser UI. An invalid string means a string which doesn't match to a required format defined by a type. e.g. If a user typed - to input[type=number], input.validity.valid would be false and form submission would be prevented. A. In such case, make input.validity.typeMismatch true, or B. Introduce new IDL attribute to ValidityState. input.validity.invalidUserInput? This behavior should be applied to the following types: number, color, date, datetime, datettime-local, month, time, and week Background: If an input type is implemented as a text field, it is very hard for UA to reject invalid strings for the type. For example, - is not a valid floating-point number, but UA can't prevent users from typing -. So the field can contain invalid strings though its value IDL attribute is empty. If a user tries to submit the form in such situation, the field is valid unless the required attribute is specified. WebKit clears the invalid string when the field loses focus or the form is submitted. A sanitized value (empty string) is submitted. Opera doesn't clear the invalid string. It silently submits a sanitized value (empty string). IE10 has a behavior similar to WebKit. However if a user type -1abc, -1abc is submitted. I don't like clearing user input. It's not a good user experience. Users don't expect their input strings are cleared by UA. Also, I don't like submitting empty value silently. Users expect their input strings are submitted. I think the best UI is to notify users about a field has an invalid string, and give a chance to correct it. Applying the standard form validation mechanism must be reasonable. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Exposing visible string of an input field
I'd like to propose adding new IDL attribute to HTMLInputElement. readonly attribute DOMString rawValue; If I understand the main use case correctly. This probably should be called displayValue or something. Yeah, displayValue sounds better. What about type=file ? IMO, the IDL attribute should work only with input types of which value mode is value. Value mode of input[type=file] is filename, so empty string should be returned. - We can enable text field selection APIs for email, number, and other types So you want to enable select() etc. for these types? Are there real needs here? Yes, I'd like to enable selection API for at least type=email and type=number. All of their existing implementations are text fields. I haven't seen a request to suport selection API for type=email, etc.. However lack of selection API looks a defect to me. - JavaScript-based screen readers can read user-visible content of input fields. For localized strings (date, datetime, datetime-local, month, time, week), it doesn't seem to be difficult to hard-code the string conversion functions into a JavaScript screen reader. For inputs that are being edited (date, datetime, datetime-local, month, time, week, number), I wonder if we should instead remove restrictions like this: # User agents must not allow the user to set the value to a non-empty # string that is not a valid floating-point number. and just let .value returns the raw input while a user is editing the value and let value sanitization algorithm happen afterward. It doesn't work for type=email. Suppose an email field has root@グーグル.com as a display value. A screen reader reads it as r...@xn--qcka1pmc.com because HTMLInputElement::value returns a sanitized string. -- TAMURA Kent Software Engineer, Google
[whatwg] Exposing visible string of an input field
Proposal: I'd like to propose adding new IDL attribute to HTMLInputElement. readonly attribute DOMString rawValue; It returns text content which a user actually see in an input field. * For text, search, url, tel, password types, it's equivalent to 'value' IDL attribute. * For email type, it returns a string which a user is editing. It means it returns a string without Unicode - Punycode conversion and without normalization of whitespace and commas. * For number type, it returns user-editing string. If a user typed '123+++' into a number field, rawValue would be '123+++' as is. * For date, datetime, datetime-local, month, time, week, the attribute returns a string in a field. If a field is text-editable, it should return user-editing string like email and number. If a field has a fixed localized date/time string chosen by a date/time picker, the attribute should return the localized string. * For submit, reset, button types, the attribute returns a label which the field shows. e.g. 'Submit' for input type=submit without value attribute. * For other types, should it return an empty string? Use case: - We can enable text field selection APIs for email, number, and other types - JavaScript-based screen readers can read user-visible content of input fields. Strings returned by rawValue attribute may be browser-dependent and locale-dependent. However it would be useful. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Localization on script level and non form field
Form control presentations and ECMA Globalization API should be synchronized. We might need HTMLInputElement::numberFormat to set/get a Globalization.NumberFormat object. http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts -- TAMURA Kent Software Engineer, Google
[whatwg] Placeholder visibility on focus
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string and the control is not focused (e.g. by displaying it inside a blank unfocused control). I'd like to propose to change this part so that we allow UAs to show placeholder text even if the control is focused. * This behavior might depend on platforms. The password field of Windows 7 logon screen shows placeholder text when the field is focused. * autofocus + placeholder is useless in the current specification. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Constraint validation feedback (various threads)
On Thu, Mar 24, 2011 at 13:37, Koji Ishii kojii...@gluesoft.co.jp wrote: Does that cover the case where multiple characters can be composed to single character? I'm thinking the case where undetermined text in CJK input methods tends to be longer and may be shortened once determined, but there may be more cases where text gets shorter as you type. Ishii-san, It's not related to this thread. Anyway, do you have any concern about the behaviors of the current browsers? -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Constraint validation feedback (various threads)
Ok. It seems the best solution is to just remove the suffering from being too long state and simply require that authors not let authors enter values longer than the maxlength. Right? I agree removing tooLong validity. Google Chrome 10 has the interactive validation, and is causing some compatibility issues about maxlength. http://www.google.com/support/forum/p/Chrome/thread?tid=4f612fe2abafc365hl=en -- TAMURA Kent Software Engineer, Google
Re: [whatwg] input type=number without keyboard editing
Thank you for many comments on this topic. I understand the team can use select or input type=range, and the team is actually using input type=range instead of input type=number for now. I'm not sure if the requirements of the team are common. But I'm afraid that type=number implementations for the current specification can't satisfy requirements of actual Web application UI and type=number won't be used widely. On Mon, Nov 1, 2010 at 11:31, TAMURA, Kent tk...@chromium.org wrote: A team in Google tried to use input type=number for a product, and they decided not to use it. What they needed was a control to select an integer from a specific integer range such as 1 - 16. The number type control in Opera and WebKit allow a user to input out-of-range value even if the control has min=1 and max=16 attributes. It's not a good UI and the reason why they doesn't use type=number. They need a number control which - doesn't allow any keyboard / cutpaste operations and So, a text field part is read-only, but the spin-buttons work. - always has a valid value. required by default, and sanitization algorithm may be different. I'm not sure how to solve this issue. Introducing new content attribute or another number type? -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google
Re: [whatwg] input type=number without keyboard editing
On Tue, Nov 2, 2010 at 05:50, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Sun, Oct 31, 2010 at 10:31 PM, TAMURA, Kent tk...@chromium.org wrote: The number type control in Opera and WebKit allow a user to input out-of-range value even if the control has min=1 and max=16 attributes. It's not a good UI and the reason why they doesn't use type=number. Realistically, anyone who uses most of the HTML5 form features (so excluding autofocus, placeholder, and some others) will have to blacklist Opera and WebKit until they shape up. This isn't a problem with the spec, it's a problem with their current implementation quality. Hopefully Firefox 4 will drive some adoption and provide an impetus for Opera and WebKit to improve. Do you have any idea of improved UI with the perfect conformance? -- TAMURA Kent Software Engineer, Google
[whatwg] input type=number without keyboard editing
A team in Google tried to use input type=number for a product, and they decided not to use it. What they needed was a control to select an integer from a specific integer range such as 1 - 16. The number type control in Opera and WebKit allow a user to input out-of-range value even if the control has min=1 and max=16 attributes. It's not a good UI and the reason why they doesn't use type=number. They need a number control which - doesn't allow any keyboard / cutpaste operations and So, a text field part is read-only, but the spin-buttons work. - always has a valid value. required by default, and sanitization algorithm may be different. I'm not sure how to solve this issue. Introducing new content attribute or another number type? -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Form validation against invisible controls
The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 The bug there is that Chrome is filling in a control that isn't visible, and, even worse, that it is filling it with a value that the user couldn't himself enter manually. That's a bug (two bugs in fact), but it has nothing to do with reporting validation errors -- the error should not be able to occur. Please look at the original report and Comment #4. It is not an auto-fill issue. Comment #2 is an auto-fill bug and it was moved to another bug entry. Regardless of the auto-fill bug, we still have compatibility issues and we can't force authors to update their web pages. I'm wondering UA should show a dialog with The web page has invisible invalid form fields. Do you want to submit the form? [Yes] [No]. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Input color state: type mismatch
Please see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-July/027243.html In short words, I disagree with the current spec. On Wed, Jul 28, 2010 at 08:45, Ian Hickson i...@hixie.ch wrote: On Mon, 5 Apr 2010, TAMURA, Kent wrote: On Sat, Apr 3, 2010 at 06:37, Ian Hickson i...@hixie.ch wrote: On Sat, 3 Apr 2010, TAMURA, Kent wrote: I found type=number also had no typeMismatch. If a user wants to type a negative value, he types '-' first. This state should make typeMismatch true because '-' is not a valid floating point number. The user agent shouldn't update the value until the input is a valid number. (User agents must not allow the user to set the value to a string that is not a valid floating point number.) Why are type=email and url different from type=number at this point? Mostly because numbers are simpler, so it seemed less useful to expose half-entered numbers to the script. However, if people disagree with this I'm happy to change it so that those three work the same. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- TAMURA Kent Software Engineer, Google
[whatwg] typeMismatch for type=number (Re: Input color state: type mismatch)
On Sat, Apr 3, 2010 at 06:37, Ian Hickson i...@hixie.ch wrote: On Sat, 3 Apr 2010, TAMURA, Kent wrote: I found type=number also had no typeMismatch. If a user wants to type a negative value, he types '-' first. This state should make typeMismatch true because '-' is not a valid floating point number. The user agent shouldn't update the value until the input is a valid number. (User agents must not allow the user to set the value to a string that is not a valid floating point number.) I don't accept this behavior. Suppose that a user type - to an empty input type=number, then press ENTER to submit the form. As per the current specification, UA should send an empty value for the number control even though the number control has a visible string. The user doesn't expect a value different from the visible value is sent. This is very confusing. In such case, UA should prevent the form submission and show a validation message for typeCheck. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Form validation against invisible controls
There are some objections against omitting invisible controls from form validation. However, it is a real issue with existing sites and users can't submit such forms at all though they can submit it with non-HTML5 browsers. My conclusion is it's better to disable interactive form validation for existing sites as possible. e.g. disabling interactive form validation for documents without !DOCTYPE html. On Fri, Jun 4, 2010 at 00:16, TAMURA, Kent tk...@chromium.org wrote: An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google
[whatwg] Form validation against invisible controls
An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Form validation against invisible controls
Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being renderedrendering.html#being-rendered (e.g. it has the hidden editing.html#the-hidden-attribute attribute set) then user agents may report a script error. This sentence is about process against controls of which validation result is invalid. I think UA doesn't need to validate such controls. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 2010/6/4 TAMURA, Kent tk...@chromium.org An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.) I'd like to propose to add another condition: 7. it is visible (computed 'display' property of CSS isn't 'none' and no 'hidden' content attribute) I couldn't find exceptional rules for validating invisible controls in the current draft. Chrome 5 was released with a part of interactive validation, and we received a bug report about validation against invisible form controls. -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Type Date
On Fri, May 7, 2010 at 06:41, Garrett Smith dhtmlkitc...@gmail.com wrote: Opera has native support that mostly works but failed with dates prior to 1582, last I checked. This seems reasonable. Gregorian calendar started in 1582. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Input color state: type mismatch
On Sat, Apr 3, 2010 at 06:37, Ian Hickson i...@hixie.ch wrote: On Sat, 3 Apr 2010, TAMURA, Kent wrote: I found type=number also had no typeMismatch. If a user wants to type a negative value, he types '-' first. This state should make typeMismatch true because '-' is not a valid floating point number. The user agent shouldn't update the value until the input is a valid number. (User agents must not allow the user to set the value to a string that is not a valid floating point number.) Why are type=email and url different from type=number at this point? -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Input color state: type mismatch
I found type=number also had no typeMismatch. If a user wants to type a negative value, he types '-' first. This state should make typeMismatch true because '-' is not a valid floating point number. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Input color state: type mismatch
By the way, it looks like WebKit has implemented type mismatch for color state [1] [2]. Yes. That's because the type=color implementation of WebKit is just a text field for now. Users can specify invalid strings. When we complete the implementation of dedicated UI and value sanitization, typeMismatch won't be true. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] :valid / :invalid only works in forms
I agree with Erik. It's useful if the pseudo classes work without a form element and name attribute. input element is often used without a form element in web applications. A related topic: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#definitions http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#definitions Note: An element can still suffer from these states even when the element is disabled; thus these states can be represented in the DOM even if validating the form during submission wouldn't indicate a problem to the user. This paragraph mentions only disabled. But it means ValidityState also works without a form element, without a name attribute, or with a readonly attribute, right? An element is a candidate for constraint validation if 1. it is a validatable type, e.g. true if input type=number, false if input type=reset 2. has no disabled attribute, 3. has no readonly attribute, 4. inside of a form element, 5. has non-empty name attribute, and 6. not inside of a datalist element. I hope ValidityState and the pseudo classes ignores 2-6. On Sat, Feb 13, 2010 at 02:56, Erik Arvidsson a...@chromium.org wrote: At the moment an input element needs to part of a form and have a name attribute for the CSS pseudo classes :valid and :invalid to be applied. [1] These limitations forces people to make their DOM more complicated just to be able to use these pseudo classes. It might have made sense to have these limitations in a world where JavaScript was not available but in many modern web apps there is no need for forms nor name attributes. Can we please remove these limitations? Erik Arvidsson [1] https://bugs.webkit.org/show_bug.cgi?id=34733#c7 (included below for completeness) http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#association-of-controls-and-forms Constraint validation: If an element has no form owner, it is barred from constraint validation. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#naming-form-controls Constraint validation: If an element does not have a name attribute specified, or its name attribute's value is the empty string, then it is barred from constraint validation. http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#pseudo-classes :valid The :valid pseudo-class must match all elements that are candidates for constraint validation and that satisfy their constraints. :invalid The :invalid pseudo-class must match all elements that are candidates for constraint validation but that do not satisfy their constraints. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#candidate-for-constraint-validation A listed form-associated element is a candidate for constraint validation except when a condition has barred the element from constraint validation. -- TAMURA Kent Software Engineer, Google
[whatwg] Step base for input type=week
The default step base for type=week should be -259,200,000 (the beginning of 1970-W01) instead of 0. If an implementation follows the current spec and an input element has no min attribute, stepMismatch for the element never be false because the step base is not aligned to the beginning of a week. -- TAMURA Kent Software Engineer, Google
[whatwg] valueAsNumber: float is not enough
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element attribute float valueAsNumber http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-valueasnumber; valueAsNumber is defined as float, IEEE754 single precision number. It should be double because number values for date and time types are milliseconds from UNIX epoch. As of today, milliseconds from UNIX epoch is about 1,264,492,163,000. The float type can't represent this value precisely. If we do the following with float valueAsNumber, the input value loses the data. input.type = datetime; input.value = 2010-01-26T08:00Z; var num = input.valueAsNumber; input.valueAsNumber = num; -- TAMURA Kent Software Engineer, Google
[whatwg] HTMLInputElement::valueAsNumber and NaN Infinity
On setting, if the valueAsNumberhttp://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-valueasnumber attribute does not apply, as defined for the inputhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element element's typehttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-type attribute's current state, then throw anINVALID_STATE_ERRhttp://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#invalid_state_err exception. Otherwise, if the valueAsDatehttp://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-valueasdate attribute applies, run the algorithm to convert a Date object to a stringhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-value-date-string defined for that state, passing it a Date object whose time value is the new value, and set the valuehttp://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-fe-value of the element to resulting string. Otherwise, run the algorithm to convert a number to a stringhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-value-number-string, as defined for that state, on the new value, and set the valuehttp://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-fe-value of the element to resulting string. It seems the current spec doesn't define behavior in a case of setting NaN or Infinitiy to HTMLInputElement::valueAsNumber. Because 'input.valueAsDate = null' makes the value empty, I think 'input.valueAsNumber = Number.NaN' also makes the value empty. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] HTMLInputElement::valueAsNumber and NaN Infinity
On Mon, Jan 25, 2010 at 19:10, Philip Taylor excors+wha...@gmail.comexcors%2bwha...@gmail.com wrote: On Mon, Jan 25, 2010 at 9:55 AM, TAMURA, Kent tk...@chromium.org wrote: It seems the current spec doesn't define behavior in a case of setting NaN or Infinitiy to HTMLInputElement::valueAsNumber. http://whatwg.org/html5#float-nan : Except where otherwise specified, if an IDL attribute that is a floating point number type (float) is assigned an Infinity or Not-a-Number (NaN) value, a NOT_SUPPORTED_ERR exception must be raised. This case seems to apply for valueAsNumber. Oh, that's right. I overlooked it. Thanks! -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Removing multiple attribute from input type=file multiple with selected files
I would prefer not to throw an exception. Making removeAttribute throw an exception seems wrong since the attribute *is* in fact removed, and making foo.multiple=false throw would mean that it would behave differently from all other mapped IDL attributes. I'd really prefer to keep things simple here as I doubt that this is something that anyone will ever do. Much less depend on a particular behavior. You're off course free to put a warning in a developer console or something like that though. I buy that. A warning seems appropriate. I'm sure *someone* will do this someday, but it's probably rare enough that it's not worth putting effort into. Yeah, a warning seems reasonable. The current implementation of WebKit does nothing, and I might add the warning if the spec say nothing about this. Thank you. -- TAMURA Kent Software Engineer, Google
[whatwg] Removing multiple attribute from input type=file multiple with selected files
What should happen to selected files in a case that a user selects multiple files for input type=file multiple and then a script code removes the multiple attribute from the input element? - nothing, no change to the selected files and they will be submitted, - cleared, or - a single file remains -- TAMURA Kent Software Engineer, Google
[whatwg] stepMismatch with value min or value max
input type=number min=0 step=2 value='-1' input type=number min=0 max=4 step=2 value=5 Should input.validity.stepMismatch return true in these cases? The spec simply says: that number subtracted from the step base is not an integral multiple of the allowed value step, the element is suffering from a step mismatch. and doesn't mention the relationship with rangeUnderflow and rangeOverflow. So I think stepMismatch should work even if value is less than min or greater than max. I'd like to clarify it. -- TAMURA Kent Software Engineer, Google
[whatwg] type=email validation is too loose for practical applications
http://www.whatwg.org/specs/web-apps/current-work/#e-mail-state A valid e-mail address is a string that matches the production dot-atom-text @ dot-atom-text where dot-atom-text is defined in RFC 5322 section 3.2.3. [RFC5322]http://www.whatwg.org/specs/web-apps/current-work/#refsRFC5322 I'd like stricter rule for it. e.g. dot-atom-text @ 1*(ALPHA / DIGIT) 1*(. 1*(ALPHA / DIGIT)) I understand the current production, dot-atom-text @ dot-atom-text, is a subset of addr-spec of RFC 5322. However dot-atom-text for the domain-part is not practical. The production accepts apparently unusable email address like tk...@ -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Comments on the definition of a valid e-mail address
FYI. I was in Gmail team and wrote the email address validation code which we are currently using. Gmail's validation rules are: - require @ - local-part should be - quoted-string without CFWS and FWS, or - 1*(atext / .)This means dot-atom-text without . restriction. This looseness was introduced for Japanese cell phone addresses. - domain-part should be [a-zA-Z0-9]+(\.[a-zA-Z0-9]+)+ It requires at least 1 dot. The last non-dot sequence should have at least 2 characters. I have never heard requests to support for non-ASCII characters other than IDN. -- TAMURA Kent Software Engineer, Google
Re: [whatwg] Comments on the definition of a valid e-mail address
- domain-part should be [a-zA-Z0-9]+(\.[a-zA-Z0-9]+)+ Correction. - is allowed for domain-part. -- TAMURA Kent Software Engineer, Google
[whatwg] HTMLOptionElement::value compatibility
The `value' DOM attribute of HTMLOptionElement is incompatible with the current major browsers. The spec says: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-option-value http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-option-value The disabled, label, and value DOM attributes must reflecthttp://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#reflect the respective content attributes of the same name. However .value in IE8, Firefox3.5, Chrome2, Safari4, and Opera10b2 doesn't work so. It returns the value of `value' HTML attribute, or the value of .text DOM attribute if the element doesn't have the `value' HTML attribute or the value of `value' HTML attribute is empty. If we substitute a string to .value DOM attribute, the `value' HTML attribute is updated. The spec should follow this behavior. -- TAMURA Kent Software Engineer, Google
