下面的这两个例子都跟滑动门有关,应该都算滑动门的延伸。
之前有在BI上看到有朋友发过斜角导航,觉得可以有更好的解决方案。但最近都很忙,两个月没有来更新内容了,今天抽了点时间写了个DEMO发上来,自己写的,如果跟哪位高人有雷同的话那纯属巧合咯。也不说太多了,直接发例子了,方法很简单,一看就明白的。有一点要注意了,图片的透明部分需要花点时间来处理了。
其实当真正理解到方法之后,就可以延伸出很多效果出来。比如说下面的这个步骤导航(名字是我随便起的),是我在某个实际项目中用到的一个效果,给大家参考下,其实还能再优化一些的。
哎,许久没运动,搬的那一天被抓去当苦力,到现在还有点肌肉酸痛呢。本人较为内敛,只是随手拿手机拍了些相片,也来晒一下了。


从底部看,好高哇!一共39层,据说有139米。老实说,我的第一感觉竟然是联想到了某款曾经用过的剃须刀-_-!

大厅里有个很大的螺旋梯,不过我还没走上去看过是什么样子。

这里是茶水间,看起来有点像吧台呢。

这里是会客区,挺休闲的,平时也可以来这里坐一坐。

办公区一角。其实我挺喜欢这面墙的!

在食堂吃的第一顿午餐,一般说来10元左右。虽然不算便宜,但相对来说也挺丰盛的,尚能接受。

食堂北区的视野不错,可以向外眺望。

每人的办公桌上都有一盆植物,说是要自己照顾,不知我会不会把它给养死了。


接下来是传说中团购价价值一千多元的办公椅,一定得给个特写先。坐起来的确挺舒服的,可以多方位地调节,还可以后仰比较大的角度,中午休息时躺着挺不错的。只是这个价格……

也不知这叫什么区了,挺休闲的,还有电视跟DVD。

还有高尔夫球哦!

随手拍的一张了,好像不怎么有感觉。

