Facebook的弹出框
很喜欢facebook的弹出框样式,官网是用table实现的,可以看克军抓取的demo页面:pop-dialog-facebook.html
一直想用非table方式实现,晚上尝试了一把:facebook_dialog_test.html

花了一个多小时,仅针对Firefox3,IE8,Safari4,Chrome2和Opera9做了测试。没时间去理IE7和IE6了,有兴趣的可进一步尝试。
2009-05-17:修改了写法,已经支持IE7和IE6. IE6下直接降级为直角,圆角半透明太难折腾了。
一点想法:
- facebook的table实现方案,看起来多了不少标签,而且语义化不太好,但用table实现,思路非常清晰,兼容性也很好。大量采用table实现界面元素的公司,还有google.
- 在背景图尚未下载完全时,对话框的样式满足“优雅降级”。
- 在禁用CSS后,两种实现方案呈现出来的样式差不多。就是标题是h2还是h4的区别。(个人觉得h2更佳,但习惯性写成了h4,囧)
- 我的实现方案在Firefox3等高级浏览器中,一次编码全部通过。只考虑高级浏览器的话,工作量和table方式差不多。
- 在IE6等老旧浏览器下,两种方案表现得都不是很完美。相比而言,table方案工作量少点。
- 或许,我们应该更坦然的去接受table方案?对于这种小模块的布局,table真的很好用,实现的技术门槛很低。
语义,也许就如诗歌一样,努力去做,可以很优雅很美。但绝大部分世人更喜欢通俗小说,诗歌在现实面前是种奢侈品。

May 17th, 2009 on 2:58
赞,比克军的结构更清晰。
May 17th, 2009 on 13:05
其实还是有很多没有意义的标签,还不如用table实现更为快捷方便
May 17th, 2009 on 17:09
非常不错
May 17th, 2009 on 18:04
弹出框是JS生成出来的。。。SEO无关,首先考虑健壮性和灵活性,有余地再考虑语义。
May 17th, 2009 on 18:42
学习!!
May 18th, 2009 on 10:03
同意。不能舍本逐末。要在可扩展\语义\灵活性\兼容性\成本等方面作出合理的抉择。而不是看见TABLE就喊打。
May 18th, 2009 on 10:54
曾经在校内干过一段时间,这类弹出框原本就是用来替代简陋的alert的,由脚本注入,并非页面信息原本的一部分,在这种情况下太纠结table就没有多少实际意义了。
我一直认为语义之针对信息类页面的,比如blog,比如CMS,比如门户,这些大量文字信息的页面需要认真考虑语义,考虑用户禁用掉脚本及CSS之后的信息是否完整,是否友好,对于盲人等使用屏幕阅读器的用户而言是否依然能够顺利得获得较为完整的信息。
而对于功能性网站,比如gmail,为了实现一个圆角按钮嵌套N层标签,并且标签上一堆class:“goog-imageless-button goog-inline-block goog-imageless-button goog-imageless-button-collapse-right goog-imageless-button-primary goog-imageless-button-hover”这或许不是一种很语义很优雅的实现,然而功能实现比语义和优雅更重要。这也是为什么当下前端人员没有地位,被逼做IT民工中的掏粪者的主要原因。
对于很多企业而言,我要的只是结果,只要各浏览器不错位,不报错,能用就成,所以DIV+CSS才如此风行,的确,DIV+CSS已经足够应付了。如果还是用建筑来做比喻的话,对于国际性的大型建筑,当然得注重模块化设计,得注重合理的架构,但是对于一些小民房而言,我让那些乱七八糟的规矩见鬼去吧,我就用砖头,我全部都用砖头,怎么着啊,我照样能盖房子,我连下水道都可以拿砖头砌,你或许还没我这本事呢。真是应了那句话啊,流氓会武术,谁也挡不住,而现今国内前端行业的只会武术招式,不懂内功心法的“流氓”真是太多了……
你们这些国内一流的高手说不定哪天就会遭遇“武功再高,也怕菜刀!”这样的尴尬……W3C自身的混乱,浏览器的混战,用户的不了解,老板的不买账,待遇的凄凉,地位的卑微,唉,我实在是坚持不下去了,我要转行……
May 18th, 2009 on 11:05
呵呵,去年就订阅你博客了,今天情绪有点激动,愤青了下。补充一点,对于许多功能性网站而言,设置好tabindex和Accesskey或许比追求完美的语义更靠谱。毕竟语义就跟你说的一样,是诗,不是什么人都能写好,也不是什么人都能读懂,都能注意到,都能领会……而tabindex就像板砖,Accesskey就像菜刀,比较大众化,当然Accesskey目前还鲜为人知。
May 18th, 2009 on 13:18
呵呵,想法与我去年做jQuery弹出窗口时一样,但我最后还是选择使用table,那时IE6还是绝对主流,IE7还在bate,
你可以瞄一眼这里,studynote.cn/labs/yybox/
May 18th, 2009 on 13:26
要我自己的 项目,就直接用 -moz(webkit)-border-radius:5px; 和 background-color:rgba(0,0,0,.5);
另外给 ie, opera 再设置个实色好了
身为一个浏览器,被强迫了那么多年去做自己做不到的事情,实在是悲哀
May 18th, 2009 on 16:11
从来没有自己写代码去实现某个效果过,向来都是抓来直接使用。。。
May 20th, 2009 on 20:47
table结构比非table结构要生成的DOM节点要多,在浏览器页面渲染速度方面非table结构有一定的优势,所以如果要实现这一效果,我会选择非table的方法
May 27th, 2009 on 17:34
身为一个浏览器,被强迫了那么多年去做自己做不到的事情,实在是悲哀 +1
IE6多可怜呀… 哎……
June 2nd, 2009 on 11:33
刚封装过一个类似组件,这个模拟弹窗,最复杂的其实是在定位上。很多效果看起来差不多,实际大不同。需要考虑的情况比较多,比如让弹窗保持在浏览器可见区域垂直居中:
1.获取浏览器可见区域高度,在ie和ff里需要做兼容处理
2.如果背后有半透明遮罩,还需要判断网页的offsetHeight是否大于浏览器可见区域的高度,以及出现滚动条,还需要读取滚动条位置
3.如果浏览器窗口在使用过程中进行了缩放,特别是有弹窗弹出时进行缩放,该怎么处理
4.如果网页上有折叠部分,通过脚本展开改变了网页的高度后,又该怎么处理以给弹窗的定位或遮罩层的显示提供环境变量?
leave a reply