在我们页面制作的时候，如果遇到了比较个性化的按钮，我们一般会采取贴图的形式来去制作，但是为了维持其良好的可读性，我们都会在那个按钮上把这个按钮的功能如 “提交” 打上去，然后通过 text-indent:-999em 给藏起来，然而，这招对于 inline-block 元素却得不出我们预想中效果，是会和字一块儿向左缩进 -999em去了，这篇文章是针对这个现象来谈谈对应的解决方案。
阅读全文…

原文地址：查看原文

上段时间，团队内部有过好几次几次给力的分享，这里对西风师傅分享的继承机制稍作整理一下，适当加了写口语化的描述，留作备案。
阅读全文…

有时候，由于设计的需要，网站中难免会用到一些比较特殊的字体如 华康少女字体 来装饰我们网站的部分，让其不那么死板，然而由于如果想调用这个字体，一般来说，除非用户电脑上本来就有安装这个字体才能正常显示，否则页面渲染会调用TA电脑上已有的字体来替代。故实现个性化字体不能单纯使用 font-family 能实现。

所以我们页面制作的时候一般会用图片来代替这些比较特殊的字体，不过这样的做法只适合于 特殊字体应用范围较少的网站。而且用图片代替文字的做法，并不方便修改。

在这里为大家介绍的是 css3 的 @font-face 属性，个性化我们站点中的字体。

阅读全文…

图片展示窗各种各样，五花百门，今天为大家介绍的是图片跑马灯效果。

阅读全文…

原文地址: http://www.baiduux.com/blog/2011/02/15/browser-loading/

本文将探讨浏览器渲染的loading过程，主要有2个目的：

• 了解浏览器在loading过程中的实现细节，具体都做了什么
• 研究如何根据浏览器的实现原理进行优化，提升页面响应速度

由于loading和parsing是相互交织、错综复杂的，这里面有大量的知识点，为了避免过于发散本文将不会对每个细节都深入研究，而是将重点放在开发中容易控制的部分（Web前端和Web Server），同时由于浏览器种类繁多且不同版本间差距很大，本文将侧重一些较新的浏览器特性

现有知识

提升页面性能方面已经有很多前人的优秀经验了，如Best Practices for Speeding Up Your Web Site和Web Performance Best Practices

阅读全文…

当我们制作表单的时候，有时候会遇到数据过长，表单列数过多，需要横向滚动条的需求，我们一般的做法是 给这个表格的外层加一个 scroll_auto 的 div 并设置:

/*css document*/
.scroll_auto{ width:100%; overflow:auto;}

套在table的外层

<!-- html element -->
<div class="scroll_auto">
	<table>
		<tr>
			<td></td>
		</tr>
	</table>
</div>

如果碰巧 你给这个 table 或者table里面的元素 设置了 :hover 的伪类(最常见的是鼠标移到table中对应的行数，该行高亮) 并在里面写有属性，那恭喜 专属于 ie9 的 bug出现了(经测试，直到ie10预览版第二版，这个bug都还没修复)。

bug 重现地址：http://www.jackness.org/lab/ie9-scrollbar-bug/ie9-scrollbar-bug.html

阅读全文…

鉴于之前写的一个图片延迟加载api 在项目中应用起来改动量太大(要把全部应用到图片延迟加载的 src 统一改成 lazy_src要惊动多个部门呢..技术部，运营部等)，于是乎就诞生了这个 lazy_onload 的优化版了，无需改动原有代码即可实现图片延迟加载。

工作原理

在 需要应用图片延迟加载的页面最底部运行(不能丢进window.onload里面，因为window.onload是等网页完全加载完成的时候才调用的，当然也包括图片的加载喇…)，运行后，给需要图片延迟加载的对象 添加一个 lazy_src 属性，并将 原有的 src 的值 存放进去，而 src 则替换成一张 透明gif图(这是因为，经过测试，chrome，opera，safari当图片设置了带有图片地址的 src地址的时候，再把src地址改为空是不行的，图片继续进行加载 无视你的空值，所以得给个图片他去load而不能直接把src设为空值)，然后就是每当触发 window.onscroll 和 window.onresize 的时候 循环检测所有图片，当图片出现在可视区域范围内时，就把 lazy_src 的值 赋值到 src，让图片进行加载。当全部图片都加载完之后，撤掉事件。

