So I'm dealing with an issue right now where I have an icon object and a button object. Specifically, in certain situations, an icon is inside a button. Many times, icons will change when their parent element is hovered (a light icon will go dark, a dark icon will go light, etc.).
So, how do we handle this when looking at the "icon" as its own module? The actual hover isn't on the icon - it's on an ancestor of the icon - such as a button or menu item link.
Even this seems weird, as you're adding a class to an ancestor that doesn't make much sense to the ancestor. Though it does have the benefit that you can add the "ico-hover-ancestor" class to any ancestor object - button, menu item, whatever.
Ultimately, though, the alternate view of the icon is a state of the icon itself. This means that, ideally, you should be able to do something like:
But to do this, you would have to use JS to append the state class to the icon module when the hover-able ancestor is hovered. Which seems like kind of a waste of JS (and would still require some sort of class to identify the hover-able ancestor just for more efficient JS targeting).
And, obviously, this isn't just with hover states, but also active states and "current" states (for menu items or tabs or something).
I've been thinking about this and it seems that each solution isn't ideal. They all have their drawbacks.
@dfogge Icons can be used in several locations - such as buttons, tabs, navigation items (either standard or drop-down), standard links, status messages (like a success, fail, warning, etc), and many other locations.
@joshuanhibbert Yeah, I've considered making a button with an icon a button variant like you showed. But I feel like the alternate state of the icon (hover, active, whatever) should be declared with the icon styles - especially since that same icon state may show up for multiple interactive objects like buttons, navigation items, and tabs. It's a sensible approach, just leads to code duplication.
So I'm dealing with an issue right now where I have an icon object and a button object. Specifically, in certain situations, an icon is inside a button. Many times, icons will change when their parent element is hovered (a light icon will go dark, a dark icon will go light, etc.).
So, how do we handle this when looking at the "icon" as its own module? The actual hover isn't on the icon - it's on an ancestor of the icon - such as a button or menu item link.
It seems weird to do something like:
.button:hover .ico-inbox { background-position: Xpx Ypx }
That pretty tightly couples the button and icon objects. Plus, then you'd have to do it for each ancestor (button, menu item, whatever else).
So, that leaves us with putting a class on the ancestor object that the icon can "listen" to, so...
<a class="link ico-hover-ancestor">
<i class="ico ico-inbox></i> Inbox
</a>
And writing CSS like:
.ico-hover-ancestor .ico-inbox { background-position: Xpx Ypx; }
Even this seems weird, as you're adding a class to an ancestor that doesn't make much sense to the ancestor. Though it does have the benefit that you can add the "ico-hover-ancestor" class to any ancestor object - button, menu item, whatever.
Ultimately, though, the alternate view of the icon is a state of the icon itself. This means that, ideally, you should be able to do something like:
.ico-inbox.is-hovered { background-position: Xpx Ypx; }
But to do this, you would have to use JS to append the state class to the icon module when the hover-able ancestor is hovered. Which seems like kind of a waste of JS (and would still require some sort of class to identify the hover-able ancestor just for more efficient JS targeting).
And, obviously, this isn't just with hover states, but also active states and "current" states (for menu items or tabs or something).
I've been thinking about this and it seems that each solution isn't ideal. They all have their drawbacks.
How would you approach this?
why wouldnt the icons always be coupled with the buttons? where else would you be using them?
I would do something like this (using BEM methodology):
@dfogge Icons can be used in several locations - such as buttons, tabs, navigation items (either standard or drop-down), standard links, status messages (like a success, fail, warning, etc), and many other locations.
@joshuanhibbert Yeah, I've considered making a button with an icon a button variant like you showed. But I feel like the alternate state of the icon (hover, active, whatever) should be declared with the icon styles - especially since that same icon state may show up for multiple interactive objects like buttons, navigation items, and tabs. It's a sensible approach, just leads to code duplication.
this is how I usually roll. I think it's the best solution
@JoniGiuro It's how I'm leaning as well. It's the most reusable, as you can use that ancestor class on any element, so you're not repeating styles.