Delete buttons look disabled in Seven theme even though they're not

It looks like this style is being applied for: form input#edit-delete

In skimming through mockups, the only place I've found a similar style so far is this mockup: http://www.flickr.com/photos/mverbaar/3659316803/in/pool-drupalredesign which does indeed seem to be intended as a disabled style (if I'm reading the functionality of that page correctly).

Does any of the other buttons look like that? A screenshot would be nice.

It's being applied on all form input#edit-delete {} so I would assume all delete buttons

I think none of the mockups had the delete button displayed in a special way, so this CSS is a remnant of how Young Hahn layed out the theme initially. As far as I remember, he used a darker color for the button background, unlike the d7ux.org mockups, so using this layout for the delete button might have made sense. Since it was not on the mockups, I think we should just remove it.

Though the patch in #6 applies it looks like it is truncated. ( that could be my misread of the patch though ).

After applying the patch I still see the delete button on the Role - Edit page. I'm not sure what the intention of the patch was since it seems as if the patch was going to remove the delete button or make it a link like I how Garland formats delete "links". I don't see how that would have been achieved with only a css patch.

Annoyed me too.

Re-rolled to keep up with head. Approach looks good to me. Before and after screenshot & new patch attached.

Is it the intent of this issue to simply allow the button to appear the same as the "Save role" button or is it to make the delete role appear as a link?

#9: delete-button.patch queued for re-testing.

I don't see any reason why delete buttons shouldn't look like the other buttons (this patch applies to all delete buttons)

patch in #9 does that

I went through the mockups to check: http://skitch.com/yoroy/n5yqp/buttonz

The idea is/was to make the primary action a blue button, not to make secondary actions look disabled. (80% use case is to hit save/submit)

It's a pity that we now lose the distinction though. So this fix also breaks something and I'm not sure if overall we are better off with this patch here.

Is there a way to make only the last-submit-button-on-the-page a blue one?

It's been my experience that the "Save" action is often the first in the list.

Here is a quick skitch of a rule that would apply to the first submit button in a form

http://skitch.com/jameselliott/nhhjq/first-child

This quick rule obviously has some drawbacks

http://skitch.com/jameselliott/nhhj4/error

also note that IE6 does not support the :first-child pseudo-selector -> http://www.quirksmode.org/css/firstchild.html

@seutje Is IE6 not supporting the :first-child really an issue? Let's call it progressive enhancement.

A bigger question is whether we should simply assume that the first submit button should be highlighted. I could see that being problematic, especially in contrib. How about we start a new issue for that, saving this for the delete button styling as this should be changed either way.

I really don't think that's an assumption we can make

@yoroy the patch in #9 just removes the rules that make #edit-delete gray, if we simply add rules to make #edit-submit blue, would that be good for u?

actually, feels kinda odd to be using IDs for this, .form-submit perhaps?

seutje: sounds good, the .form-submit being the primary interaction is an assumption we can make, no? Go for it.

hmmz, turns out pretty much everything uses that class

I noticed the styling for this was this in the stylesheet, but the selector no longer applied (div.node-form), so I just changed that selector

I don't rly know why that edit-submit-1 is in there though, I guess it's for when there's more than 1 form on any given page, but that seems like a crummy solution

anyway, this makes the submit button (and only the submit button) blue, and it removes the graying out of the delete button

On the 'add content type' page:

On the 'Performance' page:

Aha! On the 'People' page:

Search block on the Dashboard:

Edit image style:

Edit vocabulary:

Visual review only, I didn't dig for the CSS selectors causing this…

.form-submit is going to be on any buttons that have a form action attached. Delete and Save both submit the form, but with different actions.

I'm also not a fan of adding this primary function styling on an ID basis. It means you're going to have an extending list of selectors to apply the style.

I think perhaps the best solution would be to add a .primary-action class with a theme hook.

this is just me thinking out loud, the way I did this is probably not the most elegant way, so I'll go pull some sleeves to see if they can think of a better way

different approach, feels slightly cleaner as it doesn't require a form.inc hack, but feels silly to use 2 IDs in a selector

screenshots:
node edit form
ppl page
dashboard (fekk?)
edit term

any others?

content type editing
blocks
delete confirmation
appearance
theme settings
modules
permissions
path module config
edit menu (FFFUUU- why does this suddenly get an edit-actions-submit ID instead of just edit-submit like all the others?)
menu link edit page

Sub.

What do folks think of last patch?

Its far from there yet and we haven't discussed any actual strategy on why we should blue or not blue certain buttons. For this late in core freeze, I think its very unwise to make a swift decision on this.

It's too late for that crazy blue button thing, but the original bug report about delete buttons looking disabled when they're not is still valid:

Would be nice to see this fixed. I almost filed a bug report against Field API about the fact that I couldn't delete a content type until I realized it was just a theme bug.

Possibly related: #846182: Seven theme form buttons have no hover state

#9: delete-button.patch queued for re-testing.

@webchick - What about the patch in #9 that simply removes the styling? That should be a quick and simple fix for the bug. Anything else can come in a later release or be part of D8.

@rickvug That just brings back the problem we where trying to solve of it having the same importance, thus likely to get clicked accidently.

The thing we can try is to adjust its visual for it to still look "less" important, but not "disabled" anymore - not sure if thats possible. So making it more of a darker gray (but not completely same as the other).

@webchick Sorry, but this is a known issue and we cannot solve it properly without breaking UX freeze. If you feel its important enough to do so, I gladly would - but the only thing we can really do is adjust the shading a bit, and pray for the best :)

Well, this definitely is a nasty bug that's likely to result in all sorts of support requests, so yes, we should fix it. But we also can't do #22 at this stage. It's way too much.

#9 would be perfectly fine with me. To me, the importance factor is already established by position: the button one on the left is always the most important (and is the default thing that gets clicked when you hit 'enter' in the form), followed by the next most important, etc. Pretty much all forms on the internet work this way.

@Bojhan - I agree that de-emphasizing delete is an important UX consideration and #9 does not address the problem at all. However this position is better than delete looking like it is disabled. Work could then be done on a more permanent solution.

Even when pretty much all forms work this way, there is still a lot we could assist in preventing such mistakes. Hence why its visually less important, as richvug mentions #9 does not address this problem.

I know that half-assed UX solutions are normal at this stage of development. So fix it, but please keep the issue open - because we have not solved it, we just removed one ux bug to introduce a new ux bug :) - probably less important, but still.

#9: delete-button.patch queued for re-testing.

The patch in #9 still applies, and the code is very straightforward.

I've seen a couple people get tripped up by this myself (including people new to Drupal), and it sounds like everyone here agrees the patch would be an improvement over the current situation... So, RTBC.

Committed #9 to HEAD.

Now... I guess moving to D8 to discuss proper emhpasizing/de-emphasizing of main vs. delete actions? I wonder if we'd be better off starting a new issue for that, though... this poor simple bug report got rather hijacked.

There is no hijacking just a different opinion - which we explored, that is what design is about. Since we exchanged one bug for another, this is hard to call fixed - but lets do it properly in a new issue.

Ok, restoring status.

Looks like #1238484: Ability to mark the form buttons to be of a specific type (so that they can be styled differently) is the issue in which the other discussion is being continued.