Home  >  Article  >  Web Front-end  >  高性能封装检测浏览器支持css3属性函数_html/css_WEB-ITnose

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

WBOY
WBOYOriginal
2016-06-24 11:30:151133browse

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,一起成长。

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn