Polyfill date input type

That patch is missing things, it's more like this.

Actually that's still missing things, it's this.

Marking this active since #1252178: Add Modernizr to core is pending!

And #1252178: Add Modernizr to core is committed! I'm not quite sure how to implement this, I'm hoping someone can provide a patch or example.

I can certainly help with the Modernizr part! Since this looks to be mainly JavaScript changes, you can access the relevant test by writing a conditional like so:

if (Modernizr.inputtypes.date) {
  // Rely on native support
}
else {
  // Summon the polyfill!
}

Or if you only want to cover the NOT:

if (!Modernizr.inputtypes.date) {
  // Polyfill code
}

You can see the full list of support within your browser by going to your browser's JS console and evaluating Modernizr.inputtypes. It will return an Object full of booleans corresponding to each test result. Here's the output I got from Chrome 23.0.1271.64 on OSX:

> Modernizr.inputtypes
  Object
    color: true
    date: true
    datetime: false
    datetime-local: false
    email: true
    month: false
    number: true
    range: true
    search: true
    tel: true
    time: true
    url: true
    week: false

...coming from #504524: Extend Authored on field with jQuery UI Date Picker

Also coming from there. I've been maintaining Date Popup Authored, which was borne out of that issue, for d6 and d7, but all it really does is replace the Authored On textfield element with (contrib) Date's date_popup element (plus a few extra things to ensure Drupal gets the correct input).

Looks like this pretty much obsoletes the module for D8, am I right?

Splitting the authored on field into HTML5 date and time elements is covered in #501428: Date and time field type in core. If the polyfill is added we'll also have a fallback to the jQuery datepicker. So yes, I think this will obsolete the Date Popup Authored module.

Hm. I think this (or another issue that covers this) might be major, or possibly critical...

Here's what a datetime field looks like on Chrome:

So far, so good...

But here's what it looks like in Firefox:

There's absolutely no guidance about what to do until you submit the form and get an error message. :(

Also, since there's a patch here, marking needs review.

Trying to add jquery popup widget for date.

This is not working perfectly, I wasn't expecting tests to be passed, hoping failed test might be help find right path.

Here is updated patch, atleast jquery popup is working now.

I've reposted the patch from #2467351: Add jQuery UI datepicker for the Date element of the datetime field here.

I've taken a very different approach than the current patch. The idea is to add a JS fallback to all date fields instead of creating a separate widget for it.

#17 works well on Firefox, and Chrome behavior is unchanged (Chrome natively handles the input type date). We needed #2467449: jQuery UI datepicker styles broken in Seven for datepicker styling.
There is no timepicker for hours and minutes, but I guess this is another issue?

There is a separate issue for the time #1838234: Add jQuery Timepicker for the Time element of the datetime field.

@nod_ Thanks for the review, I'll look into this

I've followed the guidelines in #22, putting the settings on the element and adding a detach method to the behavior.

So test bot is finally working again - ready for review :)

Regarding 1 + 3

Date fields, in core or contrib might allow that you enter the date in more than one way. Eventhough the format is hardcoded in html5 date fields, the format the the end users will see is localized. This means that the JavaScript fallback will stick out to the end users.
If we want this to be usable, we need to make it flexible. As I already have made one Drupal 8 site, where I implemeted a fallback JS datepicker, I know that this is a real requirement, which is important for some site owners.

