enhancement(Navbar) implemented classname, hovering link color bug,

[gselderslaghs]

Proposed changes

Fixed todo in navbar by adding navbar class instead of targeting html tag, also fixes part of #573
Fixed #385 hovering link bug

Checklist:

• I have read the CONTRIBUTING document.
• My commit messages follows the conventional commit format
• My change requires a change to the documentation, and updated it accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[gselderslaghs]

Additionally made color and background color states important to fix specificity issue on same specificity level (eg. classname - classname)

[wuda-io]

I very much like the classname based approach. This is much needed.

[wuda-io]

Why use !important. Please not. This is no good practice.

[gselderslaghs]

I implemented it because the color states currently introduces a specificity problem with other classnames
They share the same specificity level if it's all based on class name, primary (or other color state) color profiles defined by color classes could get overridden by the component class background color, by declaring important state it makes sure it always has the color state defined
Another idea to avoid component overrides without using the important context would be to introduce the color states in mixins and declare them specifically on each component

[gselderslaghs]

This pull-request is currently invalid since defining the colors-module classes on the component is not working

If we look at the _colors-classes.scss it has also !important context declared
While using colors from colors-classes currently works on the navbar, colors from the colors-module are getting overridden by module defined colors because of the missing important context

I don't understand why we can use it in the color classes but not in the colors-module since adding one of colors-module class to an existing component should always result in the component rendering the specified properties of the colors-module class, right?

Possible two solutions for this scenario:

• Implement the !important context so we can just use the classname (preferred)
• Create mixins for all color-modules classes and define them on each component separately