xml地图|网站地图|网站标签 [设为首页] [加入收藏]
改变游戏的20个HTML5网站,关于HTML5的11个让人难以
分类:web前端

2011年HTML5的六大趋势

2011/12/09 · HTML5 · 1 评论 · 来源: csdn     · HTML5

导读:HTML5无疑是2011年度最耀眼的技术明星,它的威力使一些论者认为Flash、Silverlight和Win32这三大曾经的主流开发平台都进入了垂死期,它也将主导Web与原生应用(Native App)的未来走向,甚至对各移动操作系统和Apple、Google、Facebook、Amazon等几大平台公司的此消彼长也会产生深远影响。

ReadWriteWeb的年度回顾系列文章当然也少不了HTML5的身影,Dan Rowinski撰文比较全面地总结了HTML5的六大趋势,也是目前Web开发不错的趋势总结。

HTML5正在彻底改变技术人员开发Web应用的方式。无论是在桌面还是移动,这个未来的语言和标准都已经不再遥远。移动领域最热门的争议——“Web应用还是原生应用?”将随着HTML5的发展变得无关紧要。

2011年,HTML5都发生了哪些事情?我们一起来看看。

1. 移动优先

ReadWriteWeb已经将“2012最具潜力公司”称号授予了appMobi,一家HTML5创业公司,重点放在移动优先开发。事实上,随着手机和平板设备的爆炸性增长,移动优先已经成为开发社区的大趋势。

今年,我们看到了许多大公司开始移动优先的项目。《金融时报》将其iPad应用从Apple的App Store中撤下,只开发Web应用,结果取得了不错的效果。不少游戏开发者也开始转向移动Web开发。

新的一年,首先开发移动Web的趋势将会持续。其实,用户并不关心应用是用什么技术写的,只要好用就行。Web应用和原生应用的界线将变得模糊。

Mobile First(移动优先)的口号最初是由Yahoo前首席设计架构师Luke Wroblewski提出的, 已经获得了业界的广泛反响。他提倡产品研发团队首先针对移动设备设计,这不仅是因为移动设备现在数量庞大而且在飞速增长,而且因为移动设备的限制能迫使我 们改变旧习惯,先做减法,更关注产品最本质、最重要的方面,同时更多地注意性能和使用场景,反而最后会得到更出色的用户体验。当然,移动设备中丰富的传感 器、摄像头等等硬件,也为产品提供了更广阔的空间。

2.游戏开发者率先转向HTML5

游戏开发者转而开发Web版本的动力是显而易见的:他们是使iOS设备更具吸引力的主要因素,可是无论销售收入还是应用内付费收入,却都要给 Apple分成30%。HTML5对Facebook这样的游戏平台更是至关重要。想想看吧,如果不借助HTML5和Spartan计 划,Facebook怎么能在移动平台上在Apple抽成之后继续成为平台与游戏商分成?

然而,HTML5游戏开发是非常困难的。领先的HTML5游戏开发商Moblyng CEO Stewart Putney 8月时就对ReadWriteWeb说过,你知道用HTML5开发德州扑克有多难吗?

当然,通过PhoneGap和appMobi的XDK等方式将Web开发出来的代码包装为原生应用也是一个方向,Facebook的iOS应用就是这样做的。

3. 响应式设计

多种屏幕大小是移动开发的一个难点。为此,Ethan Marcotte在A List Apart上发表了Responsive Web Design一文,第一次提出了响应式设计的理念,即让内容能自动适应任何屏幕大小。(推荐阅读:《什么是响应式Web设计?》)

波士顿环球的网站BostonGlobe.com是响应式设计的一个绝佳范例。从网站开发者Filament的采访中可以知道,要做到这一点并非易事,一些基本概念必须从最开始就要考虑到,而如何处理来自第三方的图片和广告,也是头痛的问题。

4. 设备访问

