Skip to content

Tab JS and .active class #21223

Description

@mdo

There are a ton of issues all surrounding the .active class applied via our tab JS. I'm collecting all of them here to try to de-dupe them and figure out a path forward.

Here's what I have so far (checked indicates closed issue):

Seems like this is all stemming from the flexibility I was trying to provide by allowing .active to be placed on parent items (e.g., <li>s) or the .nav-link itself. To resolve this, I think we need to only allow .active on the .nav-link (or in the case of list groups, .list-group-item). With dropdowns, we also need to have a separate class that is added to the parent or menu to properly show that.

My proposal is this:

  • Let's allow this to be flexible for any markup by applying the .active class only to the item itself, and not the parent.
  • Nav links, list group items, and dropdown triggers get .active on the <a> or <button> for their active state.
  • Dropdown triggers get .active to indicate their associated menu is shown, and the .dropdown-menu gets .shown to indicate it is visible.

That last part is a deviation from the current behavior, and might require more work. I'd be fine keeping .show or .shown on the parent of the dropdown trigger and menu if that'd be easier.

Thoughts @cvrebert, @bardiharborow, @Johann-S?


Potentially related tabs issues and PRs for context:

Activity

  1. added this to the v4.0.0-alpha.6 milestone on Nov 28, 2016
  2. mdo commented on Nov 28, 2016

    @mdo
    MemberAuthor

    I've pushed a branch to add a basic <nav>-based demo (currently broken as the linked issues indicate) to the docs fwiw. See b05f148.

  3. mdo commented on Nov 28, 2016

    @mdo
    MemberAuthor

    Also /cc @Starsam80 because his PR at #21036 addresses the double active state problem outlined in #21021. His PR addresses the proper class naming for that issue, and could likely be built upon further after merge with the issues outlined here.

  4. Starsam80 commented on Nov 28, 2016

    @Starsam80
    Contributor
    
    EDIT:  I forgot that PR 20982 changed more than just `.in`, so I guess my PR is still valid. 
    
  5. modified the milestones: v4.0.0-alpha.6, v4.0.0-beta on Jan 4, 2017
  6. pvdlg commented on Jan 22, 2017

    @pvdlg
    Contributor

    See PR #21807 for all the fixes mentioned above, including #20620.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions