如何处理html5新标签的浏览器兼容问题_随笔

目前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在构建的时候和预想的一致，并且合适的样式会应用到标签上（大部分情况下是块级元素）。

有一个具体的例子，大家思考一下下面的代码：

<h1>title</h1>

</section>

</div>

很多浏览器（比如Firefox

3.6和Safari4）解析的时候都会将div作为最外层的元素，然后div里面是一个识别不了的元素（section），它会在DOM中创建，并被作为一个行内元素存在。h1和p元素都是作为section元素的子节点。因为section在DOM中真实存在，所以也可以修改其样式。这种情况对应结果2。

IE9之前的版本会认为section标签是一个错误，并直接将其忽略，那么h1和p标签会被解析，然后成为div标签的子节点。</section>也会被认为是一个错误并直接跳过。在这些浏览器中实际有效的代码是这样的：

<h1>title</h1>

</div>

那么，旧版本的IE浏览器除了生成的DOM结构和其他浏览器不一样，其对不可识别标签的容错能力还是很棒的。因为section节点没有在DOM树中构建，所以也就不能给其增加样式。这种情况对应结果1。

当然，支持HTML5的浏览器比如IE9，Firefox4+，Safari5+会创建正确的DOM结构，然后这些标签会默认附带HTML5规范中定义的默认样式。

那么，我们所面临的最大问题就是同样的代码在不同的浏览器中形成了不同的DOM结构，并且含有不同的样式。

二、如何解决HTML5标签不兼容

或许会有很多人在质疑：为什么老式的浏览器不能识别这些标签？其实错不在浏览器，因为在那个时代根本不存在这种标签，所以不能正确识别出来，而这种不寻常的标签识别令DOM结构变得异常。对此，人们想出了很多在现阶段页面中使用HTML5元素的解决方案。每一个解决方案为了做到兼容都会遇到一些特定的问题。在此也在马海祥博客上跟大家分享一下：

1、实现标签被识别

马海祥曾做个一个测试（以IE8为例），是一个文章标题和蓝色字的文章内容，其中文章内容用了article标签。代码如下：

<!DOCTYPE html>

<head>

<style>

article{color:#06F}

</style>

</head>

<body>

这是文章内容，应该是一段蓝色的文字。在老式浏览器中，如果不做hack将显示异常。

</article>

</body>

</html>

在IE8浏览器中，显示如下：

IE8不能识别article标签，定义在标签上的CSS样式没有起作用。

在IE8中，<article>被解释成命名为<article />和</article

/>两个空的标签元素，与文章内容并列为兄弟节点，如下图所示：

既然因为不能识别标签而不能使用，那我们的解决办法就是让标签被识别出来。所幸，简单地通过document.createElement（tagName）即可以让浏览器识别标签和CSS引擎知道该标签的存在。假设我们上面的例子的<head>区域加上如下代码。

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]>

<![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]>