Web应用和原生应用最大的区别之一,就是浏览器内运行的代码传统上无法访问某些硬件设备和底层特性,比如照相机、传感器、日历、联系人等。而HTML5将有望解决这一问题。

5. 离线缓存

在离线的情况下无法使用,也是Web应用的致命局限。而HTML5中的离线缓存将大大改善这一情况。2011年最大规模的离线缓存部署,是Amazon的Kindle云阅读器,能够通过各种浏览器实现本地同步。一旦这一技术成熟并得到广泛运用,原生应用的来日也就不多了——Web应用平滑部署、跨平台的天然优势太大。

Mozilla的Fennec移动浏览器项目中的离线缓存也值得关注。

6.开发工具的成熟

8月时,畅销移动Web图书作者Brian Fling曾经写了一篇非常有价值的文章Anatomy of a HTML5 Mobile App(其中的HTML5移动应用解剖图非常棒,如下),文章最后指出了实际从事HTML5项目时要考虑到的点:

时间因素,HTML5项目可能耗时更多

预算因素,这可不是简单的网站,成本不低

公司里是否有足够的人才?

基本上没什么工具,很多时候都要自己搞定

考虑所有选择,移动世界里没有绝对的对错,勿自设框框,专注客户的需求

其中的工具问题,随着appMobi、Sencha、Appcelerator等厂商(应该还有Adobe、微软?)的加入有所缓解,但与原生应用开发环境相比还远远不够。相信2012年将有更大发展。

图片 1

HTML5移动应用架构图

总结

HTML5 的其他功能包括表单和许多新标准还将快速演进。随着标准化工作的进行,HTML5可能最后还是会变回为HTML。HTML5的领导厂商包括Sencha, Adobe, Appcelerator, appMobi以及Facebook, Amazon和Google等巨头。

对于开发者来说,无论你是开发Brightcove那样的新型视频渲染,还是SoundCloud那样酷的HTML5音频实现,这都是一个令人兴奋的时代。从桌面到移动Web,HTML5正在使Web真正的杀手级应用——浏览器成为创新的中心。

赞 收藏 1 评论

图片 2

2011年回顾:改变游戏的20个HTML5网站

2011/12/23 · HTML5 · HTML5

英文原文:2011 in review: 20 HTML5 sites that changed the game,编译:webapptrend

今年HTML5确实给我们带来了很大的冲击。HTML5 Doctors,Oli Studholme评选出了20个最佳网站,它们涵盖了语义、音频、客户端web apps、canvas以及SVG和WebGL,这些网站预示了未来web的发展方向。

对HTML5和web来说,今年是收获丰富的一年。HTML5在不断成熟,今年5月HTML5进入了Last Call阶段,并计划在2014年完成标准制定。WHATWG不仅大力提升了HTML5现有的功能,还加入了诸如WebVTT这样的一些新功能。在浏览器上的进展也在逐步推进,目前正与五大提供商积极推进相关工作。还有很多的工作需要去做!

在内容方面,你能深切感受到这一年似乎真的就是HTML5的一年,CSS3和JavaScript web stack的时代已经到来。HTML5现在已经成为许多开发者的首选,有关HTML5新功能的探索工作也在积极展开。下面列举了一些特别突出的HTML5网站。其中许多网站会让人惊呼“这根本不可能在native web上实现”。

图片 3

关于HTML5的11个让人难以接受的事实

2012/01/01 · HTML5 · 2 评论 · HTML5

英文:11 hard truths about HTML5,编译:WebAppTrend

HTML5为Web开发者提供了很多强大的新特性,但是它的一些特定的限制会让它无法和本地应用匹敌。

HTML5整合进了很多新的特性,并且有可能提升Web编程模式。和每一个阅读技术资讯的人所知道的一样,没有任何一样东西能像HTML5对互联网造成更多改变。在代码中加入一些HTML5,网站会变得更快更炫。但是HTML5能为那些想要要网络上实现本地应用表现的人做什么可能不在此列了。