最后来一张露脸的吧!哎,桌上的Q哥Q妹好像都不理我。
来到TX后第一个比较正式的任务就是做一个活动页面。页面就不说了,活动页面嘛,那个线条啊只能大块大块地切图了。然后就是因为数据量并不多,所以采用了用静态页然后通过JS去读数据的做法。然后就碰到了跨域的问题了。
我想肯定有很多朋友也会碰到这样的情况,对方只给出一个链接让你去取数据,通过传递不同的参数,返回不同的数据。如果是在本域的话,用AJAX是很方便的,但AJAX不能跨域。而iframe的方法也不实用,只能跨小域,还需要在双方页面加相应的函数,页面里多了那么一块也让人感觉不舒服。所以决定用动态script标签的方法来解决这个问题。
在这里想说一句,国内的业内环境真是…,网上查出来的技术文章几乎都是同样的几篇转来转去,而且也说得不清不楚的很费解。还是BI上环境好些,呵呵。下面的代码并非我原创,也是参考来的,但我一定讲解清楚,让每一个看这文章的人都能明白具体是如何实现的。
由于浏览器安全的问题,一些跨域的请求都会被拒绝,当然,你也可以设置为添加到信任站点就能访问,但你不可能要求你的每个用户都去这样添加。但是,也有个例外,JS是可以跨域的,比如说我们用jquery的时候,可以加载code.google.com里面的jquery包,同样也能应用到jquery的框架;再比如说一些流量统计的代码,都是加一段JS在页面,我们就能应用到写在里面的函数了。所以,当我们把我们所以跨域读取的地址写在script标签的src里的时候,不管是什么后缀名的文件,都会被当做一个JS来读取。所以呢,这个页面的输出要采用JS的格式。
在这里先说两点,第一是这个方法名字虽然是叫动态script标签,但是你静态地直接写在页面里也是可以的,前提是你不需要动态地传递参数;第二是在很多文章里会把此方法跟json扯上关系,其实这跟json没有任何关系,只是因为用json来处理某些返回值时比较方便罢了。下面还是用json格式的来说明好了,因为这样的应用可能会比较多一点。
首先我们新建一个页面,可以是ASP、PHP或者CGI,或者TXT也都可以,但是让他的输出像这样:
var MyJSON = {
'info': [{'name' : 'moondy','sex' : '男','age' : '28'}]
};
这里定义了一个json,你也可以这样定义:
var name="moondy";
var sex="男";
var age="28";
喜欢怎样写就怎样写了,只是在有多组数据的时候,用json比较方便了。关键是要用var ,这样才能当做一个JS的变量来读取,此方法的主要思想,就是在你的页面动态地加入了一句变量的定义,而你就可以直接在JS中引用这个变量了。下面是JS部分:
var element = document.createElement("script");
function createScript(compId,dataId){
element.src = "http://www.moondyzone.com/json.php";//这里是你需要跨域读取的URL
element.type = "text/javascript";
element.language = "javascript";
}
function writeContent(){
alert(MyJSON[0].name);//可以看到读取了相应的数据,json的操作跟数组类似了。这里就可以直接读取上面var定义的变量了。
}
window.onload = function(){
createScript(1,2);//这里的这个参数是在需要动态传递参数的时候用的,本例中没有用到,看具体的需要了。
document.getElementsByTagName("head")[0].appendChild(element);
}
if(document.all){
element.onreadystatechange = function(){//IE用
var state = element.readyState;
if (state == "loaded" || state == "interactive" || state == "complete") {
writeContent();
}
};
} else {
element.onload = function() {//FF用
writeContent();
};
}
在这里就没有做DEMO了,本人在实际项目中应用都没有问题的了。另外也可以跟据不同的需求进行修改,比如说例子中element.onreadystatechange 是在加载完成后运行,可以自行改为点击触发之类的也都可以咯。不过有一点要注意,动态改变外域的URL时需要刷新页面,直接重写script标签中的src在IE中会读不到。
哎,最近工作太忙,都好久没来写点东西了。
这也是最近工作中碰到的一个问题,其实以前也经常碰到过。具体是这样的,有一个图片链接,为了有明显一些的提示效果,需要在鼠标移上去的时候把它放大。按思路来说,其实是很容易的,只要在a:hover img{}里定义鼠标经过时改变图片的大小就可以了。但实际上,在IE6中,a:hover img{}里定义的内容并不生效。
IE6对伪类的支持真的很烂,除了A标签外其它标签都不支持:hover伪类,而偏偏这个唯一支持的a:hover也还有着BUG。解决的方法就是给a:hover {}定义一个属性:
a:hover {zoom:1;}/*这里可以换成其他很多的属性。*/
a:hover img {……}
在网上找出的答案基本上都是这样,的确这样能解决问题,但却都没有说这个BUG到底是为什么。最初我是以为是要触发layout,但经过试验,不能触发layout的属性也能生效,比如说color、border之类的。也就是这一次,我才找到此BUG的原因所在:当a:hover {}的属性跟a {}中的是一样的时候,也就是说a:hover没有发生属性的改变,完全继承a的属性的时候,就会产生此BUG。所以给a:hover {}定义一个属性值就能解决这个问题,至于定义什么值就看具体情况了,至少可以不用zoom这个看起来有hack嫌疑的属性咯。
很久很久以前,我刚接触到这一行的时候,用的是一款名叫webedit的WEB在线编辑器。当时并不了解什么WEB标准,后来才发现在非IE的浏览器下都用不了。其实抛开兼容性的话,这一款还算是蛮不错的在线编辑器了。
再后来,就用到了所谓大名鼎鼎的FCK。FCK功能的确是不错,但我实在没法称赞它好用,他真的很难用,或者说是不适合中国人的使用习惯吧。像我们一些开发人员自己用还没什么,如果给客户做的程序用的是FCK,那么一个上传图片的模式就会搞得人摸不着头脑。
然后我不停地在找,终于碰到了一款近乎完美的WEB在线编辑器——xheditor。没有说它完美,因为它还有一个前提条件,是用jquery框架开发的。不过就算项目用的不是jquery框架,加上一个50K的JS包,它的体积还是非常小的,调用相当方便不像以前的那些需要插入一个iframe而是一个textarea就可以了,而且非常适合国人的使用习惯。详细介绍我这里就不写了,大家可以去谷歌代码上去看,他们的开发团队一直都有更新版本。
http://code.google.com/p/xheditor/

