Closed Bug 974341 Opened 6 years ago Closed 4 years ago

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

Categories

(Firefox OS Graveyard :: Gaia, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jmcf, Unassigned)

References

Details

Attachments

(3 files)

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.
Flags: needinfo?(arnau)
Summary: In the date picker allow to select only month and day → [BBs] In the date picker allow to select only month and day
Blocks: 935045
WIP https://github.com/mozilla-b2g/gaia/pull/16623
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
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!
Flags: needinfo?(arnau) → needinfo?(padamczyk)
(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
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.
Flags: needinfo?(padamczyk) → needinfo?(pabratowski)
Attached file Patch v1
Thanks for the review
Attachment #8383533 - Flags: review?(jmcf)
Attachment #8383533 - Flags: review?(alive)
Attachment #8383533 - Flags: review?(jmcf) → review+
good work, works perfectly. I left a tiny comment on GH

thanks
Comment on attachment 8383533 [details]
Patch v1

Transfer to rudy
Attachment #8383533 - Flags: review?(alive) → review?(rlu)
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.
Attachment #8383533 - Flags: review?(rlu)
(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.
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.
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 :)
Flags: needinfo?(jonas)
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
Flags: needinfo?(jonas)
(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.
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".
Flags: needinfo?(pabratowski)
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
(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.
(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.
(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.
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!
Flags: needinfo?(tantek)
Flags: needinfo?(jonas)
Flags: needinfo?(ehsan)
(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.
Flags: needinfo?(ehsan)
Sounds good to me.
Flags: needinfo?(jonas)
Assignee: crdlc → acperez
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).
(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
Flags: needinfo?(tantek)
Is this still something we're planning on doing?
Assignee: alberto.crespellperez → nobody
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.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.