在享受了HTML5的新标签以及APIs之后,现在已经是时机来承认HTML5模式确实是有一些限制的。这些限制不但会让我们对HTML5的幻梦破灭,还有可能让我们在某些场合不再使用HTML5。

事实上是,尽管HTML5确实有很强大的功能,但它并不能解决所有问题。它的一些附加功能是非常强大的,能让Web apps成为native app的强有力的对手,但是安全问题、本地数据存储的限制、同步问题以及政治问题都会让我们减小对它的期望。毕竟,任何技术都是有其限制的。

下面是Web开发者需要接受的一些关于HTML5的事实。

 事实1:安全是一场噩梦

客户端计算最根本的问题是用户最终拥有了对机器上运行的代码的控制权。在Web apps中,当浏览器拥有一个很强大的调试工具的时候,这种控制权比以往更容易被滥用。

当在浏览器中集成了一个Javascript的调试器比如Firebug,任何对Facebook、Google以及其他网站感兴趣的人都可以插入断点来查看代码。这对于了解网站是如何运行的是非常有利的,但对于安全问题来说却是一场噩梦。

想象有个变量的值是你想要改变的,Firebug或者其他一个浏览器调试器可以让你很容易地将数据改成你想要的任何数据。你想要通过改变你的地理位置来捉弄一下你的朋友吗?那么你可以修改浏览器中的经度和维度变量,让浏览器“处于”世界上的任何位置。所有你的Web应用的neat features都可以被修改,浏览器使得这样的修改比在本地应用中更为容易。

对于引发的安全问题,也是有些限制的。一些Javascript工具比如Google Web Toolkit和标准的编译器一样复杂,它们的输出是非常令人费解的。但是一些工具比如JavaScript Deminifier能解决这个问题。

威胁当然也跟应用性质有关。一个人通过改变浏览器上显示的经纬度来和朋友开玩笑说在环游世界的途中是一回事,而获得其他人的权限又是另外一回事了,这会带来威胁。一旦涉及到金钱,情况会更糟糕。所有这些都意味着基于客户端的HTML5是不能用来处理敏感数据的,每个人都应该对自己的能力加以警醒。

事实2:本地数据存储是有限制的

浏览器中隐藏的本地数据库让Web应用更容易在电脑上缓存数据。对任何一个在浏览器中享受这种台式机体验的人来说,这些数据库可以节省带宽,提升性能。然而它们肯定比不上本地应用的数据的强大功能。

HTML5的数据存储能力毫无疑问是很重要的功能,但是你仍然不能将存储的数据迁移到另外一台机器上,或是制作副本、备份、用另外一个应用打开。所有这些数据都是隐藏在浏览器之下的。

某种程度上说,这是最糟糕的一种情况。因为你要承担存储这些数据库的所有责任而不能对它有任何控制。

一些最新的浏览器可以让你看到在你的机器上创建了哪些数据库,但这些信息是有限的。Safari甚至可以让你能够删除数据库,但是你不能浏览这些信息或是将它们迁移到另外一台机器上,这些文件在设计之初就没有让它能够很容易迁移,尽管你可以做到这一点,如果你知道到哪里找这些文件的话。

你同样不能深入到文件中看到底存储了什么。当然,一个程序员可以看懂这些文件,但前提是他们研究清楚了文件格式并且做一些hacking。这些文件不像表单或者文本可以很容易地荣任何编辑器打开,使得它们不像本地应用那样容易被人们读懂。

事实3:本地数据可以被操纵:

用户可能并不拥有对数据的控制权,但是网站同样也被限制不能处理用户数据。用户换浏览器了?用户换机器了?很多Web开发者对此都无能为力。因为同步问题,他们不能让用户创建更多数据。

