小数型Number在web中最出色的两个应用场景

时间:2020-9-8 作者:admin


我们大概都知道的是:精确度问题不仅在前端,甚至在整个编程领域都是“由来已久”的。

前端的精确度问题大概要从 Math.floor(number) 向下取整、 Math.round(number) 四舍五入但是round函数在正数和负数表现竟然有差异为开端。

这里不得不提一句:Math.round的实现原理其实是“将参数加上0.5再向下取整”,也就是说并不是真正的“四舍五入”!

同样的还有因为二进制转换和存储问题导致的0.1+0.2!=0.3的问题。但是这不是重点:我们将以此引出它们在浏览器中的使用:


浏览器对于小数型px的解析

不知啥时候开始,喜欢上用小数值px表示宽/高/字体size,后来仔细一看,确实无意中有一些帮助:
我们会发现,同样是11.9px,在不同内核浏览器上表现是不同的:如
(IE)
小数型Number在web中最出色的两个应用场景

(google)
小数型Number在web中最出色的两个应用场景

这里为什么用11.9呢?因为我们应该都知道:在浏览器中中文字体“正常”显示的下限像素值是12px。这里再对比一下:
(IE)
小数型Number在web中最出色的两个应用场景
(google)
小数型Number在web中最出色的两个应用场景

再对比上面的两张图,我们似乎能发现:11.9在IE下被解析为11,而在像Firefox、google这种W3C标准浏览器中,其被解析为12。

这个的作用还不小 —— 有了IE和其余浏览器解析小数的不同,在一些要 考虑兼容性 的大小细节问题上,我们就完全不用hack插手,直接一段代码莽上去就OK了?(要知道:大量“冗杂”的CSS代码也是会对页面渲染有影响的!)

padding: 0 12px;
*padding: 0 11px;

直接改写为:

padding: 0 11.9px;

完美!


还有一个为我们所熟知的地方就是:toFixed() —— 校正精确度函数。

但是这个函数有一些令人哭笑不得的小坑,比如:有个别浏览器并不会对最后的值进行“四舍五入”、小数点后位数不同结果不同:
小数型Number在web中最出色的两个应用场景
在大多数时候,其实我们是要 重写 toFixed()方法的:

Number.prototype.toFixed=function(n){
	let power=Math.pow(10,n);   //10的n次幂
	let fixed=(Math.round(this*power)/power).toString();
	if(n===0){
		return fixed;
	}
	if(fixed.indexOf('.')<0){
		fixed+='.';
	}
	let padding=n+1-(fixed.length-fixed.indexOf('.'));
	for(let i in padding){
		fixed+='0';
	}
	return fixed;
};

撒花!

声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。