Background

  1. #1845728: Refactor and introduce generic button CSS styles for forms and links revamped and generalized the CSS for all possible buttons:

    .button,
    button
    

    Note: Seven does not implement styles for .button.

  2. #1238484: Ability to mark the form buttons to be of a specific type (so that they can be styled differently) advanced on it and introduced support for specific button "types":

    $form['actions']['submit']['#button_type'] = 'primary';
    $form['actions']['delete']['#button_type'] = 'danger';
    

    .button--primary { color: blue; }
    .button--danger  { color: red; }
    

    Relevant case study: http://www.lukew.com/ff/entry.asp?571

    #button_style is not limited to 'primary' and 'danger'. The value is simply taken over as .button--$value CSS class name. See http://getbootstrap.com/css/#buttons for common button types.

    Note: Bartik does not implement styles for .button--danger.

  3. Based on the last two building blocks, #1719640: Use 'button' element instead of empty links introduced dynamic/on-page buttons for JS interactions which masquerade as links, in order to avoid <a href="#"></a> as well as href="javascript:void(0)":

    <button type="button" class="link">Show summary</button>
    
    /**
     * Show buttons as links.
     */
    button.link {
      background: transparent;
      border: 0;
      cursor: pointer;
      margin: 0;
      padding: 0;
    }
    

    Note: Styling is broken in Bartik (faulty font override).

  4. #216064: Entity form "Delete" button triggers server-side + HTML5 form validation; change "Delete" button to a link is about to convert all "Delete" buttons into links, so as to avoid HTML5 front-end form validation and needless back-end form processing code:

    $actions['delete'] = array(
      '#type' => 'link',
      '#title' => $this->t('Delete'),
      '#attributes' => array(
        'class' => array('button', 'button--danger'),
      ),
    );
    

    <a class="button button--danger" href=".../delete">Delete</a>
    

    Note: That patch will not adjust/fix the link button styles in Bartik/Seven.

Goal

  1. Every button has a .button class or is a <button> or [type=submit] or [type=button].

  2. By default, every link in a form actions container has a .button class, so as to appear as a button. A theme is easily able to override this.

  3. Every link/button that (1) will trigger a confirmation for a destructive action or (2) immediately causes a destructive action uses .button--danger. A theme is easily able to override this button type styling (in both places).

CommentFileSizeAuthor
#2 drupal8.link-button.2.patch1.22 KBsun
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

LewisNyman’s picture

Note: Seven does not implement styles for .button.

Did you mean ? We only have styling for the class in buttons.css

sun’s picture

Status: Active » Needs review
FileSize
1.22 KB

@LewisNyman: I'm no longer sure whether the statement in the issue summary is correct. I encountered a CSS problem in Seven when I manually tested #216064: Entity form "Delete" button triggers server-side + HTML5 form validation; change "Delete" button to a link — that is about a.button though, not sure whether that makes a difference. — That said, perhaps I was also just terribly confused, because I wasn't aware that Seven intentionally wants to style danger buttons NOT as buttons, but as links instead...? ;)


Goals 2 + 3 of the issue summary do not have a proper solution yet — a discussion about that is what actually triggered this issue.

We discussed whether it would make sense to introduce a new #type 'link_button', which would denote the user interface concept of a link that is supposed to perform an action (as opposed to a navigational link).

That is, because a "link as button" is a unique UI concept. Developers should not have to specify the necessary element #properties manually, because doing so will only lead to inconsistencies. At the same time, themes should be able to identify all "links as buttons", in order to be able to customize them.

However, when I just wanted to whip up a conceptual patch, I noticed that we could simply embed support for #button_type into the existing #type 'link'...?

Attached patch shows what I mean.

sun’s picture

Assigned: sun » Unassigned
Status: Needs review » Active

Alright — since this is a meta issue, I've created a dedicated issue for the proposed change + patch + test coverage:

#2243575: Add #button_type support for #type link

andypost’s picture

is this issue valid still?

joelpittet’s picture

Status: Active » Closed (works as designed)

Closing this as we are attempting to move classes to the template and removing classes from core so CSS frameworks don't have to 'undo' as much stuff to theme from scratch.