Adobe BrowserLab – 在线跨浏览器平台页面预览环境

Adobe近日推出了一款基于Flash(由于Flex Builder更名为Flash Builder,因此不要提Flex了)技术的网页调试工具。名为 Adobe BrowserLab – 点击这里进入

这款工具能够帮助Web设计师观看在不同浏览器中同一页面的表现形式。当然,功能和浏览器覆盖面上比早先推出的BrowserShots要业余得多,但体验上还是有相当独到之处的。

这种“独到”其实是我想要已久的,具体说,主要是其提供了“2-up View”和“Onion Skin View”的对比方式,可以非常精确地看出网页在不同浏览器中的差距:

普通对比:

洋葱皮对比:两张不同的渲染结果叠加对比(Safari VS IE7)

目前,支持的浏览器并不多,包括:

有IE6,我认为足够了:)

其实Flash技术在这款应用中扮演的角色好不复杂,渲染工作是交给后端完成的,我想这个项目也是一个很好的典范并不一定是那种极其复杂的Flash应用才能博得喝彩的。

适合CSS入门者的简易模板

http://www.mycelly.com/

这个网站提供了12种最为流行的CSS布局代码。非常适合入门者使用。大家可以看看这些布局:

  1. 左右均自适应宽度(与我的博客一样)
  2. 侧栏定宽,内容自适应(剩下区域填满)
  3. 与1类似,位置相反
  4. 三栏自适应
  5. 四栏自适应
  6. 浮动“侧栏”
  7. 内容自适应,侧栏固定
     

更多布局直接看图,一目了然:

    

解决IE6、IE7、Firefox兼容最简单的CSS Hack

很早就在这里看到过解决方案,与嗷嗷讨论后发现这个方案还是很可靠的。当然,唯一的缺点就是每一个属性都要去Hack,但我在很多实践中,只用‘修正’1-2个属性就可以了。

具体写法很容易:

#someNode
{
    position: fixed;
   #position: fixed;
   _position: fixed;
}
  • 第一排给Firefox以及其他浏览器看
  • 第二排给IE7(可能以后的IE8、IE9也是如此,谁知道呢)看
  • 第三排给IE6以及更老的版本看

最好的应用就是可以让IE6也“支持”position:fixed,而且,配合这个原理,可以做到不引入JavaScript代码(仅用IE6的expression),我这里有一个现成的页面,CSS如下写:

#ff-r
{
 position:  fixed;
_position:  absolute;
 right:     15px;
 top:       15px;
_top:       expression(eval(document.compatMode && 
            document.compatMode=='CSS1Compat') ? 
            documentElement.scrollTop+15 : 
            document.body.scrollTop +
            (document.body.clientHeight
            -this.clientHeight));
}

是不是很方便:)

IE和FF的两种”姿态”

如果要在IE和FF下面开发设计Web应用,真是一件磨练人心智的事情。我不止一次的看到这句话“Of course, then, there’s one standard way and one Microsoft way.”
如同上一篇日志提到,这个世界没有真相一样,这个世界也没有标准。没有永远的标准,只有永远的bugs和hacks,至少现在,你无法否认这一点。OK,鞠躬尽瘁,无愧我心已经很难得,足矣。

曾经需要通过JavaScript动态获取元素样式,发现style属性只可写,并不可读。非常奇怪,后来由于js提供了offsetLeft、offsetWidth等属性,也就没有仔细研究。毕竟大多数情况下,获取基本layout数据足够。然而,更复杂的Web应用则不得不面对需要获得,或者批量获得一些其他的属性值,例如“font-size”等。于是开始查阅相关的问题。

由于FF和IE对DOM以及CSSStyle的各自不同的理解,解决这个问题过程之曲折不想过多描述,我只把自己的心得记录下来以飨读者。在FF、IE、Opera、Safari下同时兼容的做法步骤:
1、定义函数getStyle – 参考 http://www.robertnyman.com/2006/04/24/get-the-rendered-style-of-an-element

function getStyle(oElm, strCssRule){
var strValue = “”;
if(document.defaultView && document.defaultView.getComputedStyle){
strValue = document.defaultView.getComputedStyle(oElm, “”).getPropertyValue(strCssRule);
}
else if(oElm.currentStyle){
strCssRule = strCssRule.replace(/-(w)/g, function (strMatch, p1){
return p1.toUpperCase();
});
strValue = oElm.currentStyle[strCssRule];
}
return strValue;
}

用法:

//假设someElement是DOM中某对象的引用,那么通过以下方法可以获得该对象下的字体大小:
var getSize = getStyle(someElement, “font-size”);

2、注意,对于缩略式表达式,FF无法获取!例如“padding:4px”,在FF下面,只能按照标准返回”padding-left”。简言之

var getPadding = getStyle(someElement, “padding”);

是无效的,需要用

var getPadding = getStyle(someElement, “padding-left”);