其实在平时很少注意到CSS渲染效率的问题,不过在很多时候都是细节决定成败,这也是个不容忽视的问题。之前也拜读过网上流传的一篇有关CSS渲染效率的文章,传得太多,也不知原作是谁了。不过并不是太赞同其中的一些观点,所以就本人工作中的一些经验以及看法,说说这个问题,个人观点并非权威,欢迎拍砖。
在这里我们不只是单纯地研究渲染效率的快或慢,应该从一个项目的整体来看。页面渲染的这个过程,是在用户本地进行的,也就是说用户打开页面,载入了HTML代码以及样式表、JS等等相关的文件,浏览器再跟据这些文件把页面渲染出来。关于速度方面,我们更注重的是载入的速度。而渲染速度,的确某些样式的写法会存在渲染速度的差异,但对于当前随便每秒都能运算上亿次的个人电脑来说,把一张背景图平铺100次跟平铺10000次又有多大区别呢?当然,细节,细节决定成败,但细节不等于吹毛求疵,下面说说个人对此侧重点的一些看法。
可能会有影响,但可跟据具体情况忽略的部分
比如说颜色值,color:#F00;、color:#FF0000;、color:red; 这三者都是一样的,至少用人类的感观无法区分其对渲染速度的影响,用简写可能或多或少能减少那么几个字节的体积,不过标准写法是6位大写字符的写法。
display与visibility就不详说了,这本身就是两种不同的表现属性,该用谁就用谁。
注意某些样式的保留属性,比如说:
background:url(image.jpg);这样一句,那么在渲染的时候会默认输出background-color : transparent 、background-attachment : scroll 、background-repeat : repeat 等等属性。在完美主义者的眼里这是对资源的一种浪费,但同样,人类的感观体会不到此影响。其实个人还是认为简写形式有助于减少样式表的体积,而且这也似乎是行内默认的写法了。同样的,border、list-style等也有默认属性,也不用深究了。
背景平铺的问题
对于可平铺的背景来说,很多人喜欢用1px为单位来进行平铺,前面也说了,其实平铺多少次对于个人电脑来说几乎都是一样的,关键在于图片的大小了。对于可平铺的图片,一定范围内的像素值是一样的,所以增大尺寸对于积体的影响并不大,我这里对比了单色1*1跟10*10的图片在jpg跟gif格式下的大小,相差都几有几个字节

其实本人不太建议用1px的图,至少自己在修改的时候无法一眼看出那张图片是什么。而且现在用css sprites也会把可平铺的部分也做进去,这也是对渲染效率的提升了。
再说说会有明显影响的部分
@import 的使用
不建议在页面里使用,他会在页面加载完之后才被加载,有可能使页面闪动或是裸体。如果是样式表过多为了方面管理的话,放在CSS里就好。
某些选择符的使用
渲染的过程也就是对这些选择符的匹配,所以我们可以很容易地理解到,一些比较直接的选择符比如类选择符、ID选择符等的匹配效率高,而一些条件比较繁复点的选择符比如子选择符、属性选择符等的匹配效率相对来就低一些。当所匹配的量比较多的时候,可以明显地感觉到速度的差别。(关于各种选择符,具体可查看CSS手册了)
IE的滤镜
自从标准化的兴起以来,IE滤镜的日子就不好过了,除了不兼容以外,某些滤镜真的蛮耗资源的。现在还在用的可能就是为了处理IE6下图片透明的问题了,建议能不用就不用他吧。
expression的使用
也许这个不能归为渲染的部分,不过他的确相当占资源,如果加得多的话,会让你的页面其慢如牛。