Change wizard-trail style and remove " » "

The problem is that this change is really only relevant is "free trail" is set to true. Sometimes it truly IS a trail and the items are not clickable, and sometimes it is more of a menu and the items are clickable.

There's some work in a branch of CTools to create a Page Manager style UI as a general CTools Export UI pattern. That might ultimately be a better fix since it changes stuff like this to vertical tabs. That may, ultimately, be the right way to handle these things.

There's no issue, but I believe the branch is operations-ui (in CTools) -- the actual work is for the pipeline UX in Panels (pipelines branch in Panels). Ideally we would've had that completed prior to Drupalcon but sdboyer got busy with non-Panels stuff and didn't get to the point where we could merge that into the mainstream.

It's some pretty complicated work.

Also for consideration: #1775234: Local tasks on MiniPanels edit pages are confusing

a

In the interest of resurrecting this, how about just changing the DOM structure ever so slightly so that it appears as pseudo local tasks, ala #1775234: Local tasks on MiniPanels edit pages are confusing?

Problem

This issue arrised for me when handling the new Openlayers 3 interface (see #879130: Alter the use of "Clone" for exportable objects in code).
I also read the thread in #1775234: Local tasks on MiniPanels edit pages are confusing
But I don't like the approach for the fix there.
2 remarks:

1. If the wizard is indeed a wizard trail it should include a progress bar and preferably numbering.
2. Styling elements such as ">>" should not be included in the html output but in the css.

In #1775234 they've chosen to overwrite the divider and align the list to the right.
But what really should be done is:

1. remove the divider from the html output.
2. change the wizard trail so it resembles an ordered list <ol>
3. apply some default styling so the list items display as inline blocks
4. remove all occurrences where the wizard trail is a "free trail", this is semantic nonsens. A free trail is just another level of navigation. Also if it really is a free trail the double arrows dividing them make even less sense.

Just take a look at some UI patterns concerning wizards: http://ui-patterns.com/patterns/Wizard or https://www.pinterest.com/ruth77rn/ui-patterns-wizards/
The Drupal 8 Seven theme proposal overhaul for secondary tabs is also interesting: https://groups.drupal.org/node/283223#Navigation_Tabs

Proposal

For real wizards we adopt an ordered list like so:

function ctools_wizard_theme(&$theme) {
  $theme['ctools_wizard_trail'] = array(
    'variables' => array(
      'trail' => NULL,
      'form_info' => NULL,
    ),
    'file' => 'includes/wizard.theme.inc',
  );
}

/**
 * Themable display of the 'breadcrumb' trail to show the order of the forms.
 */
function theme_ctools_wizard_trail($vars) {
  if (!empty($vars['trail'])) {
    return theme('item_list', array(
      'items' => $vars['trail'],
      'attributes' => array(
        'class' => array('wizard-trail'),
      ),
      'type' => 'ol',
    ));
  }
}

Next we remove the option for a "free trail" and output these situations as stated in #2
Furthermore, the wizard should probably include a "active" theme variable to style the finished wizard elements and the current / future elements independently. For style I propose building on the study done in https://groups.drupal.org/node/283223

Here's a simple patch. Should be reviewed for both free trails and linear trails.
If you must use the divider as it was, the " » " can be reintroduced with css by adding:

.wizard-trail li:after {
  content: "»";
  display: inline;
  padding: 0 1em;
}

.wizard-trail li:last-of-type:after {
  content: "";
}

Oh, and it needs a review.

The 4 year old patch in #13 to wizard.css and wizard.theme.inc does not apply to the latest ctools 7.x-1.x-dev and if still applicable needs a re-roll.

Checking patch css/wizard.css...
error: while searching for:

.wizard-trail {
  font-size: 120%;
}

.wizard-trail-current {
  font-weight: bold;
}

error: patch failed: css/wizard.css:1
error: css/wizard.css: patch does not apply
Checking patch includes/wizard.theme.inc...

Here's a new patch... not 100% sure how relevant this still is though. Old remarks about styling and hardcoded >> still apply.