I want to create an animated transition on :hover I'm not able to get it to work, any idea what I'm doing wrong ?

   ul.baselinks li a.prev {background:url('/../img.png');}
    ul.baselinks li a.prev:link {background-position:-12px 0;}
    ul.baselinks li a.prev:hover {background-position:-24px 0;transition:background-position:1s;}

ul.baselinks li a.prev:hover {background-position:-24px 0;transition:background-position:1s;}

You have an extra colon after the background-position - it should be:

ul.baselinks li a.prev:hover {background-position:-24px 0;transition:background-position 1s;}

My transition is still not working, from the three images in the sprite when I hover over, nothing is happening ?

Try putting the transition on the ul.baselinks li a.prev, not the hover selector.

Edited January 14, 201511 yr by cibgraphics

Try putting the transition on the ul.baselinks li a.prev, not the hover selector.

 

That sounds good, I also thought of something else - vendor prefixes. Funny, I have read an article this morning saying vendor prefixes can safley be omitted, but maybe that's not the case.

So maybe try:

ul.baselinks li a.prev {
    background:url('/../img.png');
   background-position:-12px 0;
   transition:background-position 1s;
      -moz-transition:background-position 1s;
     -o-transition:background-position 1s;
     -webkit-transition:background-position 1s;
     -ms-transition:background-position 1s;
}
    
    ul.baselinks li a.prev:hover {
        background-position:-24px 0;
    }

If you're using grunt or gulp then you can run autoprefixer as a task then you quite literally never have to worry about vendor prefixes again. NPM keeps things upto date.

+1 for Grunt. Love me some Grunt.

 

 

That sounds good, I also thought of something else - vendor prefixes. Funny, I have read an article this morning saying vendor prefixes can safley be omitted, but maybe that's not the case.

So maybe try:

ul.baselinks li a.prev {
    background:url('/../img.png');
   background-position:-12px 0;
   transition:background-position 1s;
      -moz-transition:background-position 1s;
     -o-transition:background-position 1s;
     -webkit-transition:background-position 1s;
     -ms-transition:background-position 1s;
}
    
    ul.baselinks li a.prev:hover {
        background-position:-24px 0;
    }

 

 

http://caniuse.com/#feat=css-transitions

 

I would only use the webkit one for android.

I got it working Thanks to CibGraphics suggestion ! When you say Grunt, do you mean this ?

I got it working Thanks to CibGraphics suggestion ! When you say Grunt, do you mean this ?

 

Yes! it's well worth learning to use. here's some of the grunt tasks I use - grunt automates all of them:

• Sass compilation
• Autoprefixer
• Css minification
• JavaScript concatenator
• JsHint
• JavaScript minfication
• SVG Store - allows for automated SVG spriting
• ImageMin - lossless image optimisation.

There's a couple of others that I can't remember, but they are tied in with a 'watch* task that watches certain files or folders for changes then runs the corresponding tasks. This linked up with live-reload makes for a very efficient workflow .

 

I've heard Gulp actually runs through the tasks faster than Grunt, and most prefer the function-like syntax, but for me the more JSON esque syntax of Grunt is easier for me to read, even if it is a little verbose.

Edited January 14, 201511 yr by rbrtsmith

I know someone who loves Sass and they keep trying to sell me to learn it, I haven't yet

Sass is also well worth learning and incredibly powerful, however it the wrong hands it can produce terrible CSS, if you do learn be careful to avoid some of the common pitfalls like over-nesting.

If you want to learn grunt, which I highly suggest. I wrote a tutorial about getting started

 

 

http://cibgraphics.com/blog/grunt-js-basics-part-1

 

Also a good alternative to Sass\Scss is Less.

I'm not a fan of Less, I used Less for over a year before making the switch to Sass about 6 months ago.

 

• Less syntax is a bit weird, not a good idea to assign variables to the @symbol when it is already used by things in native css like media querys, the $ sign is more sensible.

• Less cannot handle conditionals, you have to do guarded mixins instead which involves far less intuitive syntax

• Less cannot do loops, you need to use recursion to simulate them, again not so intuitive. Sass can do while, for, for-in loops.

• You can't use a variable in a property name in Less, this is a deal breaker for me, in terms of writing efficient mixins.

• Sass allows you to extend one class from another, which can be dangerous if done in the wrong way, still it's a useful tool to have.

Quite literally the only thing Less has going for it over Sass is it's documentation which is very good. But as a whole I don't see any good reason to use Less over Sass, hence I stopped using it.

Edited January 15, 201511 yr by rbrtsmith

If you want to learn grunt, which I highly suggest. I wrote a tutorial about getting started

 

 

http://cibgraphics.com/blog/grunt-js-basics-part-1

 

Also a good alternative to Sass\Scss is Less.

 

Thanks I'll read it over soon ;-)

I'm not a fan of Less, I used Less for over a year before making the switch to Sass about 6 months ago.

 

• Less syntax is a bit weird, not a good idea to assign variables to the @symbol when it is already used by things in native css like media querys, the $ sign is more sensible.

• Less cannot handle conditionals, you have to do guarded mixins instead which involves far less intuitive syntax

• Less cannot do loops, you need to use recursion to simulate them, again not so intuitive. Sass can do while, for, for-in loops.