I know we can save a few lines of code by not supporting this, but seeing how few countries actually support the Y-m-d date format (http://en.wikipedia.org/wiki/Date_format_by_country) I vote for making it configurable.

I've addressed the other issues in the review.

Seems patch from #31 was an interdiff as well - uploading the correct patch instead.

I fixed a few lint issues, now I'm finally using the proper Drupal ESLint conf.

Something went haywire in the last patch, so fixed that. Also fixed array using the short syntax instead.

@googletorp - can you describe how to test this?

Unfortunately, it needs a reroll.

Rerolled the patch successfully as per the latest D8 release.

@mgifford To test this, you need to use a browser which doesn't support HTML 5 date fields and edit a date field (fx node creation time).

Before the patch, you need to enter the date by hand, after the patch the jQuery datepicker should be used. You should also test that the jQuery datepicker is not used for browsers that do support native HTML5 date field.

Firefox doesn't support, but chrome does (last time I tested)

I'm an unluckily developer, my clients always blame me and asked "WHY THIS IS DIFFERENT STYLE!!!"

+++ b/core/misc/date.js
@@ -0,0 +1,55 @@
+      if (Modernizr.inputtypes.date === true) {

We should add an option here to save all unluckily developers

This will need an IS and Beta update to it before we can proceed to RTBC. How to test will also need to be added to the IS.

Added beta evaluation, and better issue summary including how to test.

Thanks @googletorp. I'll do manual testing tonight, but I think this is good to go and will improve UX.

@droplet, what did you have in mind? I think normalizing the appearance is definitely out of scope for this issue, though.

+++ b/core/misc/date.js
@@ -0,0 +1,55 @@
+      // Skip if date are supported by the browser.
+      if (Modernizr.inputtypes.date === true) {

it makes sense to file follow-up for "time" that firefox still have no support

OK, got a close look at this. The patch works well, and I think this will be a good addition. I verified it with fields from the DateTime module, as well as timestamp fields (eg, created on entities), and it works as described. Since this works w/ DateTime uninstalled on timestamps only, having the JS live in core/misc/ is a good idea.

1. +++ b/core/lib/Drupal/Core/Datetime/Element/Datetime.php
   @@ -267,7 +267,7 @@ public static function processDatetime(&$element, FormStateInterface $form_state
   -        '#error_no_message' => TRUE,
   +        '#date_date_format' => $element['#date_date_format'],
   

   I am a little confused why this was there in the first place, but why does the patch remove this line?

2. +++ b/core/lib/Drupal/Core/Render/Element/Date.php
   @@ -42,6 +67,7 @@ public function getInfo() {
       * Supports HTML5 types of 'date', 'datetime', 'datetime-local', and 'time'.
       * Falls back to a plain textfield. Used as a sub-element by the datetime
       * element type.
   +   * Adds JS fallback support for browsers not understanding date types.
       *
       * @param array $element
   

   I think this comment is misplaced. Nothing in getInfo() changed. Perhaps this should be added to processDate() instead?

3. +++ b/core/lib/Drupal/Core/Render/Element/Date.php
   @@ -26,14 +27,38 @@ class Date extends FormElement {
   +  public static function processDate(&$element, FormStateInterface $form_state, &$complete_form) {
   +    // Attach JS support, if we can determine which date format should be used.
   +    if ($element['#attributes']['type'] == 'date' && !empty($element['#date_date_format'])) {
   

The comment here is a little cryptic. JS support for what? Maybe when combined with the comment above, a description can be added to processDate, that reads something like "If the element is an HTML5 date a date format is provided, then the necessary attributes are added to enable the jQuery UI Datepicker on the element."

Should be easy to fix, and then I think this is RTBC.

Still trying to triage all of these issues, some of which are pretty old...

But re #48 we already have #1838234: Add jQuery Timepicker for the Time element of the datetime field.

@mpdonadio Thanks for the feedback.

#1 I think this is an error, nice catch, reintroduced the deleted line.
#2 I reworded the comment a bit, to make it more clear.
#3 Same as 2, tried to make the comment a bit more clear.

I think this is good to go. Manual testing w/ Firefox 38.0.5 on OSX 10.10 (latest version as of 2015/06/24) was fine. Removed a bit from the IS that doesn't seem to apply to the patch anymore (datepicker in Seven works fine for me).

I've tested this manually and reviewed the patch changes, looks good to me, RTBC imo.

Committed b04d55e and pushed to 8.0.x. Thanks!

Thanks for adding the beta evaluation to the issue summary.

This change is causing the testbot to generate some exceptions for my tests:

"Undefined index: type Notice Date.php 58 Drupal\Core\Render\Element\Date::processDate()"

I don't see any mention above about API changes that would require me to do something different in my own code that uses a date form element, and I don't see anything above that mentions impact on contrib. (And in fact there's really no documentation on the date form element to begin with ...) processDate() was added by this patch, thus it's not something I invoke directly.

So maybe a change record to tell contrib developers what they need to change because of this patch?

Created followup #2528482: Fix notice in Date::processDate.

@TR can you post in the some info about what you are doing that is generating notices, the root cause could be both core and in your contrib project.

Crossposting from #2528482: Fix notice in Date::processDate ..

To reproduce, create a form with this element:

    $form['adate'] = array(
      '#type' => 'date',
      '#description' => $this->t('Enter a date.'),
      '#default_value' => '',
    );

Just visit the form, no need to submit. The notice will be shown in /admin/reports/dblog.

The nasty-looking HTML generated by this is:

      <form class="datetest-settings-form" data-drupal-selector="datetest-settings-form" action="/admin/people/datetest" method="post" id="datetest-settings-form" accept-charset="UTF-8">
  <div class="form-item js-form-type-date form-type-date form-item-adate form-no-label">
        <input data-drupal-selector="edit-adate" aria-describedby="edit-adate--description" type="date" id="edit-adate" name="adate" value="" class="form-date" />

            <div id="edit-adate--description" class="description">
      Enter a date.
    </div>
  </div>
<input data-drupal-selector="form-blof8rbyocufy2s5dlrfnl3i53jfkgztigfbh2dwqms" type="hidden" name="form_build_id" value="form-blOf8RBYocuFY2S5dLrfnL3i53JfKGztIgfBH2DwQMs" />
<input data-drupal-selector="edit-datetest-settings-form-form-token" type="hidden" name="form_token" value="LC0uSawhPy7bdWDq90CauOpNmlAs_gPngeCmKGkvbtk" />
<input data-drupal-selector="edit-datetest-settings-form" type="hidden" name="form_id" value="datetest_settings_form" />
<div data-drupal-selector="edit-actions" class="form-actions js-form-wrapper form-wrapper" id="edit-actions"><input data-drupal-selector="edit-submit" type="submit" id="edit-submit" name="op" value="Save configuration" class="button button--primary js-form-submit form-submit" />
</div>


</form>

Oh, and the datepicker doesn't work with this example either ...

No need to crosspost; that is what the followup is for. We will work through it there. Thanks!