Inline Date Picker?

This is not possible through the Webform interface. You'd need to custom theme your form to remove the date field and display it as a calendar instead.

I was also looking for this! I think having a feature to display the calendar open by default and without the dropdown menus (unless JS is disabled) would be a FANTASTIC feature!

I'm not currently planning on adding this as an option.

I'd like to add my support for this feature. I think I have a place where this would be useful.

I started work on this and http://drupal.org/node/301949. The attached patch includes this inline option and maximum and minimum inline date options.

The inline option needs better css changes. Don't know if I will get back to finish this so I thought I'd at least share what I have.

Ideally I think an option to turn the date fields into hidden fields so that there is just an inline calendar would be nice to have.

New patch. Removed drupal_set_message debug alert. Sorry

I'd strongly suggest separating out the inline date picker from the min and max date. That feature is over here: #301949: Add option to only allow dates in the past/future.

Oh, you've actually uploaded the patch in *both* places. Please separate them and submit them individually.

As for the "inline" portion of this patch:

- The class names webform-calendar-inline-0/1 is pretty clunky.
- You should use the Webform webform_strtotime() and webform_strtodate() which use PHP 5's Date objects and proper timezone handling instead of the notoriously timezone-challenged strtotime() and date() functions.
- What happens if JavaScript is turned off with this patch?
- There's a lingering console.log(inline); in the code.
- Please use two spaces instead of tabs in your code, I'd suggest updating your text editor preferences to make this the default.

I'll comment on your date range patches in the other issue.

Anyone ported this to D7?

Inline only patch for D7. Javascript not enabled is no datepicker at all, not inline, not on clicking. Also in the inline case it does not replace the date input fields, it only augments them. So I don't see any problem with js disabled.

Oops, removed the console.log statement, but forgot to save the file before creating the patch. Here's another one without console.log

Thanks @fietserwin! I'm impressed how trivial this implementation is! The only thing that gives me slight pause is that "Enable popup calendar" is a separate option from "Inline calendar". These two options really aren't meant to be used in conjunction with each other, rather they are alternatives. There's no real need for a user to check both boxes for "Enable popup calendar" and "Inline calendar", but if the user does not, the calendar does not work because the JS library is only added if the first checkbox is checked.

Rather than using checkboxes, I think we should switch the Calendar options to a set of radio button:

Date picker options:
(•) Popup calendar
( ) Inline calendar
( ) No calendar

Internally, I don't have much preference about whether these are multiple FormAPI properties or a single one, but the single approach would probably be the easiest implementation. Rather than "datepicker" being a boolean 0 or 1, we could also give it the special key "inline", to inform the element to use the inline picker rather than a separate property #inline.

Overall, this is a fantastic patch and I'm thrilled you've taken the time to make it. If we can eliminate the UI problem by switching to radio buttons, I think this patch is good to go.

I only chimed in as the inline datepicker is a good test case for the long outstanding issue #507502: (needs documentation) Provide Locale support for jQuery UI. That issue circles around a js load/execute order, and I solved that problem by wrapping the js in an attach behavior. But I had some doubts if it still would work if anyone would want to open a datepicker directly. Although I did not find this a "realistic" situation, ace11 entered the discussion and pointed to this issue. So apparently there is a use for it, and my patch from the other issue works with an inline datepicker when people do inline it in an attach behavior, like this patch already did.

To test it myself I had to adapt the patch from #6 to D7 and remove the min/max date parts. I did not really look into UI concerns or other optimizations. But I guess that you are right: showing that small calendar to pop-up a calendar is not needed anymore. The reason that this patch is so easy is the flexibility of the datepicker itself: inline datepicker.

So, I will probably not further adapt this patch, but hope that others can now pick it up and make it "production quality".

Oh, and if anybody can enter in on #507502: (needs documentation) Provide Locale support for jQuery UI to get it to RTBC, the datepicker that webform uses can finally be localized (inline or popup).

This patch needs work per #11. At this point new features are only being added to the 4.x branch.

Closing for lack of activity.

Hi all !
Years later, pushing for this to happen !

Compared to #10 I changed the following:
- changed the component edition to choose via a radio from datepicker inlined, popup or none as per #11.
- not rendering the calendar input when in inline mode
- moved the div for the inline calendar from "render" method to webform-calendar.tpl.php just as per the calendar popup button => this may not seems logical to all, let me know.
- hide the input date select box by default when using the inline calendar.

Thanks for reviewing !

Maybe also, we can have inline-block display rather then inline ?

.webform-container-inline div, .webform-container-inline div.form-item {
    display: inline-block;
}

Hi,

update patch for last 7.x-4.x-dev (also work with 7.x-4.15)

@Dom thanks for your patch.

I am not sure whether we should align this with date module.

After enabling Date popup calendar module it changes date field it inline field. I propose the same. Rather than showing a checkbox to enable popup we can create a sub-module which will change field to inline field. I am happy to work on this. Thoughts?

It would make sense to match what other parts of Drupal are doing. I would also like to have support for the HTML 5 date input type to get access to native date controls. For this there needs to be a fallback for browsers that don't have support.

Hi,

update patch for 7.x-4.22

@Dom thanks for your patch.