Web开发者也需要担心本地数据库的安全。尽管没有工具可以让用户可以很容易修改本地数据并升级权限,但服务器同样也没有能力去阻止用户做到。所有因为运行用户修改Javascript代码的安全漏洞同样会影响数据库。它们门户大开,等着有人写一个Greasemonkey脚本或一些本地代码去更改数据。

事实4:离线数据对同步是一场噩梦

HTML5的本地数据存储极大提升了离线使用Web应用的能力。唯一的问题是数据同步。

如果一个Web应用连接到网络上,它可以持续地将数据存储到云中去。而当应用离线时,应用中发生的数据就不能存储到云中。如果一个人切换了浏览器或者使用了不同的机器,就会出现副本,这时同步就会成为一个大问题。更糟糕的是,时钟本身就可能是不同步的,使得发现最新被保存的数据是不现实的。

当然,这对本地应用来说也一直都是一个问题,但是在本地应用中,为同步负责的是人,他可以通过查看文件名并改变日期来进行同步。但是因为HTML5并没有给用户对隐藏在浏览器之下的数据库的控制权,开发者必须提供用户界面让用户通过这个界面来管理同步问题。

这并非是一个完全棘手的问题。开发人员可以通过使用版本控制系统来处理这个问题,而现今的版本控制系统在处理这些问题上已经变得越发复杂了。但拥有这项技术并不意味着这是一个很容易使用的解决方案。合并不同GIT库是件很费时间的事情。HTML5开发者们需要先处理好这些问题,才能管理HTML5 Web应用的同步。

事实5:云端什么都没有向你承诺:

为HTML5将数据存储在云端而带来的所有结构性的问题来责备HTML5实际上不是件很公平的事情,但云端是一个必须的部分,因为云省去了安装软件和备份数据的麻烦。

由于HTML5本地数据存储的限制,大量Web应用存储仍然要保留在服务器端,但这可能是灾难性的。就在最近Facebook决定将不再使用一个基于Linux的插件来上传照片,结果,这个插件去掉的,同样被去掉的是通过这个插件上传的照片

这样的例子比较少见,但是因为各种原因,它们正变得越来越多。你能确保那个可爱地免费提供他们的一切HTML5应用的新兴公司在几年后甚至几个月后还存在吗?你只能自求多福。

情况还更糟糕。正如很多Web应用所明确说明的那样,这些数据并不是你的,在大数情形下,你不能诉诸法律来恢复数据。有些更离谱的服务条款甚至说数据可以“没有任何原因”就被删除。

HTML5不仅没有避免这个问题,它的结构实际上是保证了任何由你的浏览器缓存的数据都会存储在云端,这些数据是脱离了你的控制的。HTML5的炒作说这是它的一个优势特性,但这实际上却很容易造成不利影响。

事实6:强制升级并非是每个人都想要的

有个故事,或许是杜撰的,说一个人使用Gmail账户和酒吧里认识的人保持着随意的联系。当Google+出现以后,所有的历史记录都出现了,因为Google+在论坛里自动连上了那些旧的地址。每天,这些旧名字和旧面孔都会出现询问是否要加入到论坛中去。

当Web应用公司需要升级的时候,他们会将所有人一次性升级。尽管这据说是为了让用户不再受升级安装文件之苦,但对于那些不想使用新特性的人来说,这确是一场噩梦。这不像上面是一个关于人们隐私的问题。新软件可能因为新旧软件包之间的依赖关系而经常崩溃。

事实7:Web Workers并不会处理优先级

Web Workers(译者注:一种新的 JavaScript 编程模型)是HTML5的一个非常耐人寻味的特性。与其去使用Javascript传统的wait、delay和pause命令,现在Web开发者可以拆分他们的命令并且整合到Web Workers的CPU hogs中。换句话说,HTML5 Web开发者可以让浏览器表现得像操作系统一样。

但问题在于,Web Workers并没有复制操作系统的所有特性。尽管它提供了一种方式来讲负载分支并分离,但是却没有方法来管理负载或是设置优先级。API只是让消息传入或者传出Worker对象。这就是它做的一切了,剩下的都交给浏览器了。

