Not every button should have the usual button-y style. A close button, for instance, might be displayed differently. Or a play button layered on top of a video.
I imagine the better argument (in my opinion) would be to not use generic names such as btn, as they are redundant and offer little self-documentation of their use.
Instead, I believe a combination of selectors and classes would be more meaningful, and encourage readability. For this particular scenario, I would go with a button selector to give all <button> tags a consistent basic styling, and use aptly-named classes like .cancel, .primary, and .destructive to add more styling for specific button purposes.
Then if I need to find all Cancel buttons, I can use a button.cancel query selector and only get Cancel buttons.
This only works if the cancel button looks like a specialized button. If it doesn’t (for instance, if it looks like the usual “×” symbol), you’re in for a lot of style overrides.
Oh, and guess what: Your suggestion is exactly what bootstrap does. .btn.primary is for the default action, .btn.secondary I usually use for aborting and going back, .btn.danger shows that bad things will happen. The only difference is that if doesn’t force its default styles on all plain <button> elements that might be present on the page.
You’re absolutely right. My idea is to imply that developers should give their semantics actual thought and intention.
For your example, the X button can be called .dismiss, since typically that’s what clicking the X does; whereas cancelling something may have more meaning (e.g. cancelling a subscription, which triggers other actions aside of dismissing a modal window).
Not every button should have the usual button-y style. A close button, for instance, might be displayed differently. Or a play button layered on top of a video.
I imagine the better argument (in my opinion) would be to not use generic names such as
btn, as they are redundant and offer little self-documentation of their use.Instead, I believe a combination of selectors and classes would be more meaningful, and encourage readability. For this particular scenario, I would go with a
buttonselector to give all<button>tags a consistent basic styling, and use aptly-named classes like.cancel,.primary, and.destructiveto add more styling for specific button purposes.Then if I need to find all Cancel buttons, I can use a
button.cancelquery selector and only get Cancel buttons.This only works if the cancel button looks like a specialized button. If it doesn’t (for instance, if it looks like the usual “×” symbol), you’re in for a lot of style overrides.
Oh, and guess what: Your suggestion is exactly what bootstrap does.
.btn.primaryis for the default action,.btn.secondaryI usually use for aborting and going back,.btn.dangershows that bad things will happen. The only difference is that if doesn’t force its default styles on all plain<button>elements that might be present on the page.You’re absolutely right. My idea is to imply that developers should give their semantics actual thought and intention.
For your example, the X button can be called
.dismiss, since typically that’s what clicking the X does; whereas cancelling something may have more meaning (e.g. cancelling a subscription, which triggers other actions aside of dismissing a modal window).