个人整理的FF、IE的最基本的CSS兼容技巧

结合JavaScript,进行进一步补充、整理。

Updated@2007/3/11 CSS 常见注意事项: http://www.awflasher.com/blog/archives/638 – 转载请保留链接,随时可能修改!

同时兼容IE、FF的基本注意事项:

  1. float的div一定要闭合。例如:(其中floatA、floatB的属性已经设置为float:left;)

    <wrapper>

    </wrapper>

    这里的NOTfloatC并不希望继续平移,而是希望往下排。这段代码在IE中毫无问题,问题出在FF。原因是NOTfloatC并非float标签,必须将float标签闭合。在

    之间加上

    aw提醒您:这个div一定要注意声明位置,一定要放在最恰当的地方,而且必须与两个具有float属性的div同级,之间不能存在嵌套关系,否则会产生异常。并且将clear这种样式定义为为如下即可:

    .clear { clear:both; }

    此外,为了让高度能自动适应,要在wrapper里面加上overflow:hidden; 当包含float的box的时候,高度自动适应在IE下无效,这时候应该触发IE的layout私有属性(万恶的IE啊!)用zoom:1;可以做到,这样就达到了兼容。例如我的某一个wrapper如下定义:

    .colwrapper { overflow:hidden; zoom:1; margin:5px auto; }

    onhavinglayout-绝对不得错过,每一个制作CSS以及用脚本操作DOM的人都不得错过!

  2. margin加倍的问题。设置为float的div在ie下设置的margin会加倍。这是一个ie6都存在的bug。解决方案是在这个div里面加上display:inline; 例如:

    相应的css为

    #IamFloat { float:left; margin:5px;/*IE下理解为10px*/ display:inline;/*IE下再理解为5px*/ }

  3. 关于容器的包涵关系很多时候,尤其是容器内有平行布局,例如两、三个float的div时,宽度很容易出现问题。在IE中,外层的宽度会被内层更宽的div挤破。一定要用Photoshop或者Firework量取像素级的精度。
  4. 关于高度的问题如果是动态地添加内容,高度最好不要定义。浏览器可以自动伸缩,然而如果是静态的内容,高度最好定好。(似乎有时候不会自动往下撑开,不知道具体怎么回事)
  5. 最狠的手段 – !important; 如果实在没有办法解决一些细节问题,可以用这个方法.FF对于"!important"会自动优先解析,然而IE则会忽略.如下

    .tabd1 { background:url(/tab1.gif) no-repeat 0px 0px !important; /* for FF*/ background:url(/tab1.gif) no-repeat 1px 0px; /* for IE */ }

    值得注意的是,一定要将 xxxx !important 这句放置在另一句之上,具体原因很简单,就不说了:)

补充:当时发表这篇文章时,并没有IE7的出现,而且那个时候我也没有很多地考虑JavaScript。这次更新一些。

一、IE6的border。会自动往外加margin。当第一个box和第二个box之间的margin为a时,如果两个box都没有border,那么IE6、IE7、FF下面都没问题。当有border时,FF和IE7的border不会占用它们之间的“空位”,而IE6这个老喜欢“自作聪明”的家伙就把margin给撑开了。我并没有调试是否padding也会有这个副作用,我个人怀疑也有,但是既然把问题分析道这一步了,就不赘述了。解决方案就是判断是否是IE6,然后动态的修补margin。其间涉及到js获取浏览器版本、样式值这些技术。参阅 http://www.awflasher.com/blog/archives/791

二、对于块元素,在IE6下面最好制定宽度才可float起来,尤其是a标签。

三、在IE下,如果采用了list-style-position:inside,那么可能会造成li元素强行往前缩进。 资源网站:

实战DIV+CSS

看来必须抡胳膊上了。本来是准备交给别人去做,结果最后人没来公司……这样不得不自己动手把代码全部重写。今天终于搞定一大部分,受益匪浅。
其实什么事情一定要投入时间投入精力才能做好,如果为了完成认为,为了用div而用div,那意义何在呢?
非常感谢Davidold9抽出时间帮我解决了不少问题,技术和思想上的。

==项目随笔==
对于标准,我没有那么大的热忱,也不是什么绝对簇拥。如果感兴趣,这几篇文章足以解释标准的存在缘由和相关问题。
浏览器大战
也许,我们应该放弃#wrapper
了解真相,到底什么才应该是Opera的BUG,我们应该找谁去抱怨

==资源==
http://www.w3.org/TR/CSS21

我一直坚信,作为一个企业,它关心的应该是如何最大限度发挥div+css的优势;它关注的应该是产品的易用性、兼容性以及执行效率的问题。因此不得不再次重申,我根本没有打算让每一个页面都通过w3c的认证,我决不会为了通过认证而把5k的代码改称7k的或者把消耗3%的CPU的解决方案改称消耗4%的。

