The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums CSS OOCSS and the issue of icons and hover states

  • This topic is empty.
Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #40626

    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


    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: { 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):

    <a class="button  button--icon" href="#"><i class="icon  icon--inbox  button--icon__icon"></i>Link</a>​
    /* Button */

    .button {

    .button:focus {


    /* Button Icon */

    .button--icon {

    .button--icon__icon {

    .button--icon:hover .button--icon__icon,
    .button--icon:focus .button--icon__icon {


    /* Icon */

    .icon {

    .icon--inbox {


    @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.

    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, that leaves us with putting a class on the ancestor object that the icon can “listen” to, so…”

    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.

Viewing 6 posts - 1 through 6 (of 6 total)
  • The forum ‘CSS’ is closed to new topics and replies.