CPU丰富的应用比如code crackers会潜入流行网站的后台吗?用户被交给会周期性被窃取的网站了吗?病毒已经附在一切有用的软件上了,那么攻破网站就只是时间问题了。而用户面对这一切能做的很少,因为他们没有办法去监测或者跟踪Worker objects做了什么。电脑被重定向到指定网页的时候只会越来越慢。

事实8:格式不兼容比比皆是

HTML5引入了<audio>和<video> 标签,第一眼看上去,它们和图像标签一样好用。只要在其中加入一个URL,浏览器就会引入数据流。然而,如果它真有这么简单的话,为什么我浪费了两个星期来让所有主要的浏览器可以播放基本的音频文件呢?

个别浏览器构建者只实现了部分而不是全部的音频视频格式确实不是HTML5委员会的错。大家都是人,都想要争夺统治权。往往在一个浏览器上工作正常的文件到了另外一个浏览器上却不能工作了。开发者要如何测试这一点呢?API开发者非常聪明,他们加入了canPlayType函数,但就是这个函数也不是所有浏览器都支持的。

事实9:各浏览器的实现是独立的

HTML5的田园诗般的愿景是一回事,其实现的蹩脚的现实是另一回事。诚然,程序员正在尽他们最大努力来实现架构师的梦想,但就是有一些标签和对象无法正常工作。

例如,有很多理由去喜欢HTML5的地理定位API。它提供了对隐私的一定程度的包含,对精确度也有控制。要是它能一直一贯地工作该有多好——有的浏览器就会总是超时,这个浏览器还是不太聪明,因为它应该知道台式机上是没有GPS芯片的。

最后,人们会去抱怨浏览器没有完全实现HTML5的特性,而不是去责备API本身的结构问题。这一事实凸显了Web开发者在开发基于HTML5的Web应用时所面临的挑战。

事实10:硬件idiosyncracies带来新的挑战

抱怨某些浏览器构建者超出了职责要求而提供更好的性能表现似乎也不公平,但这并非是恩将仇报。一个法拉利拥有者在绕过了一个灯杆以后,他就会发现有时候额外的动力并非总是好事。

Microsof通过将IE和低端硬件驱动整合而提升了IE浏览器中画布对象(Canvas object)的性能。它甚至做了一些游戏比如pirateslovedaisies.com来显示其性能。

但现在程序员们需要注意这些附加功能是否能够实现,并且这些代码的运行速度也是无法保证的。

例如,pirateslovedaisies.com的游戏设计者设计了一个开关来开启或者关闭IE支持的特性。但是,有没有一个API来告诉你这些特性是什么呢?没有。最简单的方式是通过浏览器名字来进行测试并估算帧速率。很多游戏开发者都有多年经验来了解可用硬件的范围,唯一的解决方法就是禁止创新,但这将是Web开发者又要解决的一个新的问题。

事实11:政治一直都存在

有个叫Ian Hickson的人,是HTML5标准的主要起草者,也是生命的最高独裁者(the Supreme Dictator for Life)。我想他们这是在开玩笑,因为这样的头衔实在太不匹配了。标准的编写者只是在提出建议,浏览器公司的编码天才们才是最终做出决定的人。他们可以选择实现或者不实习某个特性,然后Web开发者就要去测试结果是否稳定。几年以后,标准就会根据与实现程度的匹配情况做出改变。

很多Javascript开发者将兼容性问题都留给了开发代码库的人,比如jQuery。这些层让我们不必去了解不同浏览器之间的差别。但是,这些代码在将来是否足够健壮?只有时间才会知道。

这个议题凸显了这个领域中最根本的问题。我们想要自由、创造性以及因为浏览器间的激烈竞争而产生的丰富特性。创新的脚步非常快,但是因为浏览器开发者都争相添加新的特性以赢得先机,使得各个浏览器之间有更多的不同。

