Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Introduce a primary-danger link/button class for contexts where the primary operation is a destructive one, such as confirm forms for entity deletion. The primary button submits the form and deletes the entity, so it should not be marked blue, but red.
Comment | File | Size | Author |
---|---|---|---|
#31 | delete-confirm.png | 23.11 KB | yoroy |
#28 | Screenshot 2015-04-16 14.10.37.jpg | 233.21 KB | LewisNyman |
#21 | 2015-04-15 19_59_30.png | 13.09 KB | mondrake |
#21 | 2278715-21.patch | 1.73 KB | mondrake |
#17 | primary-danger-class-2278715-17.patch | 2.46 KB | cmanalansan |
Comments
Comment #1
LewisNymanComment #2
cfox612 CreditAttribution: cfox612 commentedIs this for a specific theme? Both Bartik and Seven? All core themes?
Comment #3
XanoThis must be theme-agnostic, because the classes will be set in module code.
Comment #4
LewisNymanThe 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.
Comment #5
cmanalansan CreditAttribution: cmanalansan commentedI added the CSS classes only, but did not update any styles to any themes.
Comment #6
LewisNymanAll 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
Comment #7
lauriiiCreated 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:
Comment #8
cmanalansan CreditAttribution: cmanalansan commentedI 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:
primary-danger
. Any elements with this #button type will have the classbutton--primary-danger
button--primary-danger
- OR -button--primary
andbutton--danger
- OR -button--primary
,button--danger
, andbutton-primary-danger
The best approach here depends on this question: what do you aim to benefit from changing the #button_type?
Comment #9
cmanalansan CreditAttribution: cmanalansan commentedPardon me, did not mean to remove focus.png file
Comment #10
cmanalansan CreditAttribution: cmanalansan commentedActually, I agree with lauriii, I'm currently extending his patch to include ContentEntityConfirmFormBase and EntityConfirmFormBase
Comment #11
cmanalansan CreditAttribution: cmanalansan commentedBased on lauriii's patch.
Comment #12
Bojhan CreditAttribution: Bojhan commentedI 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.
Comment #13
XanoI am not familiar with the existing class for remove actions, but this issue is about a generic approach for any primary button that performs a dangerous action. Would you say that is unnecessary, an addition to the remove class, or a replacement for it?
Comment #14
LewisNyman@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.
Comment #15
Bojhan CreditAttribution: Bojhan commented@Lewis Sure :)
Comment #16
cmanalansan CreditAttribution: cmanalansan commentedI went ahead and removed the changes to the Seven theme.
Comment #17
cmanalansan CreditAttribution: cmanalansan commentedAck, disregard patch 16, this is the correct one.
Comment #18
idebr CreditAttribution: idebr commentedHow does this relate to the danger button that is being added in #2123731: edit CSS file using .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?
Comment #19
LewisNyman@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
Comment #20
idebr CreditAttribution: idebr commentedWhat 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:
It doesn't seem like we should introduce a new UI element at this stage.
Comment #21
mondrakeJust 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:
Comment #24
mondrakeGreen.
Comment #25
Bojhan CreditAttribution: Bojhan commentedNope, we are not doing this. Please see the style guide https://groups.drupal.org/node/283223
Comment #26
LewisNyman@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?
Comment #27
Bojhan CreditAttribution: Bojhan commentedI don't think we should have "red" buttons. I think we should only have deletes that are styled as links.
Comment #28
LewisNyman@Bojhan Do you mean like this?
Comment #29
lauriiiLOL thats awesome UX!
Comment #30
Bojhan CreditAttribution: Bojhan commentedHmmpf, 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.
Comment #31
yoroy CreditAttribution: yoroy commentedWhat 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.
Comment #32
LewisNymanMakes sense to me.