Add start date and end date labels

These labels were intentionally removed to help save some space and de-clutter:
See #1233612: Add a checkbox so user can choose to show/hide the end date

Personally, I would rather implement #1248720: In-Line 'End Date' with 'to' text. than add the Start/End labels. The 'to' text makes the dates self-explanatory, IMO.
However, #1248786: Fix appearance of marker for required date fields probably needs some attention too.

I like the idea of inline with a "To" string connecting them, but I'm not completely sold. Here's a list of pros and cons as I see it

Pros
1. saves vertical scrolling
2. same interaction as google calendar

Cons
1. Setting up a date is not performed this way. During setup, we ask people if they want to collect an "end date" which saves a lot of the confusion that previously existed with the 'to' date. I'd hate to bring that back.
2. 'to' is a very small word, and unlike google calendar which stands out amongst 4 select boxes, our date controls can have 12 select boxes, to which a single 'to' string could get drowned out.
3. no label what-so-ever on the start or end could be an accessibility issue (only somewhat certain). I.e when a screen reader hits this, its going to read aloud: Year, Month, Day, Hour, Minute, Second, To, Year.... Only after hearing To and Year might a blind person be able to connect the dots.
4. While less scrolling, it's really not more usable. That is, there's still the same amount of information on the screen (but takes up less vertical space).
5. This leaves us with the required issue. Which honestly doesn't sound like there's a great answer to. We can't make the legend show required. We can make all all date granularity options required (Y, M, D, H, M, S) as I'm told time is really not required. We could put an asterisk on only those that are required (Y, M, D) but doing so feels like a lame solution.

Having said all that, I guess Im in favor of leaving its formatting stacked.

If there are demos of the UI being discussed, I would be happy to give some feedback from an accessibility perspective. Even if the backend of the form isn't connected to anything, I can still evaluate the frontend