但我们希望能有一个统一的指挥者这样就能获得稳定性。但是,对于独裁和自治间的争斗,从来都没有一个理想的解决方式。与其为这些差异头疼,我们或许想要听听Winston Churchill对下议院所说的话:“事实上,民主是一种最糟糕的政府形式,除非其他的形式都经过了一次又一次的试验。”

 

赞 收藏 2 评论

图片 4

语义

1. HTML5的Web开发人员版本

将HTML5的Web开发人员版本列举在这可能有点奇怪,因为它只是一个HTML5标准的版本。一直以来W3C的标准有点让人费解,因为它是为web浏览器开发人员编写的,而不是网站。但是HTML5标准出人意外的具有非常好的可读性,并且里面列举了大量的实例。如果你以前有过阅读W3C标准的痛苦经历,或许HTML5的标准会让你喜出望外。

HTML5的Web开发人员版本是由Ben Schwarz 和同行一起制定的,诣在“为web开发人员提供基础的标准指南”。它是对浏览器提供商版本标准的修改,更适合web开发人员阅读。除了印刷风格具有更好地可读性外,还提供了许多HTML5的附件。它使用了Offline Cache,能够支持浏览器使用<progress> 和AppCache API。search-as-you-type功能也支持离线访问,搜索框使用type="search"

它告诉人们怎么做一些了不起的工作。Ben将这个作为一个志愿项目,并且可以在GitHub上找到所有的资源。web开发人员能够借助这些资源开发各种HTML5应用。

图片 52. Move the Web Forward

Move the Web Forward是由Mat Marquis, Aaron Forsander, Connor Montgomery, Paul Irish,Divya Manian, Nicolas Gallagher, Addy Osmani和一些朋友一起编写的,它告诉人们“如何按照自己的理想打造一个了不起的web”。 里面列举了各种你能够用来优化web的方法。

网站陈列了HTML5代码,使用data-* 属性能够实现Twitter中的hashtag搜索功能。里面还有一些方便阅读但是没有实际意义的申明:

图片 6<!DOCTYPE html``是一个重要的位,可以触发标准模式。)总之,所有的这些资源都诣在帮助开发者打造更加优秀的HTML5网站,Move the Web Forward中的信息是非常有用的。Beyond the Blue Beanie?, Stephanie (Sullivan) Rewis评论说:“俗话说得好,众人拾柴火焰高。有这么多人参与,必然能够推动web快速发展。现在大家应该团结起来,让web的风潮来得更猛烈些!”在Addy Osmani的The Smashing Guide To Moving The Web Forward中有更多相关讯息。

图片 73. Boston Globe

Boston Globe是一个典型的完美商业“响应web设计”网站。遵循移动优先的原则,即使是在不支持媒体库查询或是JavaScript的老版本浏览器上,它也依然能够正常运行。Filament Group的Scott Jeh表示“网站的所有功能都特意被设计为不依赖JavaScript,但是在支持JavaScript的浏览器上,它可以利用各种丰富的JavaScript驱动接口提升应用的功能”。

Scott还指出“我们选择HTLM5主要是出于几点考虑。其中最重要的一点就是,它是面向未来友好型的协议,它提供了丰富的功能能够满足我们的各种需要。例如,我们大量使用了data-``属性,用来配置行为选项或是融入内容的增强功能,当然,HTML5能够使用新的语义元素代替以往的div/p/span,这些元素非常有用,对我们很有帮助”。

图片 8Audio

4. Anatomy of a mashup

Anatomy of a mashup中融入了他对音乐的热爱,DJing,datavis以及很酷的web技术。

