974341 - [BBs] In the date picker allow to select only month and day

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect)

Description

[Jose Manuel Cantera]

There are some situations like introducing birthday dates that it is needed to allow the user to enter only day and month and not the full year.

We should enable that in Gaia, for instance supporting this kind of markup ... 

<input type="date" class="day-month"> 

ni to Arnau in order to check the viability of the suggested approach.

Comment 1

[Cristian Rodriguez (:crdlc)]

WIP https://github.com/mozilla-b2g/gaia/pull/16623

Comment 2

[Arnau March [:arnau] ( not working in Firefox OS anymore :( )]

Thanks for the patch Cristian.
ni to Patryk for advise.

Patryk, please check the attached captures:
year.png: current implementation of date picker
no-year.png: after this patch

I have 2 questions for you:
1. Could you please provide a visual to see the widths we should be using for columns?
Here Cristian, as a first approach, is keeping the same width for months, but I guess we could have a wider column for months...
2. I guess it would be could to use this patch to give extra functionality to date picker, in case we need to get just the day, month or year? or for individual values we should have a value selector?

Thanks!

Comment 3

[Arnau March [:arnau] ( not working in Firefox OS anymore :( )]

Attachment: year.png

Comment 4

[Arnau March [:arnau] ( not working in Firefox OS anymore :( )]

Attachment: no-year.png

Comment 5

[Arnau March [:arnau] ( not working in Firefox OS anymore :( )]

(In reply to Arnau March  [:arnau] from comment #2)
Sorry for the typo :)
> 2. I guess it would be "good" to use this patch to give extra functionality

Comment 6

[Patryk Adamczyk [:patryk] UX]

This would land in v.1.5 (2.0), so it would use the new style. Przemek and Vicki are working on new controls, so they could provide the right picker design.

Comment 7

[Cristian Rodriguez (:crdlc)]

Attachment: Patch v1

Thanks for the review

Comment 8

[Jose Manuel Cantera]

good work, works perfectly. I left a tiny comment on GH

thanks

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8383533 [details]
Patch v1

Transfer to rudy

Comment 10

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 8383533 [details]
Patch v1

Sorry that I don't agree on this approach to modify our implementation of <input type="date"> to make it support a non-standard behavior.

What I referenced is the following spec,
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state-(type=date)

From there, I could not see a way to let us input a yearless date and with the current approach, we could break the standard because we could input an invalid date or input a valid date with ambiguous semantics.

For this requirement, I would suggest: 

 1. Implement your own building block for this before we come out with a standard way to input yearless date.

 2. At the same time, we could propose something to dev-webapi for this, say, 
    <input type="date-yearless"> to make this happen in built-in controls.

Thanks.

Comment 11

[Cristian Rodriguez (:crdlc)]

(In reply to Rudy Lu [:rudyl] from comment #10)
> Comment on attachment 8383533 [details]
> Patch v1
> 
> Sorry that I don't agree on this approach to modify our implementation of
> <input type="date"> to make it support a non-standard behavior.
> 
> What I referenced is the following spec,
> http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-
> type-attribute.html#date-state-(type=date)
> 
> From there, I could not see a way to let us input a yearless date and with
> the current approach, we could break the standard because we could input an
> invalid date or input a valid date with ambiguous semantics.
> 
> For this requirement, I would suggest: 
> 
>  1. Implement your own building block for this before we come out with a
> standard way to input yearless date.
> 
>  2. At the same time, we could propose something to dev-webapi for this,
> say, 
>     <input type="date-yearless"> to make this happen in built-in controls.

I agree with it but I tried to put that type but system received type="text" instead of "date-yearless". Any suggestion about who could take a look at this behavior on gecko side?

> 
> Thanks.

Comment 12

[Cristian Rodriguez (:crdlc)]

Sent e-mail to dev-webapi:

https://groups.google.com/forum/#!topic/mozilla.dev.webapi/z_FgXRUPatw

Comment 13

[Tantek Çelik]

Please use "month-day" rather than "date-yearless", e.g. <input type="month-day"> as was proposed and discussed openly years ago:

http://wiki.whatwg.org/wiki/Input#new_datetime_input_use-cases

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027725.html

Thanks.

Comment 14

[Tantek Çelik]

See also: https://wiki.mozilla.org/HTML5/input#type_month-day

Comment 15

[Antonio Manuel Amaya Calvo (:amac)]

Before taking on this, and taking into account that not ever all the types that *are* currently on the standard are implemented, Jonas, are you ok with adding a new type to the input element for birthdays (month-day)?

And should this be a B2G only type, or should we add it for all versions of Firefox?

Personally, I think it would be easier just to go ahead with Cristian's approach. Concerning Rudy's worries, it's true that Cristian's approach has a ambiguous semantic: All days of year 9996 represent both themselves and the same date without a fixed year. But on the other hand, I don't see that being a practical problem on the near future :)

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Rudy: I agree that it makes me uncomfortable to add new <input> types that aren't yet standardized. However this one has been debated quite a lot so I think it's a safe bet that it'll get added eventually. But I agree it's definitely a risk.

I don't understand your concern about modifying <input type=date>. From the webpage's/webapp's point of view, this is a completely new input type. I.e. <input type="month-day"> is completely separate from <input type="date">. The fact that we're reusing some of the implementation isn't something that developers will see or care about. And it's something that we can change in the future if that makes sense.


Given that we don't have any other date pickers implemented in Firefox Desktop I don't think we should worry about that.

However it would be good to implement for Firefox for Android. But we might want to check with how the standards discussion is going first.


Also, I think that "day-month" would make more sense than "month-day". Most of the world puts days before months. Including most english speaking countries (i.e. ones that use the strings 'month' and 'day').

http://en.wikipedia.org/wiki/Date_format_by_country

Comment 17

[Tantek Çelik]

(In reply to Jonas Sicking (:sicking) from comment #16)
> Also, I think that "day-month" would make more sense than "month-day". Most
> of the world puts days before months. Including most english speaking
> countries (i.e. ones that use the strings 'month' and 'day').
> 
> http://en.wikipedia.org/wiki/Date_format_by_country

I don't think bikeshedding this makes sense after 3+ years of the proposal being out there publicly and the name being unopposed in WHATWG and HTMLWG. So no, I would reject this request. If you're serious about a renaming, I can email WHATWG/HTMLWG and ask for a public survey on it, in great bikeshedding tradition.
In addition, the abstract "most of the world" reasoning is not helpful. If you really want to justify a change, justify it via the specific documented use-cases that justified the input type in the first place.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Please do email whatwg. I don't think it's too late for changing aspects of this feature given that it has neither shipped anywhere nor made it into spec yet.

As far as use cases for renaming. I don't think use cases is what tends to drive naming, but rather what is most intuitive and/or most understandable. On that count I think "day-month" is more intuitive, though only equally understandable, as "month-day".

Comment 19

[Jose Manuel Cantera]

Hi guys,

We need to make progress with this. Can we go for enabling <input type="-moz-month-day"> in Gecko and later rename it when WHATWG makes a final decision? With a tiny patch in Gecko to enable it and Cristian's Gaia patch we can have here a quick win and a nice feature for B2G.

Do you agree?

thanks

Comment 20

[(no longer active)]

(In reply to comment #19)
> Hi guys,
> 
> We need to make progress with this. Can we go for enabling <input
> type="-moz-month-day"> in Gecko and later rename it when WHATWG makes a final
> decision? With a tiny patch in Gecko to enable it and Cristian's Gaia patch we
> can have here a quick win and a nice feature for B2G.
> 
> Do you agree?

No, that is not a good decision IMO.  Why not have the discussion on WHATWG now?  The last time that this came up nobody bikeshedded on the name for this type, so I don't know why we're assuming that people might this time without trying first.

Comment 21

[Tantek Çelik]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #20)
> (In reply to comment #19)
> > Hi guys,
> > 
> > We need to make progress with this. Can we go for enabling <input
> > type="-moz-month-day"> in Gecko and later rename it when WHATWG makes a final
> > decision? With a tiny patch in Gecko to enable it and Cristian's Gaia patch we
> > can have here a quick win and a nice feature for B2G.
> > 
> > Do you agree?
> 
> No, that is not a good decision IMO.  Why not have the discussion on WHATWG
> now? 

Because discussions tend to go better on WHATWG when there's actual progress being made on browser implementation.

> The last time that this came up nobody bikeshedded on the name for
> this type,

Right, so we should land that (type="month-day" - which BTW is also the order in ISO8601 dates YYYY-MM-DD (why I chose month-day initially) an international standard that trumps the cultural-based arguments of population A vs population B), and then give a heads up about it in case anyone cares substantially enough and can justify a name change.

> so I don't know why we're assuming that people might this time
> without trying first.

Because this very thread happened, that's why.

Comment 22

[(no longer active)]

(In reply to comment #21)
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #20)
> > (In reply to comment #19)
> > > Hi guys,
> > > 
> > > We need to make progress with this. Can we go for enabling <input
> > > type="-moz-month-day"> in Gecko and later rename it when WHATWG makes a final
> > > decision? With a tiny patch in Gecko to enable it and Cristian's Gaia patch we
> > > can have here a quick win and a nice feature for B2G.
> > > 
> > > Do you agree?
> > 
> > No, that is not a good decision IMO.  Why not have the discussion on WHATWG
> > now? 
> 
> Because discussions tend to go better on WHATWG when there's actual progress
> being made on browser implementation.

To make my position clear, I think starting the work on the implementation here is a great idea.  What's bad is *enabling* a moz-prefixed type name.  I have no opposition to implement this behind some kind of a run-time pref, or restricting it to gaia with the non-prefixed name that we suspect will win the naming bikeshedding.

> > The last time that this came up nobody bikeshedded on the name for
> > this type,
> 
> Right, so we should land that (type="month-day" - which BTW is also the order
> in ISO8601 dates YYYY-MM-DD (why I chose month-day initially) an international
> standard that trumps the cultural-based arguments of population A vs population
> B), and then give a heads up about it in case anyone cares substantially enough
> and can justify a name change.
> 
> > so I don't know why we're assuming that people might this time
> > without trying first.
> 
> Because this very thread happened, that's why.

It's you and Jonas who are disagreeing here, not anyone from WHATWG.  :-)

FWIW I don't really have a storing preference either way.

Comment 23

[Jose Manuel Cantera]

It seems the consensus is on:

+ implement this under a runtime preference and enable it only in Gaia
+ use the "standardish" "month-day" as the new input type

Jonas, Ehsan, Tantek, do you agree on that?

If so I will try to find someone in the TEF team (or can do it even myself) to create a Gecko patch for this 

thanks!

Comment 24

[(no longer active)]

(In reply to Jose M. Cantera from comment #23)
> It seems the consensus is on:
> 
> + implement this under a runtime preference and enable it only in Gaia

Agreed.

> + use the "standardish" "month-day" as the new input type

Like I said before, I have no strong preference on the name, I'll leave this up to Jonas and Tantek.

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Sounds good to me.

Comment 26

[Hixie (not reading bugmail)]

Feel free to ship this without a preference enabled for everyone, using whatever name you want, so long as it doesn't have a prefix. If implementation experience shows this should be added to the spec, I'll add it with whatever name and semantics you used, or, if we find we need incompatible semantics, with a name that won't clash. If it turns out to be a bad idea (I can't imagine that it would), then it can just be dropped without fanfare (it'll just get treated as type=text).

Comment 27

[Hixie (not reading bugmail)]

Also consider the feedback in:
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=15114

Comment 28

[Jose Manuel Cantera]

(In reply to Hixie (not reading bugmail) from comment #26)
> Feel free to ship this without a preference enabled for everyone, using
> whatever name you want, so long as it doesn't have a prefix. If
> implementation experience shows this should be added to the spec, I'll add
> it with whatever name and semantics you used, or, if we find we need
> incompatible semantics, with a name that won't clash. If it turns out to be
> a bad idea (I can't imagine that it would), then it can just be dropped
> without fanfare (it'll just get treated as type=text).

thanks, we will proceed accordingly

Comment 29

[Anne (:annevk)]

Is this still something we're planning on doing?

Comment 30

[Anne (:annevk)]

Resolving this as WONTFIX. If someone wants to make this happen after all, please open a corresponding issue here: https://github.com/whatwg/html/issues/new.