回到当初讨论的话题,div+css的优势。其实之前我已经总结过了div+css的优势 Continue reading “实战DIV+CSS”

调研结论:DIV+CSS为什么好?(更新)

DIV+CSS为什么好?
by aw(awflasher.com) 转载请注明出处 – http://www.awflasher.com/blog/archives/583

再论DIV+CSS (Updated Content)

虽然目前在公司相当忙,但是仍然有必要讨论一下div+css的问题。因为它已经不再是两年前那个新鲜的名词了。它正逐渐步入广大传统Web开发、设计人员的视野。它的好、他的坏,已经逐渐开始成为前端开发工程师争论的焦点。

今天偶然看到“一个有将近两年的div + CSS 开发经验和历史,曾经是Web标准绝对拥趸的同志”在自己的blog上发表放弃div+css的申明。我更深感一种悲哀——特别是当我苦口婆心地劝说公司的前端开发人员开始学习DIV+CSS的时候。

不过看看这个“好同志”放弃的理由的其中两条,不禁让我所心冷。

  • 公司领导及客户不关心这个,他们需要的是快速、高效的工作和花哨的页面
  • 所费功夫与收入不成正比,利用table可以大大减少工作量

确实,当今市场环境下,div+css对于一个财力一般的公司是一种奢侈。尤其是对于那种靠业务员疯狂跑业务而存活的(不打算上市)的公司,是一种莫大的浪费。我在广州曾见过许多“三天建站”的公司其中90%的人在外跑业务,然后10%的web开发设计人员把凌乱不堪的HTML代码片段一遍一遍的往table里面塞。

甚至可以这么说,一个公司对div+css的认同和投入,直接决定了这个公司的期望目标,比如上市。好在我现在所在的公司在这一点上是非常愿意付出代价的。

其实,在具体商业产品实现上,并非一定要把自己拘泥于“Web标准绝对拥趸”的角色。我们似乎应该静心思考为什么使用div+css,而不是如何实现某个细节。

我们公司面临的困境则是相反的。就是太拘泥于div+css、为了DIV+CSS而DIV+CSS。这样做是毫无意义的。如果为了实现一个效果而不顾策略强行使用一种技术,是非常失败的一种做法。当然,我觉得这需要设计人员与开发人员的共同努力和让步。尤其是在B/S架构下。设计者肯定要做出更多的让步。比如某个布局中1px的差距能节省3k的HTML文件size,哪怕放弃视觉上这1px的效果,我看都值得。更何况,大多数干扰DIV+CSS布局的设计本身也是极不美观的。

movivi.com的SEO我思考了很多。我觉得最大的问题就出在我们并没有足够吃透W3C上。

当时,当w3c刚出的时候,三大门户十分不屑。清一色的table遍布整个首页。可是这样导致的问题不久就暴露出来了。搜索引擎爬虫难以解析复杂的table,而样式的改版也极为难受。

div+css,这个布局中,div承载的是内容,而css承载的是样式。内容和样式的分离对于所见即所得的传统table编辑方式确实是一个很大的冲击,尤其是设计人员很难接受设计一个他们不能立即看到的样式。不过div+css的好处实在是太明显了:

1、搜索引擎亲和力:搜索引擎不会在意一个页面的设计或者构成。搜索引擎不可能“欣赏”设计漂亮新颖的页面;也不会去“排斥”颜色搭配丑陋的页面。它们只是默默地拿到它们需要的内容就离开。如果一个页面中涵盖了大量的table来描述构架,试想搜索引擎要花多大的代价才可以拿到真正有用的信息呢?
凭我自己的经验,一般来说,table构架描述的页面,样式结构和内容信息大小比可能达到1:1甚至更高。而CSS+DIV构架的页面,虽然在客户端看来下载一个复杂的CSS也要占用差不多的带宽,然而搜索引擎可以很方便的绕过这个css,而直接抓去div中的内容。这便是div的优势所在。带宽的稍多占用,完全显得微不足道,更何况一个冗余的table设计架构如果代码写的不好会占用更多的带宽。

2、重构页面的方便性
这个应用最经典的例子就是各大blog程序了。就如现在我用的LBS系统,以及流行的PJBLOG、php下面的WP、MT,都是采用div+css构架。内容和样式的分离导致我们在重构页面布局(更换皮肤)的时候,只用针对每一个div元素重新定义其具体位置、样式就行了。而在原来的table基础上进行改版,几乎必须改变所有的内容注入渠道,实在是太过于麻烦.
关于韩国风格网站难用div描述的问题,我个人认为在web2.0的大军冲击下,韩国的花哨流派很快会被简约派所代替。如果确实是优秀的设计,我个人认为用Flash来完成更好!

http://awards.cssmania.com/2006/07/07/css-world-awards-winners-2006.php
2006年CSS世界大赛得奖作品,看看什么叫做W3C下的完美艺术吧!看看人家的PR吧!