Revelation of HTML5, CSS3 and more…

Robin — Sat, 07 Aug 2010 10:38:49 +0000

就在我还在写这篇文章的时候，HTML5的标准还在不断完善。当然，开发者已经习惯W3C和其他“砖家”组织慢慢吞吞的编写，再加上W3C和WHATWG的恩怨，“~~2020~~2022年才会成为Proposed Recommendation”实在是意料之中的事情。

但是看看现实状况，你会非常有喜感，Safari 5、FF3、Chrome 5都已经支持了60％以上的HTML5功能，甚至连IE9 Preview3里面都有好多新功能的支持。

我们何去何从？

完全放弃之前的HTML是不可能的，广大的IE用户群会让你发疯。但这本身就是一种博弈，你如果继续将IE，尤其是IE6作为你的WebApp的主要客户端，那么你就在助长IE6，到头来让开发者更痛苦。

Yahoo所提倡的Progressive Enhancement和Graceful Degradation是两个美好的准则，面对于日益扩张的产品线、快速的产品更新速度，让你觉得多花一行代码给那些垃圾浏览器做功能支持都觉得蛋疼——有时候你甚至连SWFObject都不想用。

当然，我们不能继续停留在抱怨诸如IE之类（也就只有IE）这种垃圾浏览器的怪圈之中。

现在，已经有开发者拥有足够勇气去放弃IE6的支持了。包括google在内的一线厂商，实际上已经再为高级浏览器和IE6单独开发不同的版本的应用。也就是说，如果用户使用老掉牙的IE6进行浏览，他会看到一个催促他们换浏览器的对话框，以及一个Web 1.0的传统应用程序（没有ajax、没有canvas、没有offline功能）。

好吧，在做出这个决定的时候，你可能要说服你的主管去做用户调研以及SWOT分析。

我们不得不承认，我们自己和那些使用高级浏览器的用户没有理由去忍受因为某些弱智浏览器而削弱的用户体验。用户喜欢圆角边框、界面动画、离线存储和更智能的表单等等。

好吧。那些高级浏览器就很好么？其实，大家又回到了上次浏览器大战。Netscape和IE不断的添加自己的私有属性和方法，这就是这次我们遇到的。

诸如”-webkit-”、”-moz-”之类的前缀根本就无法通过W3C的验证，而你也无法保证这些私有的CSS属性的效果是一致的。也许大家写一个CSS3的旋转就得这个样子：

.box_rotate {
     -moz-transform: rotate(7.5deg);  /* FF3.5+
       -o-transform: rotate(7.5deg);  /* Opera 10.5
  -webkit-transform: rotate(7.5deg);  /* Saf3.1+, Chrome
             filter:  progid:DXImageTransform.Microsoft.Matrix(sizingMethod='auto expand',
                     M11=0.9914448613738104, M12=-0.13052619222005157, M21=0.13052619222005157, M22=0.9914448613738104); /* IE6,IE7
         -ms-filter: "progid:DXImageTransform.Microsoft.Matrix(SizingMethod='auto expand',
                     M11=0.9914448613738104, M12=-0.13052619222005157, M21=0.13052619222005157, M22=0.9914448613738104)"; /* IE8
               zoom: 1;
}

实在是太华丽了，这一条CSS规则就可以增大3到4倍，乐观估计整个CSS文档会因为兼容性需求增大2倍吧？

那JS方面呢？webkitTransitionEnd、webkitAnimationEnd⋯⋯乖乖，你这兼容性到底怎么做？

门户站点的前端工程师会哭的，所以HTML5的使用真的是要深思熟虑，考虑到自己的目标浏览器。

总是有人诟骂Adobe Flash是个私有技术，不如HTML5通用，就目前这种状况，现实版的HTML5就是每个浏览器厂商的“私有技术”。每个公司都维护这一套自己的命名规则，自己的文档⋯⋯原来W3C所提倡的“共产主义”就和XX一样⋯⋯

那HTML5真的是爷爷不疼奶奶不爱么？

面向广大的PC端，HTML5的应用需要大量的兼容性代码，甚至考虑到制作IE的降级版本，这个成本，对于小巧型的APP完全ok，做Gmail级别的？还是别找刺激了。

个人认为手机市场才是HTML5的天下。本身手机市场里，系统软件和手机本身都有开发商控制。iPhone下跑Safari的人绝对是占大多数，如果做iPhone4的webapp，完全有可能按照Apple的那些私有版本的HTML5写程序。基本上，满足了webkit引擎，大部分的智能机你都可以搞定了。

再加上还有个WebOS的概念在，可以期待HTML5在移动平台上会先火起来！

另一个HTML5的栖息地，可能是各大厂商的研发中心里。HTML5给了广大开发者另一个快速原型工具。以往，一个设计流程走下来，最终不管你愿意与否，你只能用Flash去实现那些复杂的动画和应用程序逻辑，但是我们现在有Flash。

CSS3的Animation和Transition，HTML5的Canvas足以满足大部门DEMO的要求了吧？

虽然这样，HTML5和CSS3已经“沦为”一个RPD工具了，但是它仍旧证明了其价值所在。

在那些CEO眼里，HTML5也将成为遏制Adobe Flash扩张的法宝。微软的Silverlight如此疲软，Apple也是希望能够将效率地下的Flash敢出移动平台⋯⋯

好吧，让我们拭目以待。我们能做的，可能只有把HTML5和Flash全部学一遍吧⋯⋯泪⋯⋯

Let Thickbox conquers Flash

Robin — Fri, 29 Aug 2008 09:08:37 +0000

大家都知道我们无所不能的Thickbox竟然不能支持Flash的载入。虽然将SWF文件当作iFrame内容直接用Anchor引用，可以在 IE下正常显示flash内容，可惜在FF下无用。在Thickbox还没有做出更新的时候，我们该怎么在Thickbox里面显示Flash呢？曾经有人提出过改版的Thickbox，可以他没有继续更新。

今天突发奇想，干脆写个PHP页面，然后当iFrame引用吧！

我这里示范一下用Thickbox打开FLV播放器并播放指定文件的例子吧。（其实这个ELFVision里已经得到了使用）
这里使用的JW FLV播放器支持N多的参数和外部脚本，我们只订制了它播放文件、长度、宽度和自动播放，这四个非常基本的参数。如下是默认状态下的播放器代码：

接下来我们自己编写一个videoPlay.php页面来作为iFrame的内容，并在使用中向videoPlay.php传递参数。（小弟在写这篇文章的时候特地花了几十分钟学PHP，对，就是几十分钟）在ELFVision中的videoPlay.php页面代码如下：




 Video Player - ELFVision

基本都是静态代码嘛……呵呵……

在正文中，可以像这样调用：

查看该视频

其中排开实现thickbox所传递的参数外，x代表宽度，y代表高度，link代表FLV文件的绝对地址，autop代表是否自动播放。之所以这样命名，是为了防止和thickbox的参数冲突。这样，Thickbox就成功调用了！

另外一个很奇怪的事情就是，调用WP内置的Thickbox来显示Flash，其窗口宽度和高度会无缘地增加30px和10px。目前为止笔者还不知道原因，所以我在传递thickbox的width和height的时候分别用真实值减去了30和10，暂且算是解决方案吧。知道真相的同学记得告诉我哦！

PageTalks » flash

Revelation of HTML5, CSS3 and more…

Let Thickbox conquers Flash