I have tried at different times to float the start and end dates next to each other, and when you have select widgets with all those elements it gets ungainly very quickly. Plus I had problems getting the right things to float without running into other css problems (like floating elements that escape their containers in some browsers). So while it seems nice when using small elements (like the popup dates, especially if they don't have any time), it gets ungainly for large ones plus the cross-browser issues begin to get dicey.

The required marker is also problematic because we can have such a multitude of date sub-parts and the system error processing can interfere with what the date module is trying to do. I've tried handling this in different ways over the years, with mixed results. Let's leave that issue out of this one though.

I think what I will do is commit this patch for now, just to add some clarity that I suppose has been lost. We already have separate issues about floating the dates next to each other and fixing the required flag. Let's deal with those questions in those issues as a feature request and bug report, respectively.

A couple problems. The labels are misformed for some widgets, the last rule needs to be something like the following, so it will work everywhere:

.field-widget-date-select .form-item.form-type-date-select > label,
.field-widget-date-select-repeat .form-item.form-type-date-select > label,
.field-widget-date-text .form-item.form-type-date-text > label,
.field-widget-date-text-repeat .form-item.form-type-date-text > label,
.field-widget-date-popup .form-item.form-type-date-popup > label,
.field-widget-date-popup-repeat .form-item.form-type-date-popup > label {
  margin-top: 0.5em;
  padding-left: 10px;
  margin-bottom: -10px;
  text-transform: uppercase;
}

But more importantly, I remember now why I got rid of those labels in the first place (in addition to cleaning up the look of things). With this change the first date always is labeled 'Start Date', even when the optional end date is hidden. That label should be hidden if there is no end date, but I don't know any way to do that for the dates that are being dynmically altered using #states. It looks very odd to have a single date that is labeled 'Start Date'.

Tagging.

This item is waiting on someone to provide some javascript functionality. I'm hoping someone can provide a patch.

Not a release blocker

Only adds a wrapper class to the patch in #11.
This helps to target start date and/or end date wrappers through CSS.

Patch applies and does what is expected.

Considering the "Start Date" label issue, could combine this with #1248720: In-Line 'End Date' with 'to' text. via replacing t('End date') with t('to') and remove Start date. Also, moving the toggle checkbox below the start date may make more sense than above?

I liked hefox's suggestion in #14, it eliminates the need for the javascript, & keeps things more compact & simple.
So I am committing that for now, but discussion here can continue...
commit: http://drupalcode.org/project/date.git/commit/a5c66a5

I did not apply the rest of the changes, however.
See questions & comments below:

+++ b/date_all_day/date_all_day.module
@@ -197,7 +197,7 @@ function date_all_day_date_combo_process_alter(&$element, &$form_state, $context
-      '#title' => t('All Day'),
+      '#title' => t('All day'),

What is the reason for this change? Even if it should be changed, this should not be in this issue, but rather, a separate issue, IMO.

+++ b/date_api/date.css
@@ -227,3 +227,10 @@ div.date-calendar-day span.year {
+.field-widget-date-select .form-item.form-type-date-select > label {
+  margin-top: 0.5em;
+  padding-left: 10px;
+  margin-bottom: -10px;
+  text-transform: uppercase;
+}

What is the reason for this css addition/change? I did not notice any placement or layout changes.

+++ b/date_elements.inc
@@ -293,7 +293,7 @@ function date_combo_element_process($element, &$form_state, $form) {
-    '#title' => t('Show End Date'),
+    '#title' => t('Enter different end date'),

+1: This looks like a good idea to me, but belongs in a different issue.

I'm right now trying to change the labels for a particular date field and I'm having some trouble. I'm not sure how I can get at the markup coming from process_data_combo().

I would think a simple solution would be to have these labels be configured by field. So, there would be label variables in field settings for "Start Date", "End Date", and "Show End Date" with these default filled in. Then the person creating the field could configure it. These could be put in the already hidden More values fieldsets so they wouldn't clog up the form.

I figure there must be some kind of reason that such a simple solution wasn't chosen for this issue. I could provide a patch to do this if desired, but I'm hesitant to do so if it's unlikely to get sommitted.

Actually I figured out how I can change these things locally. Go D7 Render API!

Since date_combo_process() calls drupal_alter(), this was pretty easy to do. I just added this hook:

function mymodule_date_combo_process_alter(&$element, $form_state, $context) {
if ('field_mydates' == $element['#field_name']) {
$element['value']['#title'] = t('Custom Start Date Label');
$element['value2']['#title'] = t('Custom End Date Label');
$element['show_todate']['#title'] = t('Custom End Date Checkbox Label');
}
}

Very easy, now that I know how to do it.

I was not able to use the code suggested in #17 since I am using date popup fields, but I was able to insert From and To labels into a date field (named field_mydate) on a node form using the CSS3 content property:

/* CSS3: Insert "From" and "To" labels in start/end date popup field for date field */
.node-form .date-no-float .form-item-field-mydate-und-0-value:before {
  content: "From:";
  display: block;
  clear: both;
  font-size: 10px;
  font-weight: bold;
}
.node-form .date-no-float .form-item-field-mydate-und-0-value2:before {
  content: "To:";
  display: block;
  clear: both;
  font-size: 10px;
  font-weight: bold;
}

Start Date & End Date should really be LEGENDs and not LABELs. Semantically you're dealing with a group of related input types. Adding a legend here would be impossible to link to any one input field.

It would be a big improvement for accessibility for this to be just taken care of in Drupal 8, especially with #501428: Date and time field type in core

That will work only if start and end date are each fieldsets. There is an issue about making fieldsets optional (#1467712: Make it possible to disable fieldset for date field), there are people already complaining that there should be no fieldsets, plus there are no fieldsets on single value fields, and sometimes the fieldset is a wrapper around both dates, not an individual date. So 'legend' is not always going to be appropriate. Label is the only thing that will be consistently available.

I don't disagree with the idea of making things more semantic, just not sure how it's going to work in practice. Obviously it will completely break existing sites so could only happen in a new version.

Well Drupal fieldsets are presently a bit of a hack. There's an effort to configure this more semantically in core for D8:
#504962: Provide a compound form element with accessible labels

Fieldsets have been basically misused by Drupal to manage a collapsible UI element. http://www.w3.org/wiki/HTML/Elements/fieldset

The element represents a set of form controls optionally grouped under a common name.

#18 worked for me. Thanks for the tip!

I changed it a little so that it could replace the existing labels instead of just pre-pending the new content and so that it wouldn't affect the "time" or "to" labels:

/* CSS3: Insert "From" and "To" labels in start/end date popup field for date field */
.node-form .date-no-float .form-item-field-date-und-0-value-date:before {
  content: "Start Date";
  display: block;
  clear: both;
  font-size: 10px;
  font-weight: bold;
}
.node-form .date-no-float .form-item-field-date-und-0-value2-date:before {
  content: "End Date";
  display: block;
  clear: both;
  font-size: 10px;
  font-weight: bold;
}

.form-item-field-date-und-0-value-date label, .form-item-field-date-und-0-value2-date label {
  display:none;
}

Solving content issues with CSS3 is not ideal. For people using the date_popup field you can do the following:

In your custom module add this function.

/**
 * Implements hook_date_combo_process_alter().
 */
function <modulename>_date_combo_process_alter(&$element, $form_state, $context) {
  if ('<fieldname>' == $element['#field_name']) {
    $element['value']['#date_title'] = '<date1label>';
    $element['value2']['#date_title'] = '<date2label>';
  }
}

In your template.php file add this function.

/**
 * Returns HTML for a date_select 'date' label.
 */
function <themename>_date_part_label_date($vars) {
  if ('<fieldname>' == $vars['element']['#field']['field_name']) {
    return t($vars['element']['#date_title']);
  } else {
    return t('Date');
  }
}

With the date popup form, I had a slightly different solution based on #23 adding the following to a custom module:

/**
 * Implements hook_date_combo_process_alter().
 */
function <modulename>_date_combo_process_alter(&$element, $form_state, $context) {
  if ('<fieldname>' == $element['#field_name']) {
        $element['value']['#instance']['label'] = 'Start date';
        $element['value2']['#instance']['label'] = 'End date';
        unset($element['value2']['#title']);
  }
}

My code might be slightly different because in the advanced date field settings I had ticked the box: 'Render as a regular field'.

I didn't need to add anything to the template.php file.