Re: [whatwg] Why do we have input type='month' and input type='week'?
On Tue, Feb 12, 2013 at 11:20 AM, Mounir Lamouri mou...@lamouri.fr wrote: Regarding week, I still believe that the use cases are pretty weak but the most important issue is that there is no good UI for this on Mobile AFAIK. There aren't stock widgets, but this isn't a hard UI problem to solve. For example, two panes: a year scroller and a scroller containing a vertical strip of calendars, where you scroll vertically to the row corresponding with the week you want to select. A trickier issue for weeks is which day the week starts on. To me, calendar weeks start on Sunday and end on Saturday. I'd find it weird to be shown a Monday-aligned calendar, but this is hard to localize, since the browser can't return anything but Monday-based week numbers. This would probably work better if the result was a date, not a week number, so it could return both Sundays and Mondays, but this might lead to localization bugs. -- Glenn Maynard
Re: [whatwg] Why do we have input type='month' and input type='week'?
On 01/02/13 15:39, Glenn Maynard wrote: On Thu, Jan 31, 2013 at 6:20 AM, Bruce Lawson bru...@opera.com wrote: The use-case for an input type I imagine is that a browser can have a select-like UI (Jan, Feb, March, April ...) which, in a French language browser becomes Janvier, Fevrier, Mars, Avril .. (or even Vendémiaire to Fructidor for FRC fans). FYI, I would find this annoying. CC expiry entry forms are typically select boxes containing 01-12. The text lines up with what's on my credit card, so I don't have to translate 07 to July in my head when entering it off of my card. Any month picker for credit card expiry dates should always have month numbers (of course, names *in addition* to numbers are fine, though probably pointless). That's exactly why I think the use case is weak: it is easy to implement a month picker: select name='month'!--fill with option for each month--/selectselect name='year'!-- fill with option for each year you want to show --/select Given how easy it is, authors might quickly end up expecting specific behaviour that the UAs do not provide. For example, Having 01 - January or January - 01 or even 01 instead of January. They could want the year to show up as 2 digits or 1 digit, as a textfield, a select or an input type='number' with a min and a max. Anyway, I still believe that the pros of input type='month' are quite low but in another hand, it shouldn't cost too much for UA to implement it if or date-time-related types are already implemented and it provides a real benefit on Mobile. Regarding week, I still believe that the use cases are pretty weak but the most important issue is that there is no good UI for this on Mobile AFAIK. Cheers, -- Mounir
Re: [whatwg] Why do we have input type='month' and input type='week'?
On Tue, Feb 12, 2013 at 9:20 AM, Mounir Lamouri mou...@lamouri.fr wrote: On 01/02/13 15:39, Glenn Maynard wrote: FYI, I would find this annoying. CC expiry entry forms are typically select boxes containing 01-12. The text lines up with what's on my credit card, so I don't have to translate 07 to July in my head when entering it off of my card. Any month picker for credit card expiry dates should always have month numbers (of course, names *in addition* to numbers are fine, though probably pointless). That's exactly why I think the use case is weak: it is easy to implement a month picker: select name='month'!--fill with option for each month--/selectselect name='year'!-- fill with option for each year you want to show --/select Given how easy it is, authors might quickly end up expecting specific behaviour that the UAs do not provide. For example, Having 01 - January or January - 01 or even 01 instead of January. They could want the year to show up as 2 digits or 1 digit, as a textfield, a select or an input type='number' with a min and a max. Anyway, I still believe that the pros of input type='month' are quite low but in another hand, it shouldn't cost too much for UA to implement it if or date-time-related types are already implemented and it provides a real benefit on Mobile. The fact that authors today have a random assortment of displays for the exact same feature (credit card expirys) is something that would be great to fix, not bemoan as a loss to the world. ^_^ ~TJ
Re: [whatwg] Why do we have input type='month' and input type='week'?
2013-02-12 19:26, Tab Atkins Jr. wrote: The fact that authors today have a random assortment of displays for the exact same feature (credit card expirys) is something that would be great to fix, not bemoan as a loss to the world. ^_^ Well, maybe, from some point of view, but is there really something to be fixed, and is it probable that input type=month would fix it? I have seen many input widgets for such data and used them a lot in test purchases. In general, the more advanced they try to be, the more annoying they get. I can type 03/15, or whatever reads in the card, rather fast. But if I have to pick things up from dropdowns or click on something in a calendar picker, I surely hope I won't need to do this a dozen more times. What are the odds that browser vendors will implement input type=month in a simple manner that allows fast typing as one input method? Rather small I think. This would make the most obvious, and perhaps the most common, use for input type=month a case *against* it. Credit card expiry month is best handled with a text input field, with suitable checks on the input string. There may be *other* cases where graphic widgets are good when selecting a month, but authors can use libraries for such purpose, and I don't see any particular reason why this should be standardized across pages but not across browsers. Even if input type=month became widely supported, many, probably most, authors will keep using libraries or their own code, because they get consistent look and feel and functionality across browsers. Some authors would be misled into using input type=month for any month input because that's logical or semantic (as it is in a sense), but this will create questionable user experience in many common cases. Yucca
Re: [whatwg] Why do we have input type='month' and input type='week'?
On Tue, Feb 12, 2013 at 9:39 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2013-02-12 19:26, Tab Atkins Jr. wrote: The fact that authors today have a random assortment of displays for the exact same feature (credit card expirys) is something that would be great to fix, not bemoan as a loss to the world. ^_^ Well, maybe, from some point of view, but is there really something to be fixed, and is it probable that input type=month would fix it? I have seen many input widgets for such data and used them a lot in test purchases. In general, the more advanced they try to be, the more annoying they get. I can type 03/15, or whatever reads in the card, rather fast. But if I have to pick things up from dropdowns or click on something in a calendar picker, I surely hope I won't need to do this a dozen more times. What are the odds that browser vendors will implement input type=month in a simple manner that allows fast typing as one input method? Rather small I think. This would make the most obvious, and perhaps the most common, use for input type=month a case *against* it. Credit card expiry month is best handled with a text input field, with suitable checks on the input string. There may be *other* cases where graphic widgets are good when selecting a month, but authors can use libraries for such purpose, and I don't see any particular reason why this should be standardized across pages but not across browsers. This argument appears to apply equally well to all the date inputs, and perhaps most of the other new inputs. I believe it's wrong. * Most people don't type very fast. We email-happy people are an exception. For most, clicking on things is faster and easier. * Experience shows that most authors appear to prefer a pair of dropdowns for selecting month and year, rather than a text input. Might as well move closer to author expectations. * Text inputs are permanently subject to the vagaries of whatever arcane syntax the author happened to want (or didn't want, but accidentally required when they miswrote their regex) - Do I just type two numbers with a slash? Or do I use a dash? Or a space? What if I use a slash surrounded by spaces? Or do I use the month name? Long or short name? Two digit or four digit year? - while visual inputs put your options in front of you and avoid all of that. Even if input type=month became widely supported, many, probably most, authors will keep using libraries or their own code, because they get consistent look and feel and functionality across browsers. Some authors would be misled into using input type=month for any month input because that's logical or semantic (as it is in a sense), but this will create questionable user experience in many common cases. This same argument keeps getting deployed against type=date. We'll see what actually happens. I expect (and deeply hope) that the ease of use of the built-ins will win the day, once they're supported on every browser sites expect their visitors to use. ~TJ
Re: [whatwg] Why do we have input type='month' and input type='week'?
On Thu, Jan 31, 2013 at 6:20 AM, Bruce Lawson bru...@opera.com wrote: The use-case for an input type I imagine is that a browser can have a select-like UI (Jan, Feb, March, April ...) which, in a French language browser becomes Janvier, Fevrier, Mars, Avril .. (or even Vendémiaire to Fructidor for FRC fans). FYI, I would find this annoying. CC expiry entry forms are typically select boxes containing 01-12. The text lines up with what's on my credit card, so I don't have to translate 07 to July in my head when entering it off of my card. Any month picker for credit card expiry dates should always have month numbers (of course, names *in addition* to numbers are fine, though probably pointless). -- Glenn Maynard
Re: [whatwg] Why do we have input type='month' and input type='week'?
On Wed, Jan 30, 2013 at 9:55 PM, Mounir Lamouri mou...@lamouri.fr wrote:
Regarding 'month', I mostly don't understand the use case. I can't find
any situation where I am asked to input a { month, year } information.
Credit cards.
This type would solve the use cases of people trying to find a week to
meet.
I think it was for tax forms, though I have not encountered one myself.
--
http://annevankesteren.nl/
Re: [whatwg] Why do we have input type='month' and input type='week'?
On Wed, 30 Jan 2013 20:55:29 -, Mounir Lamouri mou...@lamouri.fr
wrote:
Regarding 'month', I mostly don't understand the use case. I can't find
any situation where I am asked to input a { month, year } information.
Given that the element is pretty trivial to implement by authors (this
is basically two select or a select and a input type='number'),
Others have commented on use-cases for collecting month, eg credit card
expiries.
The use-case for an input type I imagine is that a browser can have a
select-like UI (Jan, Feb, March, April ...) which, in a French language
browser becomes Janvier, Fevrier, Mars, Avril .. (or even Vendémiaire
to Fructidor for FRC fans).
b
Re: [whatwg] Why do we have input type='month' and input type='week'?
2013-01-31 14:20, Bruce Lawson wrote: Others have commented on use-cases for collecting month, eg credit card expiries. I have seen forms that prompt for year in month to specify start of employment (apparently when the exact date is not interesting) or a month to use when searching for cheapest flights to somewhere, apparently assuming that the customer is flexible with dates. Or you could have a month selection in a calendar application, or budget application. There are several use cases. It might be argued that they are considerably less common than selecting a day, The main problem is different, and shared with other date and time fields: do authors really want each visitor to see whatever widget his browser is showing? In the ideal world, maybe. There is great potential in principle, since the widget could be selected, by the user or someone helping him, so that it meets the user’s personal needs and preferences. It could also be argued that in the long, it greatly improves usability if different sites and applications use methods based on such widgets, so that the user can routinely use them, instead of wondering why this widget does not work the way he would expect from past experience with similar widgets. But is this going to happen? Why would authors/designers/managers favor some “standard widgets”? The use-case for an input type I imagine is that a browser can have a select-like UI (Jan, Feb, March, April ...) which, in a French language browser becomes Janvier, Fevrier, Mars, Avril .. (or even Vendémiaire to Fructidor for FRC fans). Right. And this probably becomes a nuisance if you need to select December 1952, because the widgets have typically been designed so that you need to click on something to get one year forward or backward. The other problem is that in non-supporting browsers, or in browsers that implement input type=month in a very simple manner (textbox, user input is taken as such, just checked for correctness), the user needs to type e.g. 1952-12, which is fast and simple – as soon as you know what is expected from you. Yucca
[whatwg] Why do we have input type='month' and input type='week'?
Hi,
In my war against useless input types, I had a look at 'month' and
'week' and I am wondering what was the rationale behind having them in
the HTML specifications.
Regarding 'month', I mostly don't understand the use case. I can't find
any situation where I am asked to input a { month, year } information.
Given that the element is pretty trivial to implement by authors (this
is basically two select or a select and a input type='number'), the
only advantage I see to have this element in the specifications is to
have a native UI on mobile.
I am wondering if use cases were taken into account when this was added
to the specs and if vendors that implement this element can report good
adoption if any.
I can see niche use cases for 'week' but I do not think it is easy to
come up with a good UI for this, especially on mobile (there is no
native UI on mobile AFAIK). On desktop, Chrome's UI is terrible but the
Opera one is decent.
This type would solve the use cases of people trying to find a week to
meet. Typically, W3C F2F's. However, this is a niche use cases. Most of
the times, when people speak in 'week', they don't really mean from
Monday to Sunday. For example, if someone takes a vacation the first
week of February, he/she will not book its hotel for the week 5 or 6
but from a specific day to another specific day.
Generally speaking, I believe both those types lack use cases and I
wonder if the HTML specifications are not defining a solution for
something that is still looking for its problem.
In other words, are authors writing their own 'month' and 'week' widget
at the moment? If they are, would there life be easier with those input
types?
Thanks,
--
Mounir
Re: [whatwg] Why do we have input type='month' and input type='week'?
On 30/01/2013 21:55, Mounir Lamouri wrote:
Hi,
In my war against useless input types, I had a look at 'month' and
'week' and I am wondering what was the rationale behind having them in
the HTML specifications.
Regarding 'month', I mostly don't understand the use case. I can't find
any situation where I am asked to input a { month, year } information.
Given that the element is pretty trivial to implement by authors (this
is basically twoselect or a select and ainput type='number'), the
only advantage I see to have this element in the specifications is to
have a native UI on mobile.
I am wondering if use cases were taken into account when this was added
to the specs and if vendors that implement this element can report good
adoption if any.
I can see niche use cases for 'week' but I do not think it is easy to
come up with a good UI for this, especially on mobile (there is no
native UI on mobile AFAIK). On desktop, Chrome's UI is terrible but the
Opera one is decent.
This type would solve the use cases of people trying to find a week to
meet. Typically, W3C F2F's. However, this is a niche use cases. Most of
the times, when people speak in 'week', they don't really mean from
Monday to Sunday. For example, if someone takes a vacation the first
week of February, he/she will not book its hotel for the week 5 or 6
but from a specific day to another specific day.
Generally speaking, I believe both those types lack use cases and I
wonder if the HTML specifications are not defining a solution for
something that is still looking for its problem.
In other words, are authors writing their own 'month' and 'week' widget
at the moment? If they are, would there life be easier with those input
types?
Thanks,
--
Mounir
Hi,
I think there are a lot of use cases for week and month input types. I
know a lot of organizations using week numbers and i'm pretty interested
to use this markup for my entreprise web apps even if it's currently not
really implemented.
I will go more far. I'd like to have an input type=day /. I often
have the need to create forms where the user choose an interval of
days. By example, from 1st March to 30 November. Currently i use
input type=date / and i ignore the year.
The use cases i encountered for that is maintenance control
programmation that differs in term of number of occurences and control
types during the year. By exampe , in winter, there are no wash because
of the low temperatures. On hollyday, there are no children on the
schools and less work for the agents. Etc...
I mean there are a lot of different events/task that differs that way
(car maintenance, train ticket costs) and it would be very nice to have
it working out of the box :).
Have a nice day !
---
Nicolas Froidure
Re: [whatwg] Why do we have input type='month' and input type='week'?
On 30/01/2013 20:55, Mounir Lamouri wrote:
Regarding 'month', I mostly don't understand the use case. I can't find
any situation where I am asked to input a { month, year } information.
Credit card expiry date?
Alex
--
Alex Bishop
alexbis...@gmail.com