演示地址: http://www.jackness.org/lab/object/lazy_onloadV2/demo.html

阅读全文…

图片展示窗各种各样，五花百门，今天为大家介绍的是手风琴式的图片展示窗。

工作原理：

通过改变 margin 负边距数值来实现手风琴特效

核心代码：

瀑布式算法( 数组中数值之和不变，其中一个增加的时候，那么在确保数值大于0的前提下,其他的就要减去相应的值.)

/*
 * 瀑布式算法( 数组中数值之和不变，其中一个增加的时候，那么在确保数值大于0的前提下,其他的就要减去相应的值.)
 * - array:int int数组集合
 * - index 要发生变化的 数组下标
 * - num 要发生变化的 数组 的数值
 * - sum 数组内int的总和
 */
function accordionAccount(array,index,num,sum){
	num = parseInt(num);
	account = num - array[index];
	var total = 0;
	//alert(account);
	for(var i = 0; i < array.length; i++){
		i == index?(
			array[i] = num
			
		):(
			array[i] - account >= 0?(
				array[i] -= account,
				account = 0
			):(
				array[i] = 0,
				account -= array[i]
			)
			
		);
		total += array[i];
		//确保 数组加起来总和一致...
		if(i == array.length -1 && total != sum){
			array[i] = array[i] + sum - total;
		}
	}
	return array
	
}

演示地址：http://www.jackness.org/lab/object/accordion_slide/demo.html

阅读全文…

原文地址：http://lifesinger.wordpress.com/2011/09/23/bigrender-for-taobao-item/

对于复杂页面，为了将用户关注的内容尽可能快渲染出来，至少有两种方式：

一、Facebook 的 BigPipe 方式。先输出页面整体布局，然后逐步输出脚本块，一边输出一边执行，将内容渲染回页面布局中。这样可以让服务端的运算、网络传输和浏览器端的渲染变成并行。BigPipe 最主要解决的问题是服务端的运算时间，当服务端的运算时间大于 300 ~ 500ms 时才能体现出优势。当服务端响应非常快（小于 100ms），BigPipe 退化为下面要讲的 BigRender.

二、淘宝商品详情页的 BigRender 方式。淘宝的商品详情页，服务端平均响应时间为 52ms, 采用 BigPipe chunked 输出意义不大。这次优化主要在浏览器端。页面下载完毕后，要经过 Tokenization — Tree Construction — Rendering. 要让首屏尽快出来，得给浏览器减轻渲染首屏的工作量。可以从两方面入手：

1. 减少 DOM 节点数。节点数越少，意味着 Tokenization, Rendering 等操作耗费的时间越少。（对于典型的淘宝商品详情页，经测试发现，每增加一个 DOM 节点，会导致首屏渲染时间延迟约 0.5ms.）
2. 减少脚本执行时间。脚本执行和 UI Update 共享一个 thread, 脚本耗的时间越少，UI Update 就能越发提前。

阅读全文…

或许有部分童鞋对这 1对璧人、额不对 一对事件 有点陌生 不过如果有接触过jquery的人应该会知道 这2个事件，意思就像字面般 onmouseenter(鼠标进入)、onmouseleave(鼠标离开)，那和 onmouseover(鼠标经过)、onmouseout(鼠标离开)有什么区别呢，这 2 个方法其实并不在 ecmascript 里头，而是 IE 里面的 私有方法，那为什么还要在这里花篇幅去介绍呢，因为…因为在开发的过程中会遇到的（总有那么的一次，总有那么的一天），在这里主要是给大家分析一下这 2 个事件的原理与实现方法。

阅读全文…