广义论及HTML5时，实际指的是包括HTML、CSS和JavaScript在内的一套技术组合。它希望能够减少浏览器对于需要插件的丰富性网络应用服务（plug-in-based rich internet application，RIA)，如Adobe Flash、Microsoft Silverlight与Oracle JavaFX的需求，并且提供更多能有效增强网络应用的标准集。
目前HTML5已向开发人员提供了很多新的标签，如section，nav，article，header和footer等。这些标签语义化程度高，会被经常使用，但在IE6，IE7，IE8和Firefox 2等老式浏览器中却不能识别和正常使用。
一、HTML5标签在浏览器展示存在的问题
对于现阶段来说，使用HTML5标签可能遇到的最大问题就是如何在不支持新标签的浏览器中做恰当的处理。当我们在页面中使用HTML5元素时，可能会得到三种不同的结果。
结果1：标签被当作错误处理并被忽略。那么DOM构建的时候，就会当作这个标签不存在。
结果2：标签会被当作错误处理，并在DOM构建的时候依然会按照预期的代码进行创建，并且HTML标签会被构造成行内元素（也就是说虽然不能识别，但是代码里section标签依然会在dom中创建一个对应section节点，但是属于行内元素）。
结果3：标签被识别为HTML5标签，然后用DOM节点对其进行替换。DOM在构建的时候和预想的一致，并且合适的样式会应用到标签上（大部分情况下是块级元素）。
有一个具体的例子，大家思考一下下面的代码：
<div><section><h1>title</h1><p>text</p></section></div>
很多浏览器（比如Firefox 3.6和Safari4）解析的时候都会将div作为最外层的元素，然后div里面是一个识别不了的元素（section），它会在DOM中创建，并被作为一个行内元素存在。h1和p元素都是作为section元素的子节点。因为section在DOM中真实存在，所以也可以修改其样式。这种情况对应结果2。
IE9之前的版本会认为section标签是一个错误，并直接将其忽略，那么h1和p标签会被解析，然后成为div标签的子节点。</section>也会被认为是一个错误并直接跳过。在这些浏览器中实际有效的代码是这样的：
<div><h1>title</h1><p>text</p></div>
那么，旧版本的IE浏览器除了生成的DOM结构和其他浏览器不一样，其对不可识别标签的容错能力还是很棒的。因为section节点没有在DOM树中构建，所以也就不能给其增加样式。这种情况对应结果1。
当然，支持HTML5的浏览器比如IE9，Firefox4+，Safari5+会创建正确的DOM结构，然后这些标签会默认附带HTML5规范中定义的默认样式。
那么，我们所面临的最大问题就是同样的代码在不同的浏览器中形成了不同的DOM结构，并且含有不同的样式。
二、如何解决HTML5标签不兼容
或许会有很多人在质疑：为什么老式的浏览器不能识别这些标签？其实错不在浏览器，因为在那个时代根本不存在这种标签，所以不能正确识别出来，而这种不寻常的标签识别令DOM结构变得异常。对此，人们想出了很多在现阶段页面中使用HTML5元素的解决方案。每一个解决方案为了做到兼容都会遇到一些特定的问题。在此也在马海祥博客上跟大家分享一下：
1、实现标签被识别
马海祥曾做个一个测试（以IE8为例），是一个文章标题和蓝色字的文章内容，其中文章内容用了article标签。代码如下：
<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml"><head><meta charset="UTF-8" /><title>测试</title><style>article{color:#06F}</style></head><body><h1>文章标题</h1><article>这是文章内容，应该是一段蓝色的文字。在老式浏览器中，如果不做hack将显示异常。</article></body></html>
在IE8浏览器中，显示如下：
IE8不能识别article标签， 定义在标签上的CSS样式没有起作用。 在IE8中，<article>被解释成命名为<article />和</article />两个空的标签元素，与文章内容并列为兄弟节点，如下图所示：
既然因为不能识别标签而不能使用，那我们的解决办法就是让标签被识别出来。所幸，简单地通过document.createElement（tagName）即可以让浏览器识别标签和CSS引擎知道该标签的存在。假设我们上面的例子的<head>区域加上如下代码。
<script>document.createElement('article')</script>
IE8浏览器中的DOM解释就会变成下图所示：
自然，文字也显示成正常的蓝色。如下图所示：
2、JavaScript解决方案
JavaScript解决方案目的是解决在旧版本的IE中样式应用的问题。老版本的IE不会识别不明元素已经是一个耳熟能详的特性，而如果这些元素已经通过document.createElement()创建，那么浏览器就可以识别这些标签，并可以将其在DOM树中构建，然后允许开发者对其应用样式。
这个方法可以确保HTML5标签能在旧版本IE中对应创建DOM节点，然后可以对其应用样式。这个方法将HTML5块级元素设置成display:block，从而可以在各个浏览器中做到兼容。
今天测试以下把马海祥博客的网页改成了HTML5的，调试了一下，在FF和Opera中都显示正常了，到了IE6上却变得面目全非了。对此我还特意去找了一些使用JS代码支持HTML5标签元素的方法，在此也跟大家分享一下：
（1）、使用html5shiv
查看了一下，发现了html5shiv能解决这个问题，可以把HTML5的新元素转换成IE6认识的内容。只需要在你的head中调用这段代码就行：
<!--if lt IE 9]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
当然你也可以直接把这个文件下载到自己的网站上。但这个文件必须在head标签中调用，因为IE必须在元素解析这前知道这些元素，才能启作用！但马海祥还要提醒你一下：还要在你的CSS文件中加上以下代码，不然有可能会出现些莫名其妙的问题。
header,nav,article,section,aside,footer{display:block}
另外excanvas.js是Google为IE6支持canvas元素写的脚本，以后马海祥会跟大家再细说这样的例子，感兴趣的朋友可以去试试。
（2）、使用Kill IE6
除此之外你还可以使用KILL IE6一族，前提是你的浏览器允许执行JS文件。方法很简单，在你的网站的</body>之前加上以下代码就可以了：
<!--if lte IE 6]><script src="http://letskillie6.googlecode.com/svn/trunk/letskillie6.zh_CN.pack.js"></script><![endif]-->
上面写的<!--if lte IE 6]>在正常的HTML中属于注释，不会被执行，但在IE中是一个判断语句，所以这些代码只有在IE中才会被识别并加载。
lte：就是Less than or equal to的简写，也就是小于或等于的意思。
lt ：就是Less than的简写，也就是小于的意思。
gte：就是Greater than or equal to的简写，也就是大于或等于的意思。
gt ：就是Greater than的简写，也就是大于的意思。
! ： 就是不等于的意思，跟javascript里的不等于判断符相同
说实话，马海祥不喜欢这个利用JavaScript解决的方案，因为它破坏了我最主要的web应用开发原则：我们不应该使用JavaScript来控制布局。不仅仅是因为这个做法给那些禁用脚本的用户带来了糟糕的用户体验，更重要的是，如果我们希望我们的web应用代码是面向未来，并且维护性高的，那么必须将视图相关部分分离出来。这个方案对在跨浏览器中构建相同的DOM结构很有帮助，也可以确保你的JavaScript和CSS在各个地方运行结果相同，但是这个优势并不能改变我对这个方法的不认同。
3、Namespace hack
永远不要缺乏使用hack解决问题的能力，在IE中还有其他技术来让浏览器识别不明的标签。这个来自Elco Klingen日志的方法一开始引起了广泛的关注。该技术包含了一个XML形式的命名空间，并使用了含有namespace前缀的元素。例如：
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:html5="http://www.w3.org/html5/"> <body> <html5:section> <!-- content --> </html5:section> </body> </html>
前缀html5是纯粹是用于这个例子而且也不是官方支持的，你甚至可以用"foo"作为前缀，结果还是一样。有了前缀之后，IE会识别新的元素，从而可以应用样式。在其他浏览器中一样有效，那么最后，你就成功地在各个浏览器中构建了一样的元素和一样的样式。
这个方法的缺陷很明显：你必须在HTML文档中使用XML格式的命名空间，同样，你也需要在css中这么做:
html5\:section { display: block }
马海祥点评：这并不是我期望Web开发者编写代码的方式。虽然这是一个非常杰出的解决方案，但是这让应用变得不自然。我不希望看到文件中充满了带命名空间的元素。
4、Bulletproof技术（防d衣技术）
说实话，我是第一次接触到这个技术，建议在所有新的HTML5块级元素中增加一个内部的div元素，然后包含一个CSS class，用这个元素来替代HTML元素（类似在里面穿了一件防d衣），例如：
<section><div><!-- content --></div></section>
在应用样式的时候，Tantek推荐直接给div增加样式，而不是给新元素增加样式
推荐使用：
.section { color: blue }
而不是：
section { color: blue }
这个方案的原理是用简单的方式将原来的样式应用方式转移到一个代表了HTML5标签的元素上。由于我一般情况下不会将样式通过标签名的方式应用到元素上，所以马海祥也并完全支持这个建议。
马海祥觉得这个方案的缺陷是不同的浏览器构建了不同的DOM结构，那么你必须在编写JavaScript和CSS的时候格外小心。获取子节点或者父节点的时候，不同的浏览器返回的结果可能会不一样。特别是在下面的代码中：
<div><section><div class="section main"><!-- content --></div></section></div>
5、反向的bulletproof技术
还有一些方法，比如尝试使用和Tanteck方案相反的技术，也就是把HTML5元素放在div元素内部，例如：
<div><section><!-- content --></section><div>
这个方案唯一的不同是HTML5元素的位置，其他都一样。喜欢这个技术的支持者认为他的一致性很好（适用于所有的元素，包括<hgroup>）。但是DOM结构的不同让这个方案意义变得不大。他的主要优势是技术上的一致性。
6、关于X-UA-Compatible的使用
目前绝大多数网站都用以下代码来作为IE8的兼容方法。
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" >
虽然微软将IE向标准迈进了一大步，而事实上IE8还存在一系列渲染的奇怪现象是不争的事实。
在X-UA-Compatible中可用的方法有：
<meta http-equiv="X-UA-Compatible" content="IE=6" ><meta http-equiv="X-UA-Compatible" content="IE=7" ><meta http-equiv="X-UA-Compatible" content="IE=8" ><meta http-equiv="X-UA-Compatible" content="IE=edge" >
其中最后一行是永远以最新的IE版本模式来显示网页的。
另外加上
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" ><meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" >
而使用，Emulate模式后则更重视。
所以目前来说还是以使用
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" >
为首选。
7、通过修改HTML部分来实现
我的主要目标是确保我只需要修改HTML部分。这就意味着不需要修改CSS和JavaScript。为什么会有这样的需求？需要修改的Web应用视图越多，你越有可能制造bug。将改变限制到一个视图也就限制了bug的出现，即使出现了bug，也可以减少你查找错误的范围。如果一个视图破相了，我可以知道这是因为我增加了一个section元素，而不是考虑是不是CSS文件修改来带的影响。
在研究了所有这些解决方案，并进行一些尝试和设计之后，我回到了Tantek的方案。这是唯一一个只需要修改HTML而不用动CSS和HTML的方案。现在，我在他的方案基础上做了一些改进，来达到我想要的结果。
首先，我不会给那些代表HTML5元素的class增加样式（所以我不会使用.section这样的选择器）。我保留了div元素，然后再增加一个带语义的class来应用样式，并作为进行JavaScript *** 作的钩子。例如，这样的代码：
<div><!-- content --></div>
经过改进后：
<section><div class="section content"><!-- content --></div></section>
这样的修改完成后，我依然使用.content作为样式和脚本的入口。这也意味着我不需要修改CSS和JavaScript。
然后，为了避免hgroup标签这样的情况，我选择不使用这个标签。我在我已有的所有页面中没有找到任何一个使用了这个标签的。由于hgroup标签只能包含标题元素，如果你确实想要使用这个标签，那么使用hrgoup来包含本身是非常安全的（假设它没有包含其他的块级元素）。
关于 Web 格式推荐：MP4 + WebM 或者 Ogg 其中一种，当然全部都编码出来也可以
关于移动设备
推荐：怕麻烦则 MP4 格式，640×480 或者 480×360。不在乎编码时间和存储空间，就应该选择三种 MP4 编码方案（480×360，640×480，720p +“Main profile”）
外加一到两种 3GP 格式（320×240 或者 176×144），可以参考这份日志来获取更加详细的编码参数。
建议
以下是关于所有类型的视频编码方案建议，Zencoder 支持以下列出的所有编码格式
1.只为能播放
HTML5，Flash和移动设备：MP4/H.264，使用“Baseline”编码，480×360 或者 640×480
HTML5：WebM 或者 Ogg
2.更上一层楼
HTML5，Flash：MP4/H.264，“High profile”编码
HTML5：WebM
HTML5：Ogg
移动设备：MP4/H.264，“Baseline profile”编码，分辨率 480×360 或者 640×480
3.我要支持所有设备和浏览器
HTML5，Flash：MP4/H.264，“High profile”编码
HTML5： WebM
HTML5：Ogg
移动设备：MP4/H.264，“Baseline profile”编码，分辨率选择 480×360 以便提供高兼容性
移动设备：MP4/H.264，“Main profile”编码，分辨率 1280×720 以便支持新的设备（如 iPhone4、iPad 和 Apple TV）
移动设备：3GP/MPEG4，分辨率320×240 和（或） 177×144 以便支持非智能手机
Hybrid App（混合模式移动应用）是指介于web-app、native-app这两者之间的app，兼具“Native App良好用户交互体验的优势”和“Web App跨平台开发的优势”。1、AppCan
AppCan是国内Hybrid App混合模式开发的倡导者，AppCan应用引擎支持Hybrid App的开发和运行。并且着重解决了基于HTML5的移动应用"不流畅"和"体验差"的问题。使用AppCan应用引擎提供的Native交互能力，可以让HTML5开发的移动应用基本接近Native App的体验。[3]
AppCan作为中国Hybrid混合应用开发、移动平台、移动云平台的倡导者和领导者，以“免费+开源+开放”的互联网模式，为广大开发者提供一站式的移动应用开发支持服务。[4] 与此同时，从移动应用开发、管理、运营、安全四个方面，为各级政府和企事业单位，构建运营一体化的企业移动平台，企业通过个性化的移动运营门户，增强客户服务品质，提升整体经营管理水平。
现在，正益移动AppCan行业解决方案已成功应用于金融、航空、政府、石化、传媒等领域，客户包括东方航空、国家电网、中化集团、泰康人寿、新华社等众多大型企业，赢得了市场广泛认可，是国内企业移动信息化领域的龙头企业。[4]
2、Appcelerator
Appcelerator的Titanium开发平台使开发者可以通过HTML、PHP、JavaScript、Ruby、Python等Web编程语言开发手机、平板和桌面的原生App。其优势在于它可以让用户轻松地访问超过300个API以及定位信息。
此外，Appcelerator提供针对特定行为或事件定制的统计。App的数据既可储存在云端，也可储存在设备上。
3、Kerkee
Kerkee是一个多主体共存型Hybrid框架，具有跨平台、用户体验好、性能高、扩展性好、灵活性强、易维护、规范化、集成云服务、具有Debug环境、彻底解决跨域问题。[2]
从开发者角度来说，它支持三种的团队开发模式：
针对Web开发者：
这种模式其中的一个场景是：只会Web开发，却不会Native开发的开发者提供了一系列的平台型接口。这种方式具有开发周期短，跨平台等优点。
针对Native开发者 ：
这种开发模式的其中一个场景是：Native开发者想要截获Web页面的数据或者对数据进行自己的处理，或者Web页面中的行为进行修改。在这个时候，Kerkee框架将会为他们带来便利。
针对Web开发者和Native团队共同合作的开发团队 ：
对于这种模式的团队，kerkee框架具体更开放更透明的协作，并且严格地隔离各自职责。各得Web团队和Native团队把主要精力定位到各自的模块上，有利于各自的模块优化到极致。
4、WeX5
WeX5采用混合应用（hybrid app）开发模式, UI体系完全基于w3c的html5+css3+js；引入jquery和bootstrap并对移动做了底层优化，效率和性能接近原生应用。WeX5本机API Framework采用phonegap(cordova)框架。[5]
5、APICloud
APICloud是一款“云端一体”的移动开发平台，信仰“云端一体”的理念，重新定义了移动应用开发。APICloud为开发者从“云”和“端”两个方向提供API，简化移动应用开发技术，让移动应用的开发周期从一个月缩短到7天。APICloud由“云API”和“端API”两部分组成，可以帮助开发者快速实现移动应用的开发、测试、发布、管理和运营的全生命周期管理。
6、PhoneGap
PhoneGap是一个免费且开源的开发环境，使开发者可以开发出在Android、Palm、黑莓、iPhone、iTouch及iPad等设备上运行的App。其使用的是HTML和JavaScript等标准的Web开发语言。开发者使用PhoneGap进行开发，可调用加速计、GPS/定位、照相机、声音等功能。
PhoneGap还提供Adobe AIR App以及在线的培训课程，帮助开发者了解原生API并在他们自己的平台上开发移动App。
7、NativeScript
NativeScript是使用移动平台的 JavaScript 引擎来进行跨平台开发。逻辑部分自然无需多说，关键在于如何使用平台特性。NativeScript是通过反射得到所有平台 API，预编译它们，然后将这些 API 注入到 JavaScript 运行环境，接下来在 Javascript 调用后拦截这个调用，并运行 native 代码。NativeScript是使用大量 web 开发的技巧来进行 app 开发，因为工具链和语言都非常熟悉受到了很多前端开发者的欢迎。
8、Kinvey
Kinvey同样是一个为移动应用开发者提供后台创建服务的平台。Kinvey强调加速移动应用开发与销售的“即取即用”理念。Kinvey的中间层与数据层均托管在多个云服务提供商处，包括 Rackspace、Amazon与Microsoft。所有通过Kinvey存储的数据都会有四种方式备份：Amazon EC2、Windows Azure、Rackspace以及Kinvey自己的服务器，假如其中一两个出现了故障，用户的数据依然安然无恙。[6]
9、ExMobi
ExMobi通过全面的数据集成技术和丰富的跨平台客户端展现能力，将业务系统快速、安全、高效的移植于移动终端。ExMobi从开发（IDE环境）、集成（IT系统对接、云服务）、打包（各个 *** 作系统的应用打包）、发布（应用的运行）、管理（日志管理，更新管理）上提供了一套完整的解决方案。并通过专业的培训和支撑渠道为开发者提供可持续的学习和交流空间，扫除开发障碍。[7]
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）