[whatwg] Forms-related feedback
On Wed, 2 Oct 2013, Jonas Sicking wrote: Hixie wrote: That's not the only alternative. For example, a third alternative is that the user's selection (e.g. a directory) is returned quickly, not pre-expanded, and then any uploading happens in the background with the author script doing the walk and uploading the files. It's unclear to me what you are proposing here. Can you elaborate? On Wed, 2 Oct 2013, Glenn Maynard wrote: The same thing I did, I think: an API to navigate the directory tree as needed, and to never greedily recursing the directory tree. On Wed, 2 Oct 2013, Jonas Sicking wrote: Unfortunately that's forbidden by current specs. Right, my point is that this would be a new API. I've filed this bug to track this feature request; if there are multiple implementors interested in this, I can add it: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23988 On Wed, 2 Oct 2013, Jonas Sicking wrote: The first application that I could think of that is designed for opening or importing large number of files is iTunes. And indeed on windows where there is no native open file or directory widget, they use separate menu items for import file and import folder. Wow, fascinating. I guess on Windows then input type=file multiple should indeed expose two buttons. On OSX iTunes relies on the combined file-or-folder picker that's not available on windows. Right, that picker is what I would have expected on all platforms. On Wed, 2 Oct 2013, David Dailey wrote: [...] ability to allow JavaScript, with user-consent, to insert an image file as the src of an img into a web page [...] It all used to be easy and worked in the two relevant browsers at the time: Netscape and IE. Then someone decided it was a security risk and that it preserved the privacy of the end user more to force him or her to upload the image to the server, create a round-trip from server to client and thence to be able to view a local image in a local web page. The old functionality continued to work in Netscape until its demise, and in IE until maybe version 6. The other browsers viewed the security risk as too high and ultimately IE seems to have agreed, hence breaking previous functionality. [...] Anyhow, as I recall, at the time, Hixie commented and someone else chimed in with details (that seemed rather convoluted at the time) saying that it was something people were working on. Has this effort led to fruition? Yes, you can now read the image data without it being first uploaded to the server, via the HTMLInputElement.files API. You can take such a File and then display it in an img via the Blob API and createObjectURL. On Wed, 2 Oct 2013, Glenn Maynard wrote: Assuming for now that we need separate modes for files and directories, I'd suggest input type=directory, which causes a directory picker to be shown, doesn't populate .files at all, and adds an API entry point to retrieve a filesystem. If somebody suggests an implementable way to expose UI that doesn't need to separate files and directories then we may want something else, but that doesn't seem likely to me. I think we want to support the Mac-style file+directory mode. On Thu, 3 Oct 2013, Jonas Sicking wrote: I'd rather extend input type=file multiple such that platforms that have directories can expose those, and ones that don't just expose files. Right. And on platforms that have combined file-or-directory pickers can render a single button, and platforms that use separate Widgets can render two buttons. Right. On Thu, 3 Oct 2013, Jan Tosovsky wrote: The missing access to the file system is a blocker now for replacing many client apps to their web counterparts. The basic question is whether web technologies should implement this functionality or not. I think it is a must, though limited to a trusted zone and OSes with file systems. By that trusted zone I mean a local network (local servers can access the client file system via user action) or Internet location authorized by a specific means (e.g. certificate like Java Applets). There have been several proposals for doing this kind of thing. I think the main mailing list where they've been discussed most recently is public-weba...@w3.org. (In practice, there seems to be a lot of different things people want that all fall into the same general area, so not much progress has been made as far as I can tell. It's also hard to design a highly usable system that's also secure. You don't want a permissions dialog, since that's not very usable or safe, but it's hard to see how else you would grant a page access to a remote file system. The input type=file security model, which works great for reading single files, is not necessarily easy to extrapolate to read+write rights to filesystems.) Anyway, I would recommend taking this up with the people already working on this in public-webapps. On
Re: [whatwg] Forms-related feedback
On Tue, Dec 3, 2013 at 11:38 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 2 Oct 2013, Jonas Sicking wrote: Hixie wrote: That's not the only alternative. For example, a third alternative is that the user's selection (e.g. a directory) is returned quickly, not pre-expanded, and then any uploading happens in the background with the author script doing the walk and uploading the files. It's unclear to me what you are proposing here. Can you elaborate? On Wed, 2 Oct 2013, Glenn Maynard wrote: The same thing I did, I think: an API to navigate the directory tree as needed, and to never greedily recursing the directory tree. On Wed, 2 Oct 2013, Jonas Sicking wrote: Unfortunately that's forbidden by current specs. Right, my point is that this would be a new API. I've filed this bug to track this feature request; if there are multiple implementors interested in this, I can add it: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23988 Given that both Chrome and Firefox is shipping directory-upload support, I would say that there are multiple vendors interested. At least if 2 counts as multiple. / Jonas
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 they
Re: [whatwg] Forms-related feedback
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? Value set by script or not doesn't matter. I mean, how would the user agent parse the script's new value. 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. 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.) 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. We can force it. If we don't provide the API, the author can't do it. 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. The demo he gives is: https://chromium.googlecode.com/issues/attachment?aid=263913000name=caret.htmltoken=tDkJ1CbBJ1hhXbsgb9Y0MRMzlks%3A1379968341420 If people want to reimplement widgets, then we should make sure Web Components can support their particular widget desires. I don't think it makes sense for us to make the default widgets be able to support every weird thing people want to do. - 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
Re: [whatwg] Forms-related feedback
On Wed, Aug 21, 2013 at 2:27 AM, TAMURA, Kent tk...@chromium.org wrote: 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. If we start doing this (and other things you proposed) we'll constrain future implementation strategies for this control. And other implementations might be forced to follow particular conventions in order to not break sites. That doesn't seem exactly ideal. -- http://annevankesteren.nl/
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, 14 Jan 2013, Jonas Sicking wrote: On Jan 8, 2013 1:47 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 27 Nov 2012, Mikko Rantalainen wrote: Ian Hickson, 2012-11-22 07:15 (Europe/Helsinki): On Wed, 21 Nov 2012, Mounir Lamouri wrote: Then, maybe a better naming could be datetime-utc? I think that would mislead authors into thinking that the UI that users will see is one that asks for a UTC time. That kind of UI is the worst UI for this kind of feature, so that would be misleading. I'd suggest datetime-absolute because the other variant is floating or relative (to local politically decided time which may vary depending on future political decisions). We could rename datetime to datetime-absolute and leave datetime-local as named, but I'm not really convinced that's much better than what we have now. I think it more common for people to interact mainly with people in their own timezone. I.e. most time when talking about dates and times people don't mention what timezone is involved and rely on context to provide that information. I agree that that is accurate for when people talk. But that's somewhat misleading, I think, regarding what it implies about form controls. In Web apps, there's basically three cases: 1. Cases where you mean a specific global time (a time relative to UTC), for coordination amongst people from many locations. For example: the time that a broadcast begins e.g. a live Hangout on G+ the time that a deliverable is due e.g. the due date for a poetry contest the time that a resource becomes available and the time it stops being available, if scheduled in advance e.g. the time that a meeting phone bridge code starts working and the time it ends working 2. Cases where you mean a specific global time (a time relative to UTC), but where the time is really only relevant for local purposes, and so when given is likely to be given relative to an implied time zone. For example: the time that a plane takes off or lands the time that a physical meeting (not one involving video conferencing across multiple sites) begins the time that someone wants to go home from work 3. Cases where you mean a floating time and no time zone actually applies. For example: a wake-up alarm on a phone (wake me up at 8am on Monday, where the time zone isn't decided until Monday, by examining where the user is) the time for an event celebrated at different times in different time zones, e.g. New Year's. Now, when implementing these, there's often mistakes made. For example, authors will often confuse case 1 for case 2, and will often confuse case 2 for case 3. That is, they will often assume a time zone when one should not be assumed, and will often forget about time zones entirely when a time zone should be assumed. For example, they may ask for the time that a broadcast begins, and then just assume that the time zone is the time zone of the server. This would work fine in a single-time-zone-company where the server is colocated with the users. Similarly, they might ask for the time of a plane's departure, and then display it in the user's time zone, forgetting that there's an implied time zone given by the user's location. The opposite error is harder to make. It's harder to ignore the time zone when all times that the user enters get converted to UTC -- unless you're in the UK during the winter, or one of a handful of other countries using UTC, you're likely to notice right away (and even in those, in many cases you'll likely notice within 6 months). Because of this likelihood for mistakes, the controls are designed so that forgetting a time zone requires more characters than giving one. Authors are less likely to initially use datetime-local than datetime, so they're more likely to be reminded to use time zones immediately, than they are to forget to use time zones until too late. So in most contexts when people think about a point in time, they do so for a specific timezone. I don't know how to evaluate if this is true. When that is not the case, this is something that people are aware of. When I interact with friends/family/coworkers where the timezone is not obvious this is quite clear. And in these cases I'm aware that I need to specify timezone. I don't know that that's the case. I think it's more likely that authors will incorrectly forget to use time zones when they should have, than it is for them to use time zones when they should not. That, as described above, is the principle on which the spec's design was based. So I would imagine that when a developer sees datetime that does
Re: [whatwg] Forms-related feedback
Ian, has *any* implementer expressed a preference for implementing a picker which allows selecting date+time+timezone? I.e. one that returns UTC dates? And can you point any other platforms that has such a UI widget. I have seen plenty of date and time pickers. But never one that also allowed the user to set the timezone as part of the same widget. I.e. claiming that there is *far* more widgets elsewhere which separates picking date/times from ones that are picking date/time/timezones. Are you really claiming that this is not the case? This seems like a claim that needs to be backed up in some form. Additionally, if we were to build a date+time+timezone picker, the current API to such a picker is insufficient since a date/time expressed in UTC is insufficient to express a date+time+timezone. If we want to return UTC dates, I instead propose that we make the element take a timezone as an input (through an attribute or some such). The picker would then select just date+time but return a result using UTC timezone. / Jonas On Mon, Jul 29, 2013 at 4:21 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 14 Jan 2013, Jonas Sicking wrote: On Jan 8, 2013 1:47 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 27 Nov 2012, Mikko Rantalainen wrote: Ian Hickson, 2012-11-22 07:15 (Europe/Helsinki): On Wed, 21 Nov 2012, Mounir Lamouri wrote: Then, maybe a better naming could be datetime-utc? I think that would mislead authors into thinking that the UI that users will see is one that asks for a UTC time. That kind of UI is the worst UI for this kind of feature, so that would be misleading. I'd suggest datetime-absolute because the other variant is floating or relative (to local politically decided time which may vary depending on future political decisions). We could rename datetime to datetime-absolute and leave datetime-local as named, but I'm not really convinced that's much better than what we have now. I think it more common for people to interact mainly with people in their own timezone. I.e. most time when talking about dates and times people don't mention what timezone is involved and rely on context to provide that information. I agree that that is accurate for when people talk. But that's somewhat misleading, I think, regarding what it implies about form controls. In Web apps, there's basically three cases: 1. Cases where you mean a specific global time (a time relative to UTC), for coordination amongst people from many locations. For example: the time that a broadcast begins e.g. a live Hangout on G+ the time that a deliverable is due e.g. the due date for a poetry contest the time that a resource becomes available and the time it stops being available, if scheduled in advance e.g. the time that a meeting phone bridge code starts working and the time it ends working 2. Cases where you mean a specific global time (a time relative to UTC), but where the time is really only relevant for local purposes, and so when given is likely to be given relative to an implied time zone. For example: the time that a plane takes off or lands the time that a physical meeting (not one involving video conferencing across multiple sites) begins the time that someone wants to go home from work 3. Cases where you mean a floating time and no time zone actually applies. For example: a wake-up alarm on a phone (wake me up at 8am on Monday, where the time zone isn't decided until Monday, by examining where the user is) the time for an event celebrated at different times in different time zones, e.g. New Year's. Now, when implementing these, there's often mistakes made. For example, authors will often confuse case 1 for case 2, and will often confuse case 2 for case 3. That is, they will often assume a time zone when one should not be assumed, and will often forget about time zones entirely when a time zone should be assumed. For example, they may ask for the time that a broadcast begins, and then just assume that the time zone is the time zone of the server. This would work fine in a single-time-zone-company where the server is colocated with the users. Similarly, they might ask for the time of a plane's departure, and then display it in the user's time zone, forgetting that there's an implied time zone given by the user's location. The opposite error is harder to make. It's harder to ignore the time zone when all times that the user enters get converted to UTC -- unless you're in the UK during the winter, or one of a handful of other countries using UTC, you're likely to notice right away (and even in those, in many cases you'll
Re: [whatwg] Forms-related feedback
On Mon, Jul 29, 2013 at 4:50 PM, Jonas Sicking jo...@sicking.cc wrote: Ian, has *any* implementer expressed a preference for implementing a picker which allows selecting date+time+timezone? I.e. one that returns UTC dates? The Gmail time-picker (when you indicate that you want to set timezones), gives you three things next to each other, for date, time, and timezone. These are all right next to each other - whether they're separate or combined widgets isn't observable unless you check out the code. ~TJ
Re: [whatwg] Forms-related feedback
On Tue, Jul 30, 2013 at 9:59 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jul 29, 2013 at 4:50 PM, Jonas Sicking jo...@sicking.cc wrote: Ian, has *any* implementer expressed a preference for implementing a picker which allows selecting date+time+timezone? I.e. one that returns UTC dates? The Gmail time-picker (when you indicate that you want to set timezones), gives you three things next to each other, for date, time, and timezone. These are all right next to each other - whether they're separate or combined widgets isn't observable unless you check out the code. The iCal one allows for selecting a specific time zone and a floating one (which is what is currently called local): http://www.macobserver.com/tmo/article/Understanding_iCal_Time_Zones I actually think we need to distinguish between local and floating time zones. When using datetime-local, I would actually expect that the browser picks the local timezone as the default time zone, so doesn't expose a timezone entry in the UI. The value that is returned by the form, however, actually has a timezone. In contrast, when the app doesn't want a timezone, the developer should probably use something like datetime-floating. Then, it's clear that the time zone is actually left off of the returned value, too. Silvia.
Re: [whatwg] Forms-related feedback
On Mon, 29 Jul 2013, Jonas Sicking wrote: Ian, has *any* implementer expressed a preference for implementing a picker which allows selecting date+time+timezone? I.e. one that returns UTC dates? Your i.e. is a non-sequitur. A control that has date+time+timezone in the UI and a control that always returns UTC dates are orthogonal descriptions. type=datetime is not a control that allows selecting date+time+timezone. Regarding whether implementors have expressed interest in implementing specific controls: the controls currently in the spec were based on use cases, not on what specific implementors had indicated in terms of implementation interest. Once you can implement type=datetime-local, pretty much all the other date-related controls are trivial to implement usefully. I have seen plenty of date and time pickers. But never one that also allowed the user to set the timezone as part of the same widget. I have seen some, but that's academic, since none of the input controls in the HTML spec today are such a control. I.e. claiming that there is *far* more widgets elsewhere which separates picking date/times from ones that are picking date/time/timezones. Are you really claiming that this is not the case? This seems like a claim that needs to be backed up in some form. As noted in my previous e-mail, I'm not making any claims as to the relative proportions of the various controls. The design in the spec isn't about that, it's about reducing authoring mistakes by exposing authors to bugs quicker. Additionally, if we were to build a date+time+timezone picker, the current API to such a picker is insufficient since a date/time expressed in UTC is insufficient to express a date+time+timezone. Agreed. I don't think anyone is suggesting building such a picker at this time. I could definitely see a need for it -- or more likely, for specifically a time-zone picker -- but it's a much harder problem than the existing controls, as noted in my previous e-mail on this thread. If we want to return UTC dates, I instead propose that we make the element take a timezone as an input (through an attribute or some such). The picker would then select just date+time but return a result using UTC timezone. I don't understand the use case for such a control. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Tue, 30 Jul 2013, Silvia Pfeiffer wrote: I actually think we need to distinguish between local and floating time zones. When using datetime-local, I would actually expect that the browser picks the local timezone as the default time zone, so doesn't expose a timezone entry in the UI. The value that is returned by the form, however, actually has a timezone. That's type=datetime (the time zone is always UTC). In contrast, when the app doesn't want a timezone, the developer should probably use something like datetime-floating. Then, it's clear that the time zone is actually left off of the returned value, too. That's type=datetime-local. It's not only useful for floating times, as noted in the response on this bug, which is why it's not called something with floating in the name: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17856 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Tue, Jul 30, 2013 at 10:43 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 30 Jul 2013, Silvia Pfeiffer wrote: I actually think we need to distinguish between local and floating time zones. When using datetime-local, I would actually expect that the browser picks the local timezone as the default time zone, so doesn't expose a timezone entry in the UI. The value that is returned by the form, however, actually has a timezone. That's type=datetime (the time zone is always UTC). Hmm.. .what does a JS dev use, then, when they want to require a user to have to pick a timezone other than UTC? Silvia.
Re: [whatwg] Forms-related feedback
On Tue, 30 Jul 2013, Silvia Pfeiffer wrote: On Tue, Jul 30, 2013 at 10:43 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 30 Jul 2013, Silvia Pfeiffer wrote: I actually think we need to distinguish between local and floating time zones. When using datetime-local, I would actually expect that the browser picks the local timezone as the default time zone, so doesn't expose a timezone entry in the UI. The value that is returned by the form, however, actually has a timezone. That's type=datetime (the time zone is always UTC). Hmm.. .what does a JS dev use, then, when they want to require a user to have to pick a timezone other than UTC? There's no control in HTML today that exposes a time zone interface, whether it's UTC or anything else. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
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. - JavaScript-based screen readers can read user-visible content of input fields. Screen readers don't have to be limited to the HTML APIs. I'd expect a screen reader to have a much more intimate API to talk to the UA. There are some platforms of which native API is HTML. e.g. Chrome OS, Firefox OS, etc. Though Chrome OS can provide such API as chrome extension API, we had better have a standard API. I disagree. HTML is built on top of native APIs, even in Firefox OS and Chrome OS. It doesn't make sense to make HTML have all the APIs needed to talk to the OS. 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. - 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 just don't see how this is workable. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Mon, 14 Jan 2013, Jonas Sicking wrote: It's probably simple enough for authors to check valueAsNumber is not NaN and then have them set it to the value they want as the default, if they're calling the stepUp/stepDown methods. I've left this as throwing if the value isn't a number. *All* behavior of stepUp/stepDown is easy enough for authors to work around to cover cases where they don't agree with the spec. But if they have to, I don't see why they wouldn't simply not use stepUp/stepDown and implement whatever functionality that they want. Fair point. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On 16.1.2013 8:23, Jukka K. Korpela wrote: Since the use cases are rare, is it better to force browser vendors to develop code to implement it, in their own ways, than to let various software developers set up libraries for it? Since the browser implementations would, with practical certainty, lack adequate localizability (according to page language) and customizability, the HTML construct would not be used much. Authors, or their employers and clients, don't want just a date and time picker for example. They want a picker that suits their overall design. I don't think this will change anytime soon. Pages now use a wide variety of date pickers. While input type=date might be useful for testing and quick prototyping, and might be used by functionality-oriented authors who don't care much about look and feel, input type=datetime would rarely be used even for such purposes, so it would be an undue burden on browsers Yucca You are wrong here, while you may be right in case of web pages, for web apps native components makes more sense (for me at least). minimalistic, functional design without buch of libraries solving 1, 2 issues each of them. In such case native controls are/maybe preferable. There is a lot of authors application code, why download another code for datepicker, time picker, datetime picker, slider (range), etc. I can see datetime-local implemented in Chrome nightly and I'm glad I can stop using 2 separate controls (date, time). Overall design can be solved using pseudoclasses for browsers native controls. BK.
Re: [whatwg] Forms-related feedback
On Wed, Jan 16, 2013 at 1:03 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: On 16.1.2013 8:23, Jukka K. Korpela wrote: Since the use cases are rare, is it better to force browser vendors to develop code to implement it, in their own ways, than to let various software developers set up libraries for it? Since the browser implementations would, with practical certainty, lack adequate localizability (according to page language) and customizability, the HTML construct would not be used much. Authors, or their employers and clients, don't want just a date and time picker for example. They want a picker that suits their overall design. I don't think this will change anytime soon. Pages now use a wide variety of date pickers. While input type=date might be useful for testing and quick prototyping, and might be used by functionality-oriented authors who don't care much about look and feel, input type=datetime would rarely be used even for such purposes, so it would be an undue burden on browsers You are wrong here, while you may be right in case of web pages, for web apps native components makes more sense (for me at least). minimalistic, functional design without buch of libraries solving 1, 2 issues each of them. In such case native controls are/maybe preferable. There is a lot of authors application code, why download another code for datepicker, time picker, datetime picker, slider (range), etc. Strongly agree. I think any arguments that sites will refuse to use the native controls because they don't match the site's theme are countered by the observation that most sites using JS-library equivalents today still don't theme them very well, or at all. I usually just see a very plain mostly-white calendar, using whatever the default color scheme is for the given library. It also ignores the fact that us devs are mostly lazy, and love being able to write a simple element instead of piping in a library just to do a crappy calendar. ^_^ ~TJ
Re: [whatwg] Forms-related feedback
On Wed, 16 Jan 2013 11:01:14 -, Tab Atkins Jr. jackalm...@gmail.com wrote: Strongly agree. I think any arguments that sites will refuse to use the native controls because they don't match the site's theme are countered by the observation that most sites using JS-library equivalents today still don't theme them very well, or at all. I usually just see a very plain mostly-white calendar, using whatever the default color scheme is for the given library. Anecdotal, but *literally* every time I've given talks or demos of the new form input types I've been asked how they can be styled, and many devs have told me they'll continue to use things like jQuery UI because of the number of themes http://jqueryui.com/themeroller/ (which makes me sad) -- Bruce Lawson Open standards evangelist Developer Relations Team Opera http://dev.opera.com
Re: [whatwg] Forms-related feedback
On 16.1.2013 14:16, Bruce Lawson wrote: On Wed, 16 Jan 2013 11:01:14 -, Tab Atkins Jr. jackalm...@gmail.com wrote: Strongly agree. I think any arguments that sites will refuse to use the native controls because they don't match the site's theme are countered by the observation that most sites using JS-library equivalents today still don't theme them very well, or at all. I usually just see a very plain mostly-white calendar, using whatever the default color scheme is for the given library. Anecdotal, but *literally* every time I've given talks or demos of the new form input types I've been asked how they can be styled, and many devs have told me they'll continue to use things like jQuery UI because of the number of themes http://jqueryui.com/themeroller/ (which makes me sad) 1/ Every time, anyone is presenting some technology, there are always questions that technology cannot solve, that does not mean, it's deal breaker, tech. is bad whatever. 2/ Did you ask web developers in general? They won't use it anyway, what's the point on regular webpage, when majority of browsers has no UI for those controls yet? It may be cool for them, but they will fallback to e.g. jQuery. On the other hand, I focus on developing applications using web browser as runtime (I do not use web application for a certain reason). I do not use jQuery, or any other lib. why would I? I do not need those apps to run in every browser. 3/ Way for styling native controls are pseudo-classes, the fact, that we do not have those yet is hardly reason for abandoning it. We would have no progress at all if we had dropped every technology that is not perfect for everyone/everytime. The fact, that there is no way for styling is not a reason for abandoning/refusin, but a reson to create such pseudo-classes and implementing them. The same way all specs. are updated. BK
Re: [whatwg] Forms-related feedback
On Wed, 16 Jan 2013 13:48:43 -, Bronislav Klučka bronislav.klu...@bauglir.com wrote: 3/ Way for styling native controls are pseudo-classes, the fact, that we do not have those yet is hardly reason for abandoning it. We would have no progress at all if we had dropped every technology that is not perfect for everyone/everytime. The fact, that there is no way for styling is not a reason for abandoning/refusin, but a reson to create such pseudo-classes and implementing them. miscommunication: I strongly agree with you. I'm arguing for an urgent need to create the mechanism for styling the html controls, not for the abandonment of them. Bruce Lawson Open standards evangelist Developer Relations Team Opera http://dev.opera.com
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 Wed, 16 Jan 2013, TAMURA, Kent wrote: * If the type=datetime UI asks a UTC datetime, type=datetime-local is enough and type=datetime is unnecessary. Yes, asking for a UTC datetime would be horrible UI. * If the type=datetime UI asks a datetime and a timezone offset value, many users don't understand it. Yes, asking for a timezone offset would be terrible UI. * 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. Yes, it's hard to implement. But someone has to do it. I'd rather it was you and a handful of other browser vendors than a million Web authors. The harder something is to do, the more valuable it is for browser vendors to be the ones to do it rather than the site authors. The Google Calendar's UI is equivalent to type=datetime-local with an optional timezone selector. The key difference is that Google Calendar converts the time to UTC on the backend. That's not the same as type=datetime-local with an optional timezone selector. In fact it's the precise key difference between datetime-local and datetime. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Wed, 16 Jan 2013, TAMURA, Kent wrote: The key difference is that Google Calendar converts the time to UTC on the backend. That's not the same as type=datetime-local with an optional timezone selector. In fact it's the precise key difference between datetime-local and datetime. I don't think so. If you make a repeating event in a region with daylight saving time, Google Calendar respects the local time which you specified. Yes, for future events it adjusts the time so as to appear as if the time the user specified stays the same. But it's still converted to a global time -- other people looking at the calendar in different time zones see the event as being at the specified absolute time, not the specified local time. (In practice, I expect Google Calendar is a lot more clever than most sites would be for this kind of thing, and therefore as usual Google isn't quite simple enough to actually use what we provide in the spec...) I would love if we could have the browsers provide a time zone geographical location selector, but in practice these change so suddenly, and with so little notice, that it's not really practical. Updates would have to be pushed with minimal notice, which is unlikely, and Web authors around the world would have to coordinate updates to their sites in parallel with the browsers updating, etc. It would be a nightmare. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
2013-01-16 4:20, Ian Hickson wrote: * 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. Yes, it's hard to implement. But someone has to do it. I'd rather it was you and a handful of other browser vendors than a million Web authors. I don't think a million authors do such things. Instead, a few people may develop libraries for the purpose. The harder something is to do, the more valuable it is for browser vendors to be the ones to do it rather than the site authors. Since the use cases are rare, is it better to force browser vendors to develop code to implement it, in their own ways, than to let various software developers set up libraries for it? Since the browser implementations would, with practical certainty, lack adequate localizability (according to page language) and customizability, the HTML construct would not be used much. Authors, or their employers and clients, don't want just a date and time picker for example. They want a picker that suits their overall design. I don't think this will change anytime soon. Pages now use a wide variety of date pickers. While input type=date might be useful for testing and quick prototyping, and might be used by functionality-oriented authors who don't care much about look and feel, input type=datetime would rarely be used even for such purposes, so it would be an undue burden on browsers Yucca
Re: [whatwg] Forms-related feedback
On Jan 8, 2013 1:47 AM, Ian Hickson i...@hixie.ch wrote: [1] The only difference between Chrome's spin buttons behaviour and our proposal is that when value is the empty string, it is setting value to 0 and continue to the next steps (unless the 0 is below the minimal allowed value and n 0, in that case value=min). It might be interesting to specify something better than do nothing if value=. I'm open to doing that too; what would you preference be? Maybe if value isn't valid, we could have it changed to the step base or |min + (max - min)/2| and exit the steps if stepDown() or stepUp() is called. (I think even if stepDown(hugeNumber) is called, we should still just set the value and do nothing else.) I would tend to prefer step base mostly because it would know set it to the default value if there is a default value. However, I think step base is quite a bad solution for some types. Maybe we could use the default value if there is such a concept for the type or the step base otherwise? It's probably simple enough for authors to check valueAsNumber is not NaN and then have them set it to the value they want as the default, if they're calling the stepUp/stepDown methods. I've left this as throwing if the value isn't a number. *All* behavior of stepUp/stepDown is easy enough for authors to work around to cover cases where they don't agree with the spec. But if they have to, I don't see why they wouldn't simply not use stepUp/stepDown and implement whatever functionality that they want. The functionality that these functions provide is very little. So if they don't solve the authors use case exactly I think its easier for them in almost all cases to simply write their own implementation. Especially if you take into account the time and effort involved in looking up how the function works. So if we are going to have these functions at all, I think it should be possible to simply make the implementation of a button as simple as: button onclick=elem.stepUp()... button onclick=elem.stepDown()... And that this should in all cases produce good UI in as many cases as possible, and should never throw any exceptions. If we can't fulfill those use cases and requirement, then I think we might as well remove these functions. / Jonas
Re: [whatwg] Forms-related feedback
On Jan 8, 2013 1:47 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 27 Nov 2012, Mikko Rantalainen wrote: Ian Hickson, 2012-11-22 07:15 (Europe/Helsinki): On Wed, 21 Nov 2012, Mounir Lamouri wrote: Then, maybe a better naming could be datetime-utc? I think that would mislead authors into thinking that the UI that users will see is one that asks for a UTC time. That kind of UI is the worst UI for this kind of feature, so that would be misleading. I'd suggest datetime-absolute because the other variant is floating or relative (to local politically decided time which may vary depending on future political decisions). We could rename datetime to datetime-absolute and leave datetime-local as named, but I'm not really convinced that's much better than what we have now. I think it more common for people to interact mainly with people in their own timezone. I.e. most time when talking about dates and times people don't me nation what timezone is involved and rely on contest to provide that information. This applies both professionally, since most people work at single-timezone companies, or at least single-timezone departments, as well as privately, since most people interact with friends and family mainly in the same timezone. So in most contexts when people think about a point in time, they do so for a specific timezone. When that is not the case, this is something that people are aware of. When I interact with friends/family/coworkers where the timezone is not obvious this is quite clear. And in these cases I'm aware that I need to specify timezone. I think that the same applies to developers. So I would imagine that when a developer sees datetime that does not include a timezone. Likewise, when a developer wants to ask the user for a point in time which does include a timezone, that they would remember to ask for that explicitly. Additionally, in many cases even when timezones are involved do UIs not ask for the timezone as part of the date/time picker. When looking for airplane tickets the timezone is assumed to be that of the departing location when talking about departing time, and that of the arrival destination when talking about arriving time. When renting a car, the same thing applies, even if the car is picked up and returned in different timezones. Even the calendar app that's on my device (the built-in calendar app for Android 4.2) does not ask for timezone as part of the date/time picker. Instead a separate control is used where the user can choose what timezone the separately entered date/time is. This makes a lot of sense since timezones are easy to forget about and so having explicit and separate UI makes things more unlikely that the user will forget to enter the information. This is actually required for repeating events since it's important to know which timezone the user picked. I.e. there are two values entered by the user: the date/time and the timezone. So first off I'm not convinced that the common case for date/time entry will include entering a timezone. That might be the case in the technology industry, but is likely not elsewhere. Second, I'm not convinced that even if the common case includes timezone entry, that this means that the intuitive behavior for a datetime input type is to include UI for timezone entry. Third, I think that even in many cases where timezones are involved, that the better UI is to have timezone entry separate from from the date/time picker. I'm not advocating that having a timezone aware date/time picker is a bad idea. But I don't think it should be the default behavior. It might not even make it into the 80% set of use cases. So at least we should make datetime refer to a timezone-agnostic picker. And then use datetime-global or datetime-absolute or some such as a timezone aware picker. / Jonas
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] Forms-related feedback
On 13.1.2013 14:52, TAMURA, Kent wrote: 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 datetime-local shoud be removed from specification and datetime should reflect user's settings (e.g. underlying OS) BK
Re: [whatwg] Forms-related feedback
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). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Forms-related feedback
On Wed, 21 Nov 2012, Mounir Lamouri wrote: On 20/11/12 22:51, Ian Hickson wrote: On Tue, 20 Nov 2012, Mounir Lamouri wrote: At Mozilla, we think that the main use case for stepUp() and stepDown() is to create a UI with spin buttons: clicking on the up arrow would call stepUp() and clicking on the down arrow would call stepDown(). [...] Done, though I described it in a different way. (I hope it's equivalent.) I think there are two behaviour that you seem to have described differently: - in step 12, if you take the example page [1], setting the value to 21 and calling stepDown() should change the value to 20 and setting it to 19 and calling stepUp() should change it to 20. This how it is implemented in Opera and Firefox and this how the Chrome's UI behaves. As far as I understand the spec you wrote, those two examples would give respectively 10 and 30. [1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918 - I believe that when the value is set to below min and n 0, we should not change the value. Same thing for value below max and n 0. This is the behaviour all UA currently have with stepUp() and stepDown() (though, the previous spec was requiring that) and this is Chrome's UI behaviour. I think that behaviour makes more sense UX-wise because going down or up and having the value going the opposite way is just weird and unexpected. Done. For this: input type='number' min='10' step='10' max='21' ...if the value is 22 and you step up (with the UI), Chrome sets it to 21. (Opera does nothing.) Per spec, stepUp() now would leave this unchanged (like Opera). (I tried to test Firefox but I couldn't get my build to show UI for type=number. Not sure if I'm on the wrong channel or something?) Also, note that per the new spec if stepUp() or stepDown() are called with an argument that isn't 1, it's ignored if the value isn't on a valid step. So in the example above, if value=22 and you call stepDown(5), it only goes down to 20, not 10. Is that ok? Also, if you call it as stepDown(-2), it goes down to 20, it's not left at 22, because the argument is ignored and the method itself is used to determine the direction if we're not on step. Is that ok? Similarly, if you're at 10, and you call stepUp(1), it goes to 20, but if you call stepUp(2), it stays at 10, because 30 is out of range (max 21). Is that ok? [1] The only difference between Chrome's spin buttons behaviour and our proposal is that when value is the empty string, it is setting value to 0 and continue to the next steps (unless the 0 is below the minimal allowed value and n 0, in that case value=min). It might be interesting to specify something better than do nothing if value=. I'm open to doing that too; what would you preference be? Maybe if value isn't valid, we could have it changed to the step base or |min + (max - min)/2| and exit the steps if stepDown() or stepUp() is called. (I think even if stepDown(hugeNumber) is called, we should still just set the value and do nothing else.) I would tend to prefer step base mostly because it would know set it to the default value if there is a default value. However, I think step base is quite a bad solution for some types. Maybe we could use the default value if there is such a concept for the type or the step base otherwise? It's probably simple enough for authors to check valueAsNumber is not NaN and then have them set it to the value they want as the default, if they're calling the stepUp/stepDown methods. I've left this as throwing if the value isn't a number. On Sun, 25 Nov 2012, Scott Gonz�lez wrote: For any non-parsable value (including no value), we start at 0, take the step, then confine to a valid step within min/max. I think that makes sense for the UI, but for the methods I'm less sure, given how easy it is to check for this case and do whatever behaviour makes the most sense for the control. On Thu, 22 Nov 2012, Markus Ernst wrote: Am 22.11.2012 01:51 schrieb Ian Hickson: On Sun, 14 Aug 2011, Timo Beermann wrote: It should be able to implemet checkboxes, where by only activating/deactivating this single checkbox you can active/deactivate multiple other checkboxes. That is possible with scripting today, but it should be possible without scripting, only with HTML/CSS. Because some users deactivate Scripting (for security or whatever other reason) and on other computers (school, university, work,...) you are not able to change the settings, even if you want to. E.g. I use NoScript and only allow scripting on very few trusted sites, that really need it. I haven't added this yet, but it is already logged as a possible future extension, so it's possible it may be added in the future. What would be helpful though is examples of sites that do this kind of thing, so that we can study how necessary it
Re: [whatwg] Forms-related feedback
On 20/11/12 22:51, Ian Hickson wrote: On Tue, 20 Nov 2012, Mounir Lamouri wrote: Currently stepUp(n) and stepDown(n) are very basic methods. They more or less do value += n * allowedValueStep; with n = -n; if stepDown() was called. In addition of being pretty dumb, there are a lot of reasons why they can throw. At Mozilla, we think that the main use case for stepUp() and stepDown() is to create a UI with spin buttons: clicking on the up arrow would call stepUp() and clicking on the down arrow would call stepDown(). Such a use case needs methods that do better than just adding n * allowedValueStep. In addition, we think that throwing is very often a bad idea and that should happen when the developer clearly did something wrong. So, we would like to change the stepUp()/stepDown() algorithm to match the following behaviour: - we only throw if the input type doesn't allow those methods or if there is no allowed value step; - if the value isn't a number (aka empty string), we should just exit the steps; - if the value is below the minimal allowed value and n is negative, we should exit the steps; - if the value is above the maximal allowed value and n is positive, we should exit the steps; - if the element is suffering from a step mismatch, and n is negative, the value should be changed to the next valid value. Otherwise, it should be changed to the previous allowed value; - newValue = value + n * allodValueStep; - if the newValue is below the minimal allowed value, the newValue should be equal the minimal allowed value; - if the newValue is higher than the minimal allowed value, the newValue should be equal the minimal allowed value. Such a behaviour creates a real added value in stepUp() and stepDown() that make those methods useful compared to simply do value += n * allowedValueStep; and prevent throwing when there is no need to. Done, though I described it in a different way. (I hope it's equivalent.) I think there are two behaviour that you seem to have described differently: - in step 12, if you take the example page [1], setting the value to 21 and calling stepDown() should change the value to 20 and setting it to 19 and calling stepUp() should change it to 20. This how it is implemented in Opera and Firefox and this how the Chrome's UI behaves. As far as I understand the spec you wrote, those two examples would give respectively 10 and 30. - I believe that when the value is set to below min and n 0, we should not change the value. Same thing for value below max and n 0. This is the behaviour all UA currently have with stepUp() and stepDown() (though, the previous spec was requiring that) and this is Chrome's UI behaviour. I think that behaviour makes more sense UX-wise because going down or up and having the value going the opposite way is just weird and unexpected. [1] The only difference between Chrome's spin buttons behaviour and our proposal is that when value is the empty string, it is setting value to 0 and continue to the next steps (unless the 0 is below the minimal allowed value and n 0, in that case value=min). It might be interesting to specify something better than do nothing if value=. I'm open to doing that too; what would you preference be? Maybe if value isn't valid, we could have it changed to the step base or |min + (max - min)/2| and exit the steps if stepDown() or stepUp() is called. (I think even if stepDown(hugeNumber) is called, we should still just set the value and do nothing else.) I would tend to prefer step base mostly because it would know set it to the default value if there is a default value. However, I think step base is quite a bad solution for some types. Maybe we could use the default value if there is such a concept for the type or the step base otherwise? [1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918 Thank you for the prompt change, Ian. -- Mounir
[whatwg] Forms-related feedback
On Fri, 7 Sep 2012, TAMURA, Kent wrote: 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 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. This only makes sense if the control is a text control, which is not necessarily the ideal UI. For example, consider the GMail UI for typing e-mail addresses. What would you expose as the rawValue when the control contains two user chips, one word that is not yet converted to an e-mail address, and the user is dragging one of the chips to the end? * For number type, it returns user-editing string. If a user typed '123+++' into a number field, rawValue would be '123+++' as is. What if the number control is a spin dial and the user has the dial between numbers 1 and 2? * 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? - JavaScript-based screen readers can read user-visible content of input fields. Screen readers don't have to be limited to the HTML APIs. I'd expect a screen reader to have a much more intimate API to talk to the UA. Strings returned by rawValue attribute may be browser-dependent and locale-dependent. However it would be useful. I think browser-dependent and locale-dependent APIs are a recipe for interoperability disaster. I agree with the underlying use case of more detailed control over the widgets. But the way to fix that isn't to bolt on more and more browser-specific APIs to input, IMHO; the long-term fix is to implement a Web components model and allow the controls to be directly overridden. On Mon, 10 Sep 2012, Kang-Hao (Kenny) Lu wrote: 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. I don't really understand the value in this. Why can't the page just get out of the way and let the browser and user work together? 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? On Fri, 7 Sep 2012, Mikko Rantalainen wrote: 2012-09-07 07:35 Europe/Helsinki: Ian Hickson: On Thu, 30 Aug 2012, Jonas Sicking wrote: I think while in theory we could rely on UAs to enable barcode entry anywhere, which definitely would provide the maximum capabilities for [...] In this respect it's similar to the WebKit-proprietary x-webkit-speech attribute on input. In fact, this suggests that if other browsers are interested in supporting speech input, maybe we should standardise it as an inputmode value, e.g. inputmode=speech. Possible the inputmode= attribute in that case could be switched to a list of tokens, so you could in fact do inputmode=latin-prose speech or inputmode=numeric barcode in order to provide the user agent with more flexibility in the UI. While I agree that inputmode attribute should be made a space separated list of tokens, I'd avoid stuff like latin-prose. Expected input language should be specified via lang or xml:lang attributes instead. Latin here doesn't refer to the language, but to the input method (e.g. QWERTY or QWERTZ keyboard as opposed to hiragana mode in Japan). Examples of somewhat sensible inputmode values for input type=text: - unicode or text This isn't sensible since it doesn't say whether a dual-label latin/hiragana keyboard should be in latin mode or hiragana mode or whether a dual-label numeric/alphabetic phone keypad should be in numeric or alphabetic mode. - numeric (prefer numeric input but allow any text) That one is fine. - barcode Barcode is borderline (and
