Yes, but element selectors based on the tag name alone are considered bad practise. Especially in bigger HTML sites. Even more so if you use a JS library / framework or some broad browser stylesheet underneath, or you use the same stylesheet in several places.
Also, a div or img tag can be a button with its own event listener as well. That may be asking for trouble as well, but I’ve been there (not proud of it).
The reasons that made a bunch of people scream very loudly to not do that 20 years ago were never good enough for making generic advice and don’t exist anymore.
Even more so if you use a JS library / framework or some broad browser stylesheet underneath
Learn CSS layers, use CSS layers.
Overall, if you every feel the need to write in your code “a button (behaves like a button)”, it’s very likely you are doing something wrong.
I’m not sold on layers, they do nothing to simplify the current mess that CSS is, because they build on top of what’s already out there. If CSS was built with the concept of layers, then it could probably be better. In reality, we’ll always have specificity rules and IMO adding layers will just add to the complexity.
The specificity rule is not that hard to understand, I’m not sure what’s the point of throwing layers in the mix. There are new CSS features I like and I see simplifying written code, but this is definitely not one of them.
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).
Besides what the other comment mentioned, that’s also not how most front-end frameworks work. You often need specific classes with your elements to use the default styles.
There’s nothing stopping you from styling buttons.
Yes, but element selectors based on the tag name alone are considered bad practise. Especially in bigger HTML sites. Even more so if you use a JS library / framework or some broad browser stylesheet underneath, or you use the same stylesheet in several places.
Also, a div or img tag can be a button with its own event listener as well. That may be asking for trouble as well, but I’ve been there (not proud of it).
A use case I find perfectly valid are
<label class="btn">s for checkboxes and radios with huge-ass hit areas.Considered by whom?
The reasons that made a bunch of people scream very loudly to not do that 20 years ago were never good enough for making generic advice and don’t exist anymore.
Learn CSS layers, use CSS layers.
Overall, if you every feel the need to write in your code “a button (behaves like a button)”, it’s very likely you are doing something wrong.
I’m not sold on layers, they do nothing to simplify the current mess that CSS is, because they build on top of what’s already out there. If CSS was built with the concept of layers, then it could probably be better. In reality, we’ll always have specificity rules and IMO adding layers will just add to the complexity.
The specificity rule is not that hard to understand, I’m not sure what’s the point of throwing layers in the mix. There are new CSS features I like and I see simplifying written code, but this is definitely not one of them.
What are CSS layers? I’m legitimately curious.
They change the precedence rules so that you can import large frameworks at will and not have them disrupt your rules or each other.
Basically, anything you apply in one layer has less precedence than what is applied on the next layers.
So I’m clear, are you referring to the
@layerCSS at-rule? Or, something else?Yes, I’m referring to the @layer rule.
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).Besides what the other comment mentioned, that’s also not how most front-end frameworks work. You often need specific classes with your elements to use the default styles.