>  기사  >  웹 프론트엔드  >  高性能封装检测浏览器支持css3属性函数_html/css_WEB-ITnose

高性能封装检测浏览器支持css3属性函数_html/css_WEB-ITnose

WBOY
WBOY원래의
2016-06-24 11:30:151171검색

css3出来已经很久了,现在来谈判断浏览器是否支持某个css3的属性虽说有点过时了,但是还是可以谈谈的,然后,此篇主要谈的不是判断是否支持,而是怎么封装更好,为什么这么封装,欢迎吐槽。

入题,判断浏览器是否支持css3 transition,方法很简单,只需要下面这句代码就行了:

'transition' in document.body.style

chrome和ie支持document.body,但是Firefox不支持,Firefox支持document.documentElement,对于没有doctype声明的ie又不支持document.documentElement。

所以用 创建一个都支持的元素,然后通过 判断属性在元素的style里是否存在即可:

'transition' in document.createElement( 'i' ).style

当然这是标准下,对于老点的chrome或者Firefox,它们不支持transition,但是支持带前缀的transition,比如chrome 里css写成-webkit-transition: 1s;于是js也需要对这种情况进行判定,向后兼容。

现在贴一段简洁的封装代码,然后再逐步解析,以避免繁杂,产生不了全局观:

    function cssProperty( attr ){            var prefix = [ 'O', 'ms', 'Moz', 'Webkit' ],                length = prefix.length,                style = document.createElement( 'i' ).style;            cssProperty =  function( attr ){                if( attr in style ){                    return true;                }                attr = attr.replace( /^[a-z]/, function( val ){                    return val.toUpperCase();                });                var len = length;                while( len-- ){                    if( prefix[ len ] + attr in style ){                       return true;                    }                }                return false;            };            return cssProperty( attr );        }

接下来是一段一段的解释。

为什么直接声明prefix = [ 'O', 'ms', 'Moz', 'Webkit' ]

而不使用字符串切割prefix = 'O ms Moz Webkit'.split( ' ' ),其他人很多都是这样写的。

经笔者测试, 测试代码如下,为了不必要的影响,我两段代码一起测试和两段代码分别测试都做了观察,结果无差。

为了偷懒,估计其他浏览器应该也是差不多的结果就不做ie的测试了:

测试结果如下,单位ms:

很明显,直接声明prefix = [ 'O', 'ms', 'Moz', 'Webkit' ]的代码执行效率更高。

再看[ 'O', 'ms', 'Moz', 'Webkit' ]是25个字节,'O ms Moz Webkit'.split( ' ' )是28个字节,即便是从文件大小方面,前者也优胜过后者。

然而为什么很多国外包括jQuery源码里都是用split分割的形式呢?

(ps:jQuery-2.1.3源码5738行写cssPrefix时,是用的直接赋值,代码如右:cssPrefixes = [ "Webkit", "O", "Moz", "ms" ])

原因我猜大概是这样的:对于分割的字符串种类比较多时,采用split有利于文件字节的减少,而执行效率缩小99999倍后几乎可以忽略不计,但是对于文件被下载更快,虽说也可以忽略不计,但是选择这边比选择执行效率那边要好一点吧。

(ps:或许还有个原因就是书写split的这条代码方便吧,不像数组那样,一会单引号,一会逗号方括号的...。如果是为了装逼就算了)

回归正题,回归到我们这里,两边我们都胜过,所以,毋庸置疑的就应该选择前者。

❤对于网上有些不缓存而每次去获取style的代码,我想说,难道同个浏览器环境下,下一秒这个元素的style就变了吗,难道不同元素它是style也是变的,难道div元素支持transition,其他某个元素就不支持transition了?!

下面这个代码来自国外的谁(当然中国好像很多都是直接不假思索的就拷贝过来了): http://code.tutsplus.com/tutorials/quick-tip-detect-css3-support-in-browsers-with-javascript--net-16444

❤仔细一看,会发现为什么我的排列是这样的:O ms Moz Webkit,而别人的是这样的:Webkit Moz O ms;

理由来自 2015年浏览器市场份额排行榜: http://tools.yesky.com/420/93749420.shtml

在国内,Opera PC版估计没什么用,而且它早已转向webkit内核了,ie就不谈了,对于开发者来说坑太多了,看不到好效果就看不到吧,对不起了。

所以,总体来说,排名依次是chrome,Firefox,ie,opera。

在后面的 while 循环 判断代码中,是倒序判断的,所以从执行效率的角度讲,

大部分情况是chrome访问,所以就第一个判断webkit内核,满足条件就跳出循环,减少执行,提高运行效率。

❤我的代码里多了 var len = length; 用下面的代码测试一下,环境是(老版一点的)浏览器都只支持带前缀的这两个属性(比如Firefox13),测试国外代码第二个及以后的alert弹出的都会是false,因为它耗尽了len。

    alert( cssProperty( 'columns' ) )    alert( cssProperty( 'animation' ) )

❤函数封装如下封装,如果像国外那种柯里化封装表示js一加载完就会执行外层的匿名函数,然后把新函数赋值给supports,如果页面一定会用到检测函数,那么这种方法与下面的封装效果无差,但是如果页面不一定 用到,即cssProperty变成了整站全局函数,或许另多个页面用到,于是像下面这样封装就不会造成函数的自执行,只有第一次调用函数的时候,函数才会执行,然后被赋予新值,详情可以参考一下《JavaScript高级程序设计第三版》惰性载入函数。

    function cssProperty( attr ){         //...code         cssProperty =  function( attr ){             //...code         };         return cssProperty( attr );    }

最后欢迎访问我的 Github ,欢迎Star,欢迎Fork,一起成长。

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.