• You can't use a variable in a property name in Less, this is a deal breaker for me, in terms of writing efficient mixins.

• Sass allows you to extend one class from another, which can be dangerous if done in the wrong way, still it's a useful tool to have.

Quite literally the only thing Less has going for it over Sass is it's documentation which is very good. But as a whole I don't see any good reason to use Less over Sass, hence I stopped using it.

Nice summery on the pros and cons of Less and Sass.

Edited January 16, 201511 yr by CreativeSheep

I'm not a fan of Less, I used Less for over a year before making the switch to Sass about 6 months ago.

 

 

• Less syntax is a bit weird, not a good idea to assign variables to the @symbol when it is already used by things in native css like media querys, the $ sign is more sensible.

• Less cannot handle conditionals, you have to do guarded mixins instead which involves far less intuitive syntax

• Less cannot do loops, you need to use recursion to simulate them, again not so intuitive. Sass can do while, for, for-in loops.

• You can't use a variable in a property name in Less, this is a deal breaker for me, in terms of writing efficient mixins.

• Sass allows you to extend one class from another, which can be dangerous if done in the wrong way, still it's a useful tool to have.

Quite literally the only thing Less has going for it over Sass is it's documentation which is very good. But as a whole I don't see any good reason to use Less over Sass, hence I stopped using it.

You actually can use variables as class names and you can extend classes.

You actually can use variables as class names and you can extend classes.

Im sorry i should have clarified more. I meant extend using a placeholder/ghost selector.

http://thesassway.com/intermediate/understanding-placeholder-selectors

 

And the variable thing i mean as a property name, rather than a selector. Aka interpolation.

That said it does seem the Less team have fixed this on their latest release. Certainly a step in the right direction.

 

Btw I'm not saying Less is a bad tool. It's just there are no compelling reasons to use it over Sass, whereas the contrary is certainly true.

Btw I'm not saying Less is a bad tool. It's just there are no compelling reasons to use it over Sass, whereas the contrary is certainly true.

 

Hey, I right with you. I used to be a LESS user but have switched over to SCSS about 3 months ago. I do find LESS easier to setup unless you are dealing with Libsass, and that is painfully outdated compared to the gem. But thankfully they are bringing it up to speed. I dont like dealing with ruby gems because they are confusing to me. You have to deal with a bunch of stuff other than just the gem. It's a pain.

 

So I typically will use LESS if it is a smaller project and SCSS if it is a major project where I need to deal with the gem crap.

I didn't really have any issues with Ruby or it's Gems. My mac already had ruby, and windows just required it downloading, then if i recall correctly it was just the command 'gem install sass -g'. I have no Ruby knowledge, I just know that ruby gems is a package manager like NPM.

 

As for the Sass compilation, there's Grunt tasks that can run that

 

I do agree for somebody new to all this, the fact that Less is written in JavaScript does make things a little easier, but once the installation is done either can be run as Grunt tasks.

 

Just setup a base Gruntfile with Sass on, which can then be used on all your projects then you can add in project specific tasks, but you never have to deal with setting up Sass ever again. I've never had run Ruby commands or do anything with any gems since the initial install.

Edited January 18, 201511 yr by rbrtsmith

I didn't really have any issues with Ruby or it's Gems. My mac already had ruby, and windows just required it downloading, then if i recall correctly it was just the command 'gem install sass -g'. I have no Ruby knowledge, I just know that ruby gems is a package manager like NPM.

 

As for the Sass compilation, there's Grunt tasks that can run that

 

I do agree for somebody new to all this, the fact that Less is written in JavaScript does make things a little easier, but once the installation is done either can be run as Grunt tasks.

 

Just setup a base Gruntfile with Sass on, which can then be used on all your projects then you can add in project specific tasks, but you never have to deal with setting up Sass ever again. I've never had run Ruby commands or do anything with any gems since the initial install.

 

You get into trouble when you start getting into projects that require older versions of sass. Then you have to use a manager to deal with multiple versions of gems. And those gems require different versions of ruby. Thats when its starts to get messy and why you should never install gems on a global level.

Unless I am missing something why would a project require and older version of Sass? IIRC all of the old syntax works fine in the newest implementation as they have merely extended / built upon existing functionality, surely you can just update the package.json file in that project to use the latest version of sass, or run 'npm update'

Edited January 19, 201511 yr by rbrtsmith

Unless I am missing something why would a project require and older version of Sass? IIRC all of the old syntax works fine in the newest implementation as they have merely extended / built upon existing functionality, surely you can just update the package.json file in that project to use the latest version of sass, or run 'npm update'

 

Perhaps that is true, Ive only been using SCSS for a few months now. I just know that when I worked at a ruby shop they would have run me out of town if I installed a gem globally. Everything had to be run through RVM and Bundler.

 

Perhaps that is true, Ive only been using SCSS for a few months now. I just know that when I worked at a ruby shop they would have run me out of town if I installed a gem globally. Everything had to be run through RVM and Bundler.

 

You could be right with the whole gem thing, I am not too familiar with Ruby. Good stuff to know, I guess it might depend on the gem itself but as a whole I could understand why a blanket ban on global installs could be necessary.