<![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前缀的元素。例如：

<body>

<html5:section>

</html5:section>

</body>

</html>

前缀html5是纯粹是用于这个例子而且也不是官方支持的，你甚至可以用"foo"作为前缀，结果还是一样。有了前缀之后，IE会识别新的元素，从而可以应用样式。在其他浏览器中一样有效，那么最后，你就成功地在各个浏览器中构建了一样的元素和一样的样式。

这个方法的缺陷很明显：你必须在HTML文档中使用XML格式的命名空间，同样，你也需要在css中这么做:

html5\:section {

display: block

}

马海祥点评：这并不是我期望Web开发者编写代码的方式。虽然这是一个非常杰出的解决方案，但是这让应用变得不自然。我不希望看到文件中充满了带命名空间的元素。

4、Bulletproof技术（防d衣技术）

说实话，我是第一次接触到这个技术，建议在所有新的HTML5块级元素中增加一个内部的div元素，然后包含一个CSS class，用这个元素来替代HTML元素（类似在里面穿了一件防d衣），例如：

</div>

</section>

在应用样式的时候，Tantek推荐直接给div增加样式，而不是给新元素增加样式

推荐使用：

.section {

color: blue

}

而不是：

section {

color: blue

}

这个方案的原理是用简单的方式将原来的样式应用方式转移到一个代表了HTML5标签的元素上。由于我一般情况下不会将样式通过标签名的方式应用到元素上，所以马海祥也并完全支持这个建议。

马海祥觉得这个方案的缺陷是不同的浏览器构建了不同的DOM结构，那么你必须在编写JavaScript和CSS的时候格外小心。获取子节点或者父节点的时候，不同的浏览器返回的结果可能会不一样。特别是在下面的代码中：

</div></section>

</div>

5、反向的bulletproof技术

还有一些方法，比如尝试使用和Tanteck方案相反的技术，也就是把HTML5元素放在div元素内部，例如：

</section>

<div>

这个方案唯一的不同是HTML5元素的位置，其他都一样。喜欢这个技术的支持者认为他的一致性很好（适用于所有的元素，包括<hgroup>）。但是DOM结构的不同让这个方案意义变得不大。他的主要优势是技术上的一致性。

6、关于X-UA-Compatible的使用

目前绝大多数网站都用以下代码来作为IE8的兼容方法。

虽然微软将IE向标准迈进了一大步，而事实上IE8还存在一系列渲染的奇怪现象是不争的事实。

在X-UA-Compatible中可用的方法有：

其中最后一行是永远以最新的IE版本模式来显示网页的。

另外加上

而使用，Emulate模式后则更重视。

所以目前来说还是以使用

为首选。

7、通过修改HTML部分来实现

我的主要目标是确保我只需要修改HTML部分。这就意味着不需要修改CSS和JavaScript。为什么会有这样的需求？需要修改的Web应用视图越多，你越有可能制造bug。将改变限制到一个视图也就限制了bug的出现，即使出现了bug，也可以减少你查找错误的范围。如果一个视图破相了，我可以知道这是因为我增加了一个section元素，而不是考虑是不是CSS文件修改来带的影响。

在研究了所有这些解决方案，并进行一些尝试和设计之后，我回到了Tantek的方案。这是唯一一个只需要修改HTML而不用动CSS和HTML的方案。现在，我在他的方案基础上做了一些改进，来达到我想要的结果。

首先，我不会给那些代表HTML5元素的class增加样式（所以我不会使用.section这样的选择器）。我保留了div元素，然后再增加一个带语义的class来应用样式，并作为进行JavaScript *** 作的钩子。例如，这样的代码：

</div>

经过改进后：

</div>

</section>

这样的修改完成后，我依然使用.content作为样式和脚本的入口。这也意味着我不需要修改CSS和JavaScript。

然后，为了避免hgroup标签这样的情况，我选择不使用这个标签。我在我已有的所有页面中没有找到任何一个使用了这个标签的。由于hgroup标签只能包含标题元素，如果你确实想要使用这个标签，那么使用hrgoup来包含本身是非常安全的（假设它没有包含其他的块级元素）。

我在马海祥博客上花了很多时间来测试比较bulletproof和反向的bulletproof哪个更好一些。我做选择时最主要的决定因素就是反向的bulletproof需要我去增加CSS代码。在那些为HTML5标签创建了DOM节点但是没有应用默认样式的元素来说，div元素里包含了一个HTML5块级元素在很多情况下都会搅乱我的布局，因为创建的DOM节点是行内元素。我不得不明确增加CSS规则来让这个节点变成块级元素从而可以正常布局，这也就违反了我不修改CSS文件的初衷。

马海祥博客点评：

在我的研究中，我使用了多个页面，然后在这些页面上使用修改过后的bulletproof技术。我分别在简单和复杂的布局中，含有和不含有JavaScript交互进行测试。在每一个例子中，我只需要修改HTML就可以让页面表现正确（不修改JavaScript和CSS）。那么，子节点和父节点的问题怎么办？有趣的事情是我在测试中并没有遇到这样的问题。

理由很简单，因为我对代码苛刻的态度。我认真地做了第二遍检查：

（1）、标签名和ID不会用于应用样式（只是用class）。

（2）、尽量选择常用的CSS选择器并且尽量减少选择器的使用。

（3）、JavaScript代码不依赖于特定的DOM结构。

（4）、标签名不用于 *** 作DOM。

我注意到另一个有趣的事情是我使用了HTML5元素作为容器。而这些新的元素仅仅是作为功能性模块的边界。你应该花费你的大部分时间为内部的元素编写样式和脚本而不是处理各个模块间的样式和脚本。由于马海祥博客的JavaScript和CSS标签都应用在容器的内部，所以一切都显得很顺利。我想这才是一个真正的代码质量高的网站。

目前大部分网站已经逐渐尝试使用HTML5进行重构，但基本大多停留使用新的HTML5语义化标签上。对于低版本IE浏览器，兼容新的HTML5标签很容易

而HTML5的新属性用到的不多，通常都是新属性+js兼容法

对于特殊的功能性新标签，国内几乎没有大型网站使用，如video、audio、canvas等

移动端大多是webkit内核，可放心使用HTML5

在国内，你要是等现代浏览器普及了再开始用HTML5那至少要5年以上，IE6应该还有1年左右就差不多灭绝了，IE8短时间内不会灭绝。

给你的建议是，可以考虑HTML5+兼容性辅助，让现代浏览器显示炫酷效果，老浏览器保证业务正常即可，不一定和HTML5版本样式完全一样，只要最基本功能有就行了

解决方法：将 *** 作系统与浏览器适配。

判断 *** 作系统和浏览器种类和版本，这个不难。

目前的主流平台一共5个：

桌面平台：

Windows（完美支持H5和 Flash Player）

Mac OS X（完美支持 H5和 Flash Player）

Linux（支持 H5，Flash Player支持到11.2，Chrome对 Flash Player 支持更好）

移动平台：

Android（支持 H5，Adobe已经放弃Flash Player支持）

iOS（支持 H5，不支持 Flash Player）

从上面可以看到，有半数以上的平台（包括已经放弃支持的）支持 Flash Player。既然超过了半数，就有进行切换的需求与可能。

最完美的情况，就是检测 *** 作系统和浏览器版本，根据不同情况进行适配，例如：

Windows XP 系统，IE6浏览器，使用 Flash Player 来播放视频；

Mac OS X 系统，使用 H5 来播放视频；

移动平台，必须使用 H5 ；

……

虽然在前端开发上有一定的成本（例如 Flash Player 和 H5 的界面适配、Desktop 和 Mobile 的界面适配，以及各种浏览器和平台的组合之类的），但也不是不可承受。

让我们来看看 Flash Player 与 H5 以及各个浏览器支持的视频格式吧（下表来自HTML5 Video）：

&ltimg data-rawheight="270" data-rawwidth="823" src="https://pic3.zhimg.com/50/66dc86342a9af7b4b0274124eb644445_hd.jpg" class="origin_image zh-lightbox-thumb" width="823" data-original="https://pic3.zhimg.com/66dc86342a9af7b4b0274124eb644445_r.jpg"&gt

也就是说，在支持 video 标签的 H5 浏览器中，并没有一种视频格式是所有浏览器通吃的。

如果觉得这个表不够详(zhuan)细(ye)的话，还可以看看下面这张图（下表来自wikipedia HTML5 video）：

&ltimg data-rawheight="869" data-rawwidth="1423" src="https://pic3.zhimg.com/50/1d915e90d4c19acd3239b976ccc93e85_hd.jpg" class="origin_image zh-lightbox-thumb" width="1423" data-original="https://pic3.zhimg.com/1d915e90d4c19acd3239b976ccc93e85_r.jpg"&gt

如果抛弃掉可爱又可怜的 Opera ，以及不考虑 Firefox 在 OS X 和 Linux 上的问题，我们确实可以说，MP4格式已经是所有现代浏览器能够直接支持的视频格式（下表来自A/V Formats | The State of HTML5 Video Report）：

&ltimg data-rawheight="760" data-rawwidth="960" src="https://pic2.zhimg.com/50/218d9bba7a6b14ca270c66dc729e70b2_hd.jpg" class="origin_image zh-lightbox-thumb" width="960" data-original="https://pic2.zhimg.com/218d9bba7a6b14ca270c66dc729e70b2_r.jpg"&gt

而实际上，已经有公司在做这件事（而且做了好久），JWPlayer 是一个优秀的 Flash Player 视频播放器，后来开始支持 H5，下面是它的一些介绍：

HTML5 Video Player &Flash Video Player

HTML5 Video Attributes &Market Share Report

所以，技术上并不是问题。做还是不做，我猜测最大的原因是视频格式转换成本。

这些视频网站已经积累的大量的视频资源，早期基本上是 Flash Only 的 FLV 格式。后期如果继续用Flash Player 来播放视频，为了实现高清的支持，很可能使用的是 MP4 的马甲 F4V 格式。这两种文件格式的标准可以看这里： F4V/FLV Technology Center。

FLV 格式早期使用过两种编码，分别是 Sorenson Spark 和 On2 VP6 （下表来自抛弃FLV，迎接MP4——制作Flash Player支持的H.264视频格式），这两种格式 H5 肯定是不支持的。

&ltimg data-rawheight="529" data-rawwidth="581" src="https://pic3.zhimg.com/50/d0b74e5f34fe771af73439044c8df4d1_hd.jpg" class="origin_image zh-lightbox-thumb" width="581" data-original="https://pic3.zhimg.com/d0b74e5f34fe771af73439044c8df4d1_r.jpg"&gt

因此，要将现有的海量视频数据转换成 MP4，需要一个相当的过程，视频网站可能考虑过这个过程比较漫长，就暂时将该工作搁置（或者正在平稳进行中）。

比如，YouTube 就已经把自己的所有视频转向 WebM（这是 Google 推动的视频格式），可以看这里：YouTube Swiftly Converts Videos in WebM Format。

但 Google 毕竟是钞票多到用不完，牛人多到一个团，从标准到产品到实现一条龙的一流公司。对于天朝这些小公司比如爱X艺优X库马铃薯之类来说，除了技术市场钞票广告之外，还必须考虑国情。

在伟大而神奇的中国，大量的平台依然是Windows XP + IE6 组合，让这些系统升级到 IE8都嫌困难，更别提安装 Chrome 和 Firefox 这种现代浏览器了。针对于它们，Flash Player 是唯一的选择。既然用 Flash Player 来播放视频，那么 FLV 还是 MP4 显然就无所谓了。

不过，一切都会改变的，至少在我们的有生之年，它们是一定会改过来的。

相比用 H5 全平台看视频，我更期待在有生之年登上月球（火星太远就不考虑了）。不过就目前科技的发展速度来看，有点儿悬。

另外吐槽题主3点：

1. 不是所有人都买得起 MBP 的……

2. 发热不能全怪在Flash Player 头上……

3. 就算你一定要怪在 Flash Player 头上，也不要仅仅是怪在视频播放器头上……

==================

2014-09-22更新：

按照评论里面的同学说的，我用 Android+Firefox 访问了优酷/土豆等网站，确实，它们在移动设备上已经支持 H5了。

所以我上面猜测的视频格式转换成本的原因应该是不存在的。

那么，我再次猜测，原因可能是以下几点：

1. Flash Player 在 PC 端的体验和表现更加一致，更容易管控播放器质量和进行版本迭代；

2. 由于前面讲到的原因，H5 的支持在 Windows XP 上是无望的，只能使用 Flash Player，国内企业必须考虑这点；

3. 为什么不检测浏览器版本实现不同平台使用不同的播放器，参照1的解释。

欢迎分享，转载请注明来源：内存溢出

原文地址: http://outofmemory.cn/zaji/7552067.html

如何处理html5新标签的浏览器兼容问题

发表评论

评论列表（0条）