Introduce a primary-danger link/button class

Is this for a specific theme? Both Bartik and Seven? All core themes?

The button_types are set in module code, but what a theme chooses to do with it is up to them. We only need to implement the CSS in Seven for now in my opinion.

I added the CSS classes only, but did not update any styles to any themes.

All the other button class variants are set with using #button-type correct? Shouldn't we be using that here? In any case the class that would need to be added would be button--primary-danger

Created a style for the button with the danger color presented in the Seven style guide.

I think we should use the button type functionality because it doesn't require any extra code.

Here's pictures of the button:

Normal:

Hover:

Focus:

I changed the class to button--primary-danger.

One thing to consider before deriving this class from #button-type:
#button-type only stores one value. From what I can tell, it can be either 'primary' or 'danger' but not both.

We can address this in several ways:

1. Create a third #button_type called primary-danger. Any elements with this #button type will have the class button--primary-danger
2. Change #button_type to be an array instead of a string. Any elements with #button_type => array('primary', 'danger'):

• ... will have the class button--primary-danger - OR -
• ... will have the classes button--primary and button--danger - OR -
• ... will have the classes button--primary, button--danger, and button-primary-danger

The best approach here depends on this question: what do you aim to benefit from changing the #button_type?

Pardon me, did not mean to remove focus.png file

Actually, I agree with lauriii, I'm currently extending his patch to include ContentEntityConfirmFormBase and EntityConfirmFormBase

Based on lauriii's patch.

I am not following this, this is about adding a class. The Seven style guide already has a style for remove actions. This patch shouldn't change anything about Seven.

@Bojhan Can we consistently call the 'remove' class the 'danger' class to reduce confusion? That's how it's set up in the CSS files and we should be describing it's purpose instead of one use case.

@Lewis Sure :)

I went ahead and removed the changes to the Seven theme.

Ack, disregard patch 16, this is the correct one.

How does this relate to the danger button that is being added in #2123731: Add .button:not(a.button--danger) so that no reset is needed on button--danger? Are we creating both a link--danger and a button--danger?

@idebr yes maybe that is the most sensible way to do it, as this danger button styling shares a lot of styling with other buttons

What would be the use case for 'link--danger' if there is already a 'button--danger' with the exact same styling? Is the scope for this issue limited to link--danger or does it also touch button--danger?

Either way:

1. The last patch is inconsistent with the proposed resolution
2. @Bojhan in #12:
   

   The Seven style guide already has a style for remove actions. This patch shouldn't change anything about Seven.

   It doesn't seem like we should introduce a new UI element at this stage.

3. And if we do, the patch needs the CSS for create the link styling

Just had a try combining #7 with parts of #2469929-18: The confirmation forms' cancel link should be styled as a button, just to see how it looks. Screenshot on top of #2469929: The confirmation forms' cancel link should be styled as a button.

Screenshot:

Green.

Nope, we are not doing this. Please see the style guide https://groups.drupal.org/node/283223

@Bojhan But the styleguide is not a static design, we're proposing an addition to fill a gap in the styleguide. Or we should add guidance on which button type to use when the action is both primary and dangerous. What do you think?

I don't think we should have "red" buttons. I think we should only have deletes that are styled as links.

@Bojhan Do you mean like this?

LOL thats awesome UX!

Hmmpf, I guess neither options are really nice.

I am not sure if the delete button class is the right direction though, it will most likely be abused a lot. When its "Delete | Cancel" its kinda fine. But when its Save | Delete for example, you really don't want this.

What I see under OS X is that even the confirmation dialog of a delete action does not make the delete action the primary one.

If it's a destructive action, maybe it's indeed better to deliberately *not* present the second button/link for confirming the deletion as the primary one. In short, I'm not convinced we need to do something about this.

Makes sense to me.