Support to no javascript browsers

Closing my own #1975460: Use select element instead of textfield for fallback as this is older.

Compleatly agree. First step probably would be to use select element instead of textfield. Textfield makes field unusable with JS off. It is possible to base it on select element, it's should be not that hard/different. It would be much needed first step.

Comments? Should we try that?

I'm not thinking that far yet. Babysteps. Let's just change textfield to select to enable bare bones fallback if JS is off. As for new terms, levels and page reload, I'm not sure that will be easy task. Got to experiment.

Didn't know what I've tried before but it was a somehow very simple solution.
Committed to 7.x-1.x-dev so it will be available in the next development and full release.

@stBorchert Did you test new select element with adding new terms? There could be a problem with validation (fix is also not hard). If select element returns value that was not been in that select element before, Drupal will set error "An illegal choice has been detected. Please contact the site administrator."

If you test and see this error, drop me a line here. I am writing new module that could provide ideas and solutions to SHS too.

The features "add new terms" and "add new levels" are not available without JavaScript so I doubt there will be errors ;)

Wait, but if JavaScript is enabled and new terms added, then form will still return values that were not in select element before. Even if terms are created with AJAX call.

Currently I am making custom module that does magic thing. I use FAPI multiple select element + fork of Chosen to create very simple (4 functions) fake autocomplete field with add term option.

My select element was angry that I tried submit form with values that were not known during hook_field_widget_form(). It's because of _form_validate() thats gets called on all select elements. More info here...

Anyway, for future reference:

/**
 * Implements hook_field_widget_form().
 */
function MODULE_field_widget_form(&$form, &$form_state, $field, $instance, $langcode, $items, $delta, $element) {

  // Something, something.

  $element += array(
     // Add usual fapi stuff for select.
     '#after_build' => array('kill_default_validate'),
     '#element_validate' => array('my_own_validate'),
    );
  }

  return $element;
}

function kill_default_validate($form_element) {
  unset($form_element['#needs_validation']);
  return $form_element;
}

/**
 * Element validation callback for field widget hierarchical select element.
 */
function my_own_validate($element, &$form_state, $form) {
  // Better validate, with hookers and blackjack.
  form_set_value($element, $value, $form_state);
}

The special validation handling has been committed some time ago but your comment reminded me about some JavaScript I forgot to push: the new item needs to be appended to the original select so it can be set as value.

Thanks for the hint :)

Just noticed that the views exposed filter widget gets given an element-invisible class, meaning that the fallback select field is invisible by default and if javascript is disabled will never appear.

Without that class it the fallback appears to work fine. I'm not sure if the class was added to prevent visual stutters but maybe it should be an option to either have it displayed by default for accessibility or hidden for better (with-js) UX but with a warning that it will break the fallback.