在项目中 background transiton 带来的"便利"与“坑”

本文就两个例子跟大家分享一下background-image与background-size的渐变(transition)所带来的方便与“深坑”

首选,说说这东西好的地方,有时候在做PC项目的时候,可能会碰到这种需求:要求鼠标移入一个ICON或者一张图片的时候要求显示另外一张图片,并且带有渐变的效果。

那么对于类似于我这种经验不是特别成熟的前端来说,肯定会想找到经理说,大哥可不可以把它改成色块,绝对可以完成任务。因为很简单啊,映像中颜色的渐变还是很容易实现的,当然啦,日子不可能像你梦想的那样好过,“必须按需求实现”。

然后我就想着1、要切换图片,2、要渐变效果。如果是以前的话,我肯定是弄两个不同的标签咯,然后hover的时候分别fadeIn,fadeOut,  对!这个很容易实现嘛对吧,但是我觉得呢,做WEB前端应该需要坚持:能用CSS解决的,绝不用JS。为什么呢?因为···(自己百度去)

言归正传,只用CSS实现上面两个要求

我就想着要渐变,那就肯定是CSS3的transition了,但是图片能不能渐变,我还真的不知道,当时我就试着玩一下,

在项目中 background transiton 带来的"便利"与“坑”在项目中 background transiton 带来的"便利"与“坑”

左边三个泡泡,默认的状态,背景啥的都写的很清楚了,现在把hover需要做的写进去(其实也没啥,不就是换个背景图片么,哎),

在项目中 background transiton 带来的"便利"与“坑”在项目中 background transiton 带来的"便利"与“坑”

截图当然解释不了渐变的效果,你们可以自己试着玩儿,反正(background-image)背景图片也可以渐变就对啦.(可参考我的项目http://mysidechina.com/)

下面说说同样的东西把我坑了一下午的例子

在项目中 background transiton 带来的"便利"与“坑”

简单点儿说吧,首先,可能你的页面上有这么一个元素需要有渐变,这里我就不管是width还是height还是top,left了,无所谓,因为你任性的写了个 “all” ,混蛋!!!谁让你写“all”的,就是这个坏了事儿,你可能兴高采烈的觉得我的这部分效果都有了,渐变的效果也很完美。然后,然后,然后,你可能碰到了一个新的需求,比如所,我们要求图片根据屏幕做自适应,那么这里我们肯定是根据窗口的比例和图片的比例进行计算然后确定到底是background-size:100% auto;还是background:auto 100%;  相信同胞们在项目中肯定碰到这样的需求吧,那么问题来了,我发现在更改了background-size这个属性的时候,页面上背景图片的位置并没有立马改变,而是过了几秒钟才变,尼玛···明明没问题啊,难道是JS的计算时间过长?当然啦,这个肯定而是考虑的可能性之一。

在经过排除其它的原因之后,发现了上面那个玩意儿,然后就瞬间顿悟了,这里有一个“all”和“transition-delay”拉了我的后腿,意思就是说,这里的all也包括了我们要修改的background-size,在延后2.5S之后才开始执行!!并且还有3秒钟的渐变,我了个天,这种中间就整整5.5秒了,不解释,赶紧赶紧赶紧把transition改了

在项目中 background transiton 带来的"便利"与“坑”

乖乖的把"all"改成了"transform"。OK!问题真的解决了。

所以说啊,我们写CSS的时候也要养成好的习惯,那么针对这个渐变来说呢,就是:你需要什么属性有渐变那就写上什么,而不要动不动就给个"all",鬼知道你后面会不会在这个上面才坑啊,也有可能同事改你的代码的时候一直碰到BUG却不知道是这个原因影响的呢,所以“下手”慎重!

上一篇:Codeforces 786 B. Legacy


下一篇:springMVC之HelloWorld