Closed jaseemabid closed 9 years ago
@jaseemabid Thanks for the suggestion. Although I usually would in other projects, I want to keep this one as simple as possible. Namespacing will reduce the possibilities of conflicts but not all due to the nature of CSS.
I encountered the same issue. I added Hover.css to an application with Zozo Tabs (a nicer-looking jQuery UI Tab replacement) and the entire tabbed section started swaying upon page load.
I had to remove the demo "button" class because it conflicted with existing style settings.
I updated all classes to require an addition "hv" class (similar to what Font Awesome does with their "fa" class requirement.) http://fortawesome.github.io/Font-Awesome/examples/
For example, here's a pulsing hover+fa delete button:
<button class="hv pulse-grow"><i class="fa fa-trash-o"></i></button>
Are you able to maintain a CSS prefixed version that doesn't contain any demo styles?
Yes, #31 has requested the same so I'll moved the demo styles into a <style>
element in the HTML.
Still not too sure about namespacing yet but I'll reopen this ticket and consider it. Give a :+1: if you're for namespacing.
+1. Considering how broken CSS is, every library should be namespaced.
:+1: for namespacing :smile: I had some conflicts with existing classes... For the ease of use (and implementation), I would recommend only a prefix for the existing classes.
For example:
pulse
:arrow_right: h-pulse
pulse
:arrow_right: hvr-pulse
pulse
:arrow_right: hover-pulse
Most of the developers use IDE's, so usually the length of the class name can be a secondary concern, and also namespaces would help in creating a more cleaner code.
In the context of CSS, namespace === prefix, right?
Close enough, but not always...
Look at fontawesome, and at my proposal above.
In case of fontawesome the namespace is 'fa' and is required by every class that is prefixed with 'fa-', all the prefixed classes act as a modifier for the 'fa' base class.
In this case, we really don't need a base class, and that's why just a prefix would be enough, for technical reasons.
For code visibility, and compatibility one solution should be chosen, it really depends on the structure you're currently using.
+1 to the Namespacing. I was implementing this into a site built on the ZURB Foundation Framework and the menu (Top Bar) completely broke. Upon inspecting I noticed that a hover class was being added by the script and when I would click the link it would hover the menu vs actually clicking the link. I commented out the hover class and it works fine.
I like the idea of a simple hv-
before the class. In my example above having hv-hover
would of prevented the issue.
Also, thank you for this project! I tripped upon it the other day and I love it!
In 2.0.0 all classes are now prefixed with hvr
. Should you wish to change the namespace, you can do so in scss/_options.scss
or less/_options.less
.
It would be nice to namespace the CSS classes to make hover not interfere with existing libraries/code.
Something like
hover-grow
?