混搭的Definitive Daft Punk音频利用了<audio> API和<canvas>,以及CSS3的变形和效果转换功能,将音乐变得可见。Cameron表示“所有的波形和光谱都是根据音乐实时变化的,这样你就能够在你的浏览器上看到音乐的变化了!”未来证明Flash还有市场,Cameron使用了一个自定义的Flash app采集音频数据。关于HTML5,Cameron表示“我热衷于HTML5开发最重要的原因就是开发的直接性;我能够编辑一个JavaScript文件,刷新一下,我立即就能看到修改的效果。不需要编译,也无需额外的插件。一切就是这么简单直接。”

图片 95. SoundCloud

SoundCloud 提供了声音录制和共享服务,大受艺术家和DJ们的欢迎,他们能够使用SoundCloud分享自己的合成音乐并且吸引更多的粉丝。它也是一个很好的HTML5教学实例。在桌面web app上通常用Flash播放音频,而现在还可以选择使用HTML5 Audio。这样SoundCloud还能在iPad上运行,最近发布了一个基于HTML5的工具。

除了使用<audio> 和 Audio API外,他们还在许多地方使用了data-*属性,以及Canvas,SVG和LocalStorage。Matas Petrikas表示“我认为我们使用Canvas渲染波形部件是一个非常明智的选择,相比于Flash,它极大的减轻了CPU的占用率”。不幸的是,还是有一些用户对此嗤之以鼻(虽然确实存在一些客观原因),不愿意使用HTML5的新元素和属性(虽然这一现象正在逐渐改变)。

然而,HTML5音频并不是唯一的选择,正如Matas所说的“HTML5 Media API在web浏览器中的实现状况不佳”。为了解决这个问题,Tomás Senart和Yves Van Goethem做了一套“Are We Playing Yet?”的音频测试工具。Matas表示“大家的反应非常棒,几乎所有的浏览器提供商都参与了进来,我们对2012年充满信心!”

移动设备上还存在一些其他的问题,如:声音录制问题,缺乏广泛的position:fixed 的UI支持,移动浏览器的更新不够及时——Android WebKit正逐渐变为现代的IE6。因此,SoundCloud大力提升了它在iOS和Android上的native apps。Matas说“我们希望能够尽可能为用户提供最好的体验,但现在移动浏览器还没能跟上”。但是他未来仍然充满信心:“我们非常看好即将推出的设备API(getUserMedia),我们希望将来能够不依赖Flash直接在浏览器上处理声音”。

虽然目前的规范和浏览器还存在这样或是那样的问题,但是毫无疑问,这些问题肯定会很快得到处理。比如Mobile Safari现在已经能够支持背景声音GeoLocation以及速度感应器了。虽然目前还存在这些问题,但Matas认为,与Flash相比,“HTML5版本的开发是一个相当快的过程。调试和优化都简单得多。这使得我们能够更轻松地开发或者重建应用,而最终的用户也会从中获益!”

图片 10

6.The Wheels Of Steel

Scott Schiller开发的The Wheels Of Steel由两个唱片和一个混音器构成,可以在浏览器中运行。在浏览器支持的情况下它优先选用HTML5 Audio,在不支持的环境中它会通过Scott的JavaScript库SoundManager 2使用Flash替代。它还使用了一些其他的有趣元素,包括使用<input type="range"> 实现唱片的平滑转换和本地存储,使用CSS3提升应用的视觉效果。Scott的The Wheels Of Steel: An Ode To Turntables (HTML)介绍了更多细节问题。里面说到“网页能够实现优雅的降级,即使在不支持JavaScript的环境中,应用的核心UI和内容也能够很好地显示。如果浏览器不支持JS网页就无法正常显示或变得模糊不清,这就是网站开发者的失职”。

图片 11客户端web apps

本文由澳门新葡亰手机版发布于web前端,转载请注明出处:改变游戏的20个HTML5网站,关于HTML5的11个让人难以

上一篇:开发相关内容总结,数据交互与本地存储 下一篇:HTML5在游戏领域不敌Flash,HTML5的10个关键区别
猜你喜欢
热